just letting Nova
scheduler do all the hard work for us and let overrides maybe come in
later? Or should we we start off requiring that everything is manual and
later transition to using Nova? (I don't have a strong opinion either
way, but I hope we land o
, and that to start out we're just going to
handle the simple case of wanting to install many nodes, each with only
one distinct type. But I just wanted to clarify that we are, indeed,
making that decision?
Overall I think these look good. Thanks!
--
Matt Wagner
Software Enginee
ministrator, Anna wants to be able to view
> the history of nodes that have been in a deployment.
Why does she want to view history of past nodes?
Note that I'm not arguing against this; it's just not abundantly clear
to me what she'll be using this information for. Does she want
Count"? (I don't love that particular phrasing either, but it seems
more accurate/precise.)
> Does this seem accurate? All feedback is appreciated!
Thanks for starting this discussing, Mainn. I agree with the others that
it's a good idea to get this stuff nailed down early on.
--
PMI IP managed by Neutron.
I think what happened here is that two separate things we need got
conflated.
We need the IP address of the management (IPMI) interface, for power
control, etc.
We also need the MAC of the host system (*not* its IPMI/management
interface) for PXE to serve it the appropri
there a lasting benefit
long-term? I can see one -- match to the closest, but be willing to give
me more than I asked for if that's all that's available. Is there any
downside to this being permanent behavior?
I think the lowest-common-denominator match will be familiar to
sysadmins, too. W
en I manually
install it, the venv installation still tries to download the Google
Drive version and fails. I'm still pretty new to pip; is there a way to
force it to use a different location? Is there any value in me making
the version I downloaded available
bsequent patches to reduce the
> queue backlog and speed up development.
Big +1 from me on this. (I'd love to see this as more common practice in
the community overall, IMHO. Don't merge anything broken, but address
the "it would be neat if..." tasks in new patches instead of
On 30/04/14 15:37 -0700, Devananda van der Veen wrote:
Hi all,
Just a reminder that May 5th is our next scheduled meeting day, but I
probably won't make it, because I'll be just getting back from one trip and
start two consecutive weeks of conference travel early the next morning.
Chris Krelle (
On 26/05/14 09:39 -0700, Devananda van der Veen wrote:
Hi all!
I'd like to nominate Dmitry (dtantsur) to ironic-core. He's been very
active in Ironic over the last few months, in particular finding and
fixing bugs and adding support for CentOS and Fedora. His reviews have
been insightfu
On 04/06/14 17:21 +0800, 严超 wrote:
Hi, All:
When I tried to deploy a bare metal using ironic and following
http://ma.ttwagner.com/bare-metal-deploys-with-devstack-and-ironic/, I face
the one issue:
It looks like this message came through several times, and that
someone helped you in anothe
On 25/03/14 12:23 +, Lucas Alvares Gomes wrote:
Hi,
Right now Ironic is being responsible for storing the credentials for the
IPMI and SSH drivers (and potentially other drivers in the future), I
wonder if we should delegate this task to Keystone. The Keystone V3 API now
has a /credentials e
On 01/04/14 13:19 -0400, Solly Ross wrote:
As OpenStack Marconi grows, I think it's time we addressed the question on
everyone's mind:
why isn't the project called OpenStack Macaroni?
Strong +1 from me.
OpenStack is growing incredibly fast, but if there's one thing it
lacks, it's cheesy pasta
On 08/04/14 14:04 +0400, Vladimir Kozhukalov wrote:
0) There are a plenty of old hardware which does not have IPMI/ILO at all.
How Ironic is supposed to power them off and on? Ssh? But Ironic is not
supposed to interact with host OS.
I'm more accustomed to using PDUs for this type of thing. I.
On 05/08/14 12:33 -0700, Devananda van der Veen wrote:
Hi all!
The following idea came out of last week's midcycle for how to improve our
spec process and tracking on launchpad. I think most of us liked it, but of
course, not everyone was there, so I'll attempt to write out what I recall.
This
On 07/08/14 14:17 +0200, Dmitry Tantsur wrote:
2. We'll need to speed up spec reviews, because we're adding one more
blocker on the way to the code being merged :) Maybe it's no longer a
problem actually, we're doing it faster now.
I'm not sure if this will actually delay stuff getting merged.
16 matches
Mail list logo
