On Wed, Sep 3, 2014 at 12:50 PM, Nejc Saje wrote:
>
>
> On 09/02/2014 11:33 PM, Robert Collins wrote:
>>
>> The implementation in ceilometer is very different to the Ironic one -
>> are you saying the test you linked fails with Ironic, or that it fails
>> with the ceilometer code today?
>
>
> Disc
> I look at what we do with Ironic testing current as a guide here.
> We have tempest job that runs against Nova, that validates changes
> to nova don't break the separate Ironic git repo. So my thought
> is that all our current tempest jobs would simply work in that
> way. IOW changes to so called
Oh, it's because Precise doesn't have the docker.io package[1] (nor "docker").
AFAIK the -infra team is now using Trusty in gate, so it won't be a
problem. But if you think that we should still support Ironic DevStack
with Precise please file a bug about it so the Ironic team can take a
look on th
Hi Mike,
Thanks for bringing it up. I wanna say that I'm not an expert in
CPython, but I personally like the fix because I have had some
problems with stale .pyc in Ironic before, and they are pretty
annoying.
On Fri, Sep 12, 2014 at 4:18 PM, Mike Bayer wrote:
> I’ve just found https://bugs.laun
> 1. Not everyone will have an enterprise CMDB, so there should be some way
> to input inventory without one (even if it is a text file fed into
> ironicclient). The bulk-loading format to do this is TBD.
>
> 2. A way to generate that inventory in an automated way is desirable for
> some folks, but
Hi
2) UNDEPLOYED NODE - a node that has not been deployed with an instance
>
> Other suggestions included UNASSIGED, UNMAPPED, FREE, and AVAILABLE.
> Some people (I'm one of them)
> find AVAILABLE to be a bit of an overloaded term, as it can also be
> construed to mean that, say,
> a service ins
> So, a conversation came again up today around whether or not Ironic will,
> in the future, support operations on groups of nodes. Some folks have
> expressed a desire for Ironic to expose operations on groups of nodes;
> others want Ironic to host the hardware-grouping data so that eg. Heat and
>
Hi Rohan,
I've successfully deployed an image using Ironic+Devstack, you might want
to take a look at the guideline:
https://etherpad.openstack.org/p/IronicDeployDevstack
After calling /v1/nodes//states/provision, my Node
> "provision_state" is stuck at "deploying" and i can also see that there i
>
> So, I'd like to nominate the following two additions to the ironic-core
> team:
>
> Max Lobur
>
> https://review.openstack.org/#/q/reviewer:mlobur%2540mirantis.com+project:openstack/ironic,n,z
>
> Roman Prykhodchenko
>
> https://review.openstack.org/#/q/reviewer:rprikhodchenko%2540mirantis.com+
+1
> What time would work for you? How about Thursdays at 8am PST?
>
Works for me
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi Ruby,
Thank you for putting this up.
I'm one of the ones think we should try hard (even really hard) to
maintain the compatibility on every commit. I understand that it may
sound naive because I'm sure that sometimes we will break things, but
that doesn't means we shouldn't try.
There may be
Hi,
Thanks for putting it up Dmitry. I think the idea is fine too, I understand
that people may want to use in-band discovery for drivers like iLO or DRAC
and having those on a separated interface allow us to composite a driver to
do it (which is ur use case 2. ).
So, +1.
Lucas
On Wed, Nov 26,
>
> > https://en.wikipedia.org/wiki/Blaze_Bayley
>
> Good call! I never thought I'd see a Blaze Bayley reference on this
> list. :) Just watch out for imposters...
>
> http://en.wikipedia.org/wiki/Slow_Riot_for_New_Zer%C3%B8_Kanada#BBF3
>
> >
> >
> >
Ah forgot to say,
Please add your launchpad ID on the Name Field. And I will close the poll
on Wednesday at 18:00 UTC (I think it's enough time to everyone take a look
at it)
Cheers,
Lucas
On Mon, Dec 1, 2014 at 4:44 PM, Lucas Alvares Gomes
wrote:
> Hi all,
>
> I'm sorry fo
Hi,
Poll is closed! Everyone please welcome: Pixie Boots, the new Ironic mascot!
Thanks for everyone that voted!
Cheers,
Lucas
On Mon, Dec 1, 2014 at 4:47 PM, Lucas Alvares Gomes
wrote:
> Ah forgot to say,
>
> Please add your launchpad ID on the Name Field. And I will close the
Hi
I probably won't be able to make it to the SF Bay Area, but I think it's a
good idea for those who can't go to Grenoble.
Lucas
On Tue, Dec 30, 2014 at 9:58 PM, Clif Houck wrote:
> I'll attend. Whether it's in-person or remote is up in the air though.
>
> Clif
>
> On 12/30/2014 10:51 AM, Jay
Hi Peeyush,
Now, the problem is that external DHCP is not able to send confirmation
> of deployment to Ironic server, which results in timeout for the
> instance. I want to know how Ironic is handling external DHCP, do I need
> to make changes other than putting "dhcp_provider=none"?
>
AFAIUI set
eers,
Lucas
On Tue, Jan 13, 2015 at 12:04 PM, Lucas Alvares Gomes wrote:
> Hi Peeyush,
>
> Now, the problem is that external DHCP is not able to send confirmation
>> of deployment to Ironic server, which results in timeout for the
>> instance. I want to know how Ironic is han
> We've all been pretty lax about the amount of detail that we put in commit
> messages some times, and I'd like to change that as we start Juno
> development. Why? Well, just imagine that, six months from now, you're going
> to write a document describing *all* the changes in Juno, just based on t
> 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 (nobodycam) has offered to chair that meeting i
On Thu, May 22, 2014 at 1:03 AM, Devananda van der Veen
wrote:
> I'd like to bring up the topic of drivers which, for one reason or another,
> are probably never going to have third party CI testing.
>
> Take for example the iBoot driver proposed here:
> https://review.openstack.org/50977
>
> I
> Linux has a very different model then OpenStack does, the article you
> mention is talking about a whole separate git repo, along with a separate
> (re: just OR, not exclusive or) set of maintainers. If you leave these
> drivers in a staging directory would you still require two cores for the
> c
+1
On 26 May 2014 17:45, "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
> insig
On Wed, May 28, 2014 at 2:02 PM, Dmitry Tantsur wrote:
> Hi Ironic folks, hi Devananda!
>
> I'd like to share with you my thoughts on asynchronous API, which is
> spec https://review.openstack.org/#/c/94923
> First I was planned this as comments to the review, but it proved to be
> much larger, so
On Wed, May 28, 2014 at 10:18 PM, Jaromir Coufal wrote:
> Hi All,
>
> There is a lot of tags in the subject of this e-mail but believe me that all
> listed projects (and even more) are relevant for the designs which I am
> sending out.
>
> Nodes management section in Horizon is being expected for
On Wed, Jun 4, 2014 at 2:51 PM, 严超 wrote:
> Yes, but when you assign a "production" image to an ironic bare metal node.
> You should provide ramdisk_id and kernel_id.
> Should the ramdisk_id and kernel_id be the same as deploy images (aka the
> first set of k+r) ?
> You didn't answer me if the two
Hi,
On Fri, Jun 6, 2014 at 9:44 AM, Gopi Krishna Saripuri
wrote:
> Hi,
>
> I'm using icehouse devstack version. I'm testing the vendor_passthru methods
> behavior using curl , But it is failing with 404 not found error.
> Here is the query/response.
>
> curl -H "X-Auth-Token:${token}"
> http://
On Fri, Jun 6, 2014 at 3:18 AM, David Shrewsbury
wrote:
> FYI for all,
>
> I have posted http://review.openstack.org/98201 in an attempt to at least
> give *some* warning to developers that a change to one of the public
> methods on classes we derive from may have consequences to Ironic.
> I have
On Wed, Mar 12, 2014 at 8:07 PM, Chris Jones wrote:
>
> Hey
>
> I wanted to throw out an idea that came to me while I was working on
> diagnosing some hardware issues in the Tripleo CD rack at the sprint last
> week.
>
> Specifically, if a particular node has been dropped from automatic
> schedul
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 endpoint which would allow us to specify arbitrary type
Hi Russell,
Ironic allows drivers to expose a "vendor passthru" API on a Node. This
> basically serves two purposes:
>
> 1. Allows drivers to expose functionality that hasn't yet been
> standardized in the Ironic API. For example, the Seamicro driver exposes
> "attach_volume", "set_boot_device" an
On Fri, Apr 4, 2014 at 3:10 PM, Ling Gao wrote:
> Hello Vladimir,
> I would prefer an agent-less node, meaning the agent is only used
> under the ramdisk OS to collect hw info, to do firmware updates and to
> install nodes etc. In this sense, the agent running as root is fine. Once
> the nod
> There are lots of configuration management agents already out there (chef?
> puppet? salt? ansible? ... the list is pretty long these days...) which you
> can bake into the images that you deploy with Ironic, but I'd like to be
> clear that, in my opinion, Ironic's responsibility ends where the h
>
> So, I'd like to formally propose that Ruby (rloo), Haomeng (whaom), and
> Yuriy (yuriyz) be added to the core team at this time. I believe they have
> all been very helpful over the last few months.
>
+1 for all! Good stuff :)
Cheers,
Lucas
___
OpenS
+1 for me as well, I'd like to have a better way to track incoming features.
Also, as part of the migration progress I think that we need a good
wiki page explaining the process of how propose a new feature, with a
template of what's mandatory to fill out and what is optional. I
wouldn't like to h
Hi,
Today we have hit the problem of having an outdated sample
configuration file again[1]. The problem of the sample generation is
that it picks up configuration from other projects/libs
(keystoneclient in that case) and this break the Ironic gate without
us doing anything.
So, what you guys thi
Thanks guys for the heads up
Indeed making it backwards compat by adding the "[ip_]version" key to
the dictionary sounds like the best way to go.
Cheers,
Lucas
On Thu, Oct 2, 2014 at 3:53 AM, Carlino, Chuck wrote:
> As a 'heads up', adding ironic to the thread since they are a 'key' consumer
>
Hi,
I don't know if it's a known issue, but we have this patch in Ironic
here https://review.openstack.org/#/c/124610/ and the gate jobs for
python26 and python27 are failing because of some import error[1] and
it doesn't show me what is the error exactly, it's important to say
also that the tests
On Thu, Oct 2, 2014 at 12:47 PM, Dmitry Tantsur wrote:
> On 10/02/2014 01:30 PM, Lucas Alvares Gomes wrote:
>>
>> Hi,
>>
>> I don't know if it's a known issue, but we have this patch in Ironic
>> here https://review.openstack.org/#/c/124610/ and the
Awesome!
Thanks Doug for this, I will start working on moving the ironic* stuff
to use the oslo libraries.
Lucas
On Mon, Oct 13, 2014 at 2:20 PM, Doug Hellmann wrote:
> I’ve put together a little script to generate a report of the projects using
> modules that used to be in the oslo-incubator
+1 for the separation
I already gave up of the term "discovery" as you can see on the DRAC
Hardware Introspection[1] spec, I also don't think that
"introspection" is the best word for that (we already use the world
"cloud" for OpenStack so it can't get more confusing than that).
Perhaps "interroga
On Tue, Oct 21, 2014 at 10:27 AM, Sam Betts (sambetts)
wrote:
> I agree with Devananda's definition of Œhardware discovery¹ and other
> tools similar to Ironic use the term discovery in this way, however I have
> found that these other tools often bundle the gathering of the system
> properties to
On Tue, Oct 21, 2014 at 6:29 PM, Stuart Fox wrote:
> Having written/worked on a few DC automation tools, Ive typically broken
> down the process of getting unknown hardware into production in to 4
> distinct stages.
> 1) Discovery (The discovery of unknown hardware)
> 2) Normalising (Push initial
Chris,
It was great to work with you, best of luck and enjoy this new opportunity.
Cheers,
Lucas
On Wed, Oct 22, 2014 at 6:50 PM, Morgan Fainberg
wrote:
> Chris,
>
> Best of luck on the new adventure! Definitely don’t be a stranger!
>
> Cheers,
> Morgan
>
>> On Oct 22, 2014, at 10:37, Chris Beh
Just for reference, the spec is this one:
https://review.openstack.org/#/c/133828/
That's a good point, I think it's important to have this distinction
of a new node being discovered and a registered node being
introspected/interrogated. So I'm +1 for the idea.
On Wed, Nov 12, 2014 at 9:47 PM, Vi
On Thu, Nov 13, 2014 at 4:45 AM, Angus Salkeld wrote:
> On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews
> wrote:
>>
>> Hi All,
>>
>> Chris Yeoh started the use of an APIImpact flag in commit messages for
>> specs in Nova. It adds a requirement for an APIImpact flag in the commit
>> message for a pr
Hi
On Thu, Nov 13, 2014 at 11:27 AM, Ganapathy, Sandhya
wrote:
> Hi All,
>
> Based on the discussions, I have filed a blue print that initiates discovery
> of node hardware details given its credentials at chassis level. I am in the
> process of creating a spec for it. Do share your thoughts re
This was discussed in the Contributor Meetup on Friday at the Summit
but I think it's important to share on the mail list too so we can get
more opnions/suggestions/comments about it.
In the Ironic weekly meeting we dedicate a good time of the meeting to
do some announcements, reporting bug status
On Sun, Nov 16, 2014 at 2:27 PM, Assaf Muller wrote:
>
>
> - Original Message -
>> Hi Ironickers,
>>
>> I was thinking this weekend: All the cool projects does have a mascot
>> so I thought that we could have one for Ironic too.
>>
>> The idea about what the mascot would be was easy becaus
I'm adding all the names suggestions to the Ironic WhiteBoard
etherpad[1] (at the bottom).
Feel free to include more names there and then we can call a vote.
[1] https://etherpad.openstack.org/p/IronicWhiteBoard
Lucas
On Mon, Nov 17, 2014 at 10:56 AM, Lucas Alvares Gomes
wrote:
> On
people to discuss anything that need further explanation, only mentioning
>>> the topic but not the content.
>>>
>>> Ghe Rivero
>>>
>>> On Nov 13, 2014 5:08 PM, "Peeyush Gupta"
>>> wrote:
>>>>
>>>> +1
>>&g
On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen
wrote:
> Hi all,
>
> As discussed in Paris and at today's IRC meeting [1] we are going to be
> alternating the time of the weekly IRC meetings to accommodate our
> contributors in EMEA better. No time will be perfect for everyone, but as it
>
, Lucas!
>
> Deva
>
> On Mon Nov 17 2014 at 8:20:09 AM Jim Rollenhagen
> wrote:
>>
>> On Sun, Nov 16, 2014 at 01:14:13PM +, Lucas Alvares Gomes wrote:
>> > Hi Ironickers,
>> >
>> > I was thinking this weekend: All the cool projects does hav
> I just started the code for processing of notifications from Ironic.
> Conceptually they are the same as notifications from Nova but the
> actual form of the payload is completely different. This means I have to
> write a different processor for that payload. And now so does StackTach
> if they w
+1 !
On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen
wrote:
> Hi all!
>
> It's time to grow the team :)
>
> Jim (jroll) started working with Ironic at the last mid-cycle, when "teeth"
> became ironic-python-agent. In the time since then, he's jumped into Ironic
> to help improve the proj
+1 !
On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen
wrote:
> Hi all!
>
> While David (Shrews) only began working on Ironic in earnest four months
> ago, he has been working on some of the tougher problems with our Tempest
> coverage and the Nova<->Ironic interactions. He's also become q
On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies wrote:
> At the meetup today, the topic of our spec process came up. The general
> sentiment is that the process is still young and the hiccups are expected,
> but we do need to get better about making sure we're staying on top of them.
>
> As a first st
Oh sorry... I thought it was about Ironic not TripleO (morning issues)
Anyway, it could be something that we could adopt in Ironic as well :)
On Wed, Jul 23, 2014 at 9:40 AM, Lucas Alvares Gomes
wrote:
> On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies wrote:
>> At the meetup today, the
Already agreed with the idea at the midcycle, but just making it public: +1
On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko
wrote:
> Hi!
>
> I think this is a nice idea indeed. Do you plan to use this process starting
> from Juno or as soon as possible?
It will start in Kilo
___
> We've come to a conclusion that it would be a great opportunity for both
> teams to join forces and build this thing together.
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/open
no doubt, +1
On Tue, Sep 24, 2013 at 7:04 PM, Devananda van der Veen
wrote:
> Hi!
>
> I would like to nominate myself for the OpenStack Bare Metal Provisioning
> (Ironic) PTL position.
>
> I have been working with OpenStack for over 18 months, and was a scalability
> and performance consultant at
+1 to consolidate.
They are all doing the same thing, so why not put them into a common place?
>
*almost* the same thing, there's some small differences, one e.g is that
Ironic use PATH for the update instead of PUT.
Cheers,
Lucas
___
OpenStack-dev mai
+1
On Wed, Jul 31, 2013 at 5:29 PM, Anita Kuno wrote:
> I agree too.
>
>
> On 13-07-31 12:20 PM, Ghe Rivero wrote:
>
> +1
>
>
> On Wed, Jul 31, 2013 at 6:10 PM, Devananda van der Veen
> wrote:
>>
>> Hi,
>>
>> I'd like to propose to add Chris (NobodyCam) to ironic-core. He has been
>> doing a lot
> So - calling for votes for Derek to become a TripleO core reviewer!
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,
> I am interested in remote BIOS configuration.
> There is "New driver interface for BIOS configuration specification"
> https://review.openstack.org/#/c/209612/
>
> Is it possible to implement this without REST API endpoint?
>
I may be missing something here but without the API how will the
Hi,
> Let's have a quick poll, which would you prefer and why:
>
> 1. openstack baremetal provision state --provide UUID
> 2. openstack baremetal provision --provide UUID
> 3. openstack baremetal provide UUID
> 4. openstack baremetal set provision state --provide UUID
> 5. openstack baremetal set
> It's still not 100% consistent, "power" is a noun, "provision" is a verb.
> Not sure it matters, though, adding OSC folks so that they can weigh in.
>
"provision" can also be a noun [1]. But since the OSC syntax suggest
having a verb we could have something like:
$ openstack baremetal set power
Hi,
In the last Ironic meeting [1] we started a discussion about whether
we need to have a mid-cycle meeting for the Mitaka cycle or not. Some
ideas about the format of the midcycle were presented in that
conversation and this email is just a follow up on that conversation.
The ideas presented we
Hi,
> Also keep in mind that DEBUG logging, while still should have some masking
> of data, since it is explicitly called out (or should be) as not safe for
> production, can contain some " sensitive" data. Credentials should still be
> scrubbed, but I would say the swift temp URL is something tha
Hi,
> I sent a new idea to openstack-dev, and nobody has opinions? :P
>
> I'd like to get consensus on this soon, please do reply if you have
> thoughts on this.
>
Sorry for the delay...
Yeah, I've no problem giving this virtual midcycle idea a go, so +1
I'm +1 for re-enabling it in Ironic. I think ironic plays a big role
in the tripleo puzzle so we should be aware of breakages in the
tripleo project.
On Mon, Nov 30, 2015 at 3:19 PM, Derek Higgins wrote:
> Hi All,
>
> A few months tripleo switch from its devtest based CI to one that was
> bas
Hi Zhi,
> And the error message is:
> InstanceDeployFailure: RPC do_node_deploy failed to validate deploy or power
> info. Error: Node d71babdd-aa91-450d-b957-dc8c633c41f2 is configured to use
> the agent_ssh driver which currently does not support deploying partition
> images.
>
> Could someone g
Hi,
> 1. "baremetalintrospection" - named after the process we
> implement
+1 for baremetal-introspection ( or inspection ? )
Cheers,
Lucas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
Hi,
Thanks for starting this discussion Ruby.
On Mon, May 16, 2016 at 2:57 PM, Loo, Ruby wrote:
> Hi,
>
> A patch to ironic-lib made me wonder about what is our supported usage of
> ironic-lib. Or even the intent/scope of it. This patch changes a method,
> ‘bootable’ parameter is removed and ‘bo
Hi,
On Mon, May 16, 2016 at 3:56 PM, Sam Betts (sambetts)
wrote:
> I personally disagree with saying that if we wanted it make it usable by
> projects other than ones in the Ironic umbrella it should go into oslo. I
> think that non-ironic projects directly related to Ironic such as out of
> tree
Hi,
> So… how does any library get ready to be used by others? Clearly it is being
> used now by the fuel-agent. Do we say ‘sorry fuel-agent, we don’t guarantee
> yet that we won’t break you’? Or ‘fuel-agent, just so you know. Ironic-lib
> isn’t quite ready to be used so we cannot guarantee that w
Hi,
> This sounds like an Ironic bug to me. Cleaning (wiping a disk) and
> removing state that would break subsequent installations on a different
> drive are different things. In TripleO I think the reason we disable
> cleaning is largely because of the extra time it takes and the fact
> that our
Hi,
> I see in the priority list that "redfish support" is still highly wanted (4
> +1).
> And we are still very interested to provide that. It took much more time
> than expected, as we first decided that we wanted a good low level library
> to help us dialog following the Redfish standard to the
Hi,
> I'm working with Tien who is a submitter of one[1] of console specs.
> I joined the console session in Austin.
>
> In the session, we got the following consensus.
> - focus on serial console in Newton
> - use nova-serial proxy as is
>
> We also got some requirements[2] for this feature in th
Hi,
Thanks for bringing this up Vasyl!
> At the moment Nova with ironic virt_driver consider instance as deleted,
> while on Ironic side server goes to cleaning which can take a while. As
> result current implementation of Nova tempest tests doesn't work for case
> when Ironic is enabled.
>
> The
Hi,
Thanks for writing it down Jim.
> So, I've been thinking about this quite a bit. We've also talked about
> doing a v2 API (as evil as that may be) in Ironic here and there. We've
> had lots of lessons learned from the v1 API, mostly that our API is
> absolutely terrible for humans. I'd love t
Hi,
>> I agree in general with the idea but I think it needs a tad more
>> context. We need to remember that Ironic (ex-Nova Baremetal) was
>> created to fill a gap in OpenStack that was missing for TripleO
>> project to get off the ground. That was the problem being solved and
>> these aspects ar
Hi,
> Both Sam and Jay are to the point where I consider their +1 or -1 as
> highly as any other core, so I think it's past time to allow them to +2
> as well.
>
> Current cores, please reply with your vote.
>
Great work Sam and Jay!
+1 for both
Cheers,
Lucas
__
Hi,
On Wed, Jun 22, 2016 at 10:53 AM, Sam Betts (sambetts)
wrote:
> This patch https://review.openstack.org/#/c/324909/ merged last night and
> has broken the IPA functional tests.
>
> To verify pull master and run "tox -r -e func" and it¹ll fail to run. If
> you git checkout the commit before th
Hi,
>> I would say we should add a job to the IPA gate to verify the
>> functional tests, just like swift does [0].
>>
>> We may also need to revert/fix that patch that broke those tests.
>
>
> I'm -1 to reverting anything until we have the test in the gate.
>
Fair enough.
I've opened two bugs:
Hi,
Hi this email is just a heads up to alert people that the
"IRONIC_QEMU_HOOK_PATH" variable for DevStack is not available
anymore, a path [0] was merged and replaced that variable with another
one called "IRONIC_LIBVIRT_HOOKS_PATH" without deprecating it first.
For context, the "IRONIC_QEMU_HO
Hi,
I would like to quickly announce the creation of a new project called
Ironic Staging Drivers.
What the Ironic Staging Drivers project is?
-
As context, in the Tokyo design summit it was decided that drivers in the
Ironic tree will
Hi,
> So, it looks like the only reason we check the reservation field here is
> because we want to return a 409 for "node is locked" rather than a 400,
> right? do_node_deploy and such will raise a NodeLocked, which should do
> the same as this check. It's unclear to me why we can't just remove t
Hi,
>
> Another question folks: while the problem above is valid and should be
> solved, I was actually keeping in mind another one:
> https://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/node.py#L1052-L1057
>
> This is also not retried, and it prevents updating during power o
Hi,
> malhar@ubuntu:~/Documents/contribution/temp/ironic$ git review -s
> Using global/system git-review config files
> (/etc/git-review/git-review.conf) is deprecated
> Could not connect to gerrit.
> Enter your gerrit username: myusername
> Trying again with
> ssh://malhar_v...@review.openstack.o
Hi,
> Please make sure you have the correct access rights
> and the repository exists.
> error: Could not fetch gerrit
> Problems encountered installing commit-msg hook
> The following command failed with exit code 1
> "scp -P29418 malhar_...@review.openstack.org:hooks/commit-msg
> .git/hooks/
Hi,
> Could you combine 1 and 4?
>
> Deprecate not specifying the version, but pin to the oldest one for now?
> That way users get the warnings that they need to adapt, but things keep
> working? Could be switched to just 4 after a few months.
>
This is similar to what I would like to suggest. Bu
>> 1. yes
>> 2. no -- the client should default to the minimum supported version. We got
>> that wrong previously, and that's what is hurting us now.
>
> So if we do this, simply shipping the code doesn't break anyone. Nobody
> has disagreed on this yet, best I can tell.
>
We would still need a de
On Thu, Jul 30, 2015 at 8:27 AM, Dmitry Tantsur wrote:
> On 07/30/2015 08:59 AM, Kai KH Huang wrote:
>>
>> Dear Devananda
>>
>> I'm the development leader of Lenovo Cloud Solution. Lenovo is
>> planning to contribute its Ironic driver to the OpenStack community. The
>> Ironic driver deve
Hi,
> It sounds like we all agree -- the client we ship should default to a fixed,
> older version. Anyone who wants newer functionality can pass a newer version
> to their client.
>
> Here's the current state of things:
>
> server:
> - stable/kilo: 1.6
> - current: 1.11
>
> client:
> - stable/kil
Hi,
> Our initial solution [1] was to simply disable instance queries in the
> IronicHostManager, as they were never needed, and were painful to
> execute. But subsequent discussion on IRC brought up some potential
> (although not very likely) use cases where this might not be true. One
> example
Hi,
Thanks for the reminder.
> Just a quick reminder - we're switching back to a consistent meeting time,
> at 18:00 UTC Mondays.
>
The time is actually 17:00 UTC [1]
[1] https://wiki.openstack.org/wiki/Meetings/Ironic#Next_Meeting
Cheers,
Lucas
___
HI
> Hi, I'd like to make sure I understand. Is it the case that ideally, if we
> could go back in time, we'd like to change the client so it defaults to 1.1?
AFAIUI, yes
> But since we can't, the next client that we ship/release will have the most
> reasonable oldest version? If so, then since
Hi,
> After thinking about this some more, I'm not actually going to address Rob's
> points above. What I want to do is go back and discuss... what do people
> think about having an API that allows the initial provision state to be
> specified, for a node that is created in Ironic. I'm assuming th
Hi
> On 21 Aug 2015 6:45 am, "Jim Rollenhagen" <
>>
>> +1, there are tons of dragons here. Now that we're to the point where
>> our state machine is well-defined with a single entrypoint, I think
>
> I'm clearly confused. When was 1.6 deleted?
>
It wasn't and won't be AFAICT. But I think Jim is t
1 - 100 of 170 matches
Mail list logo
