Re: [openstack-dev] [Ironic] [TripleO] How to gracefully quiesce a box?

I also feel that graceful power off is one of the feature that we want in ironic. But until then, you can see if the below works for you: You can set the following property to false which will prevent ironic to sync the power state. It will instead update the node with the latest power status

[openstack-dev] [ironic] How to use ironic-python-agent ?

Hi, This is regarding the new teeth agent that is proposed in Ironic. I understand that the teeth agent is still under development, but is there some document available on how I can include the teeth agent in my ramdisk, so that I can get it handshaked with the ironic driver. I just checked the

Re: [openstack-dev] [Nova Baremetal] disk-image builder tool error

As the error suggests, please use one of the root distribution elements (ubuntu, fedora, etc). disk-image-create -h will give some examples. On Tue, Apr 22, 2014 at 1:24 PM, Jander lu lhcxx0...@gmail.com wrote: Hi, I am following this wiki page(https://wiki.openstack.org/wiki/Baremetal),

Re: [openstack-dev] [ironic workflow question]

The deployment kernel/ramdisk is supposed to be built by ramdisk-image-create command. *ramdisk-image-create -a amd64 fedora deploy-ironic -o /tmp/deploy-ramdisk* The deployment kernel/ramdisk is used only for deployment and cannot give a full-fledged system. The deploy images are created by

Re: [openstack-dev] [Nova] [Ironic] vendor_passthru testing

Hi, vendor_passthru is a POST request and that might be missing here. curl -i -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -H X-Auth-Token:${token} http://10.105.214.179:6385/v1/nodes/2d70d135-85b5-4f75-b741-0ead90a42b29/vendor_passthru/get_firmware_info Can you just

Re: [openstack-dev] [Ironic] Do we need an IntrospectionInterface?

+1 for a separate interface. On Fri, Nov 28, 2014 at 7:20 PM, Lucas Alvares Gomes lucasago...@gmail.com wrote: 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

[openstack-dev] [Ironic] RAID interface - backing disk hints

Hi All, This is regarding the RAID configuration spec that was posted for review some time back: https://review.openstack.org/#/c/135899/ This review consists of a generic RAID interface currently proposed jointly by Redhat (for DRAC hardware) and HP (for iLO hardware). This spec defines a

Re: [openstack-dev] [Ironic][FFE] secure boot support in iLO drivers

Corrected [1] is below (link for pxe_ilo patch review): [1] https://review.openstack.org/#/c/154808/ On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen devananda@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, This feature [0] enables secure boot mode for

[openstack-dev] [Ironic] Adding vendor drivers in Ironic

Hello All, This is about adding vendor drivers in Ironic. In Kilo, we have many vendor drivers getting added in Ironic which is a very good thing. But something I noticed is that, most of these reviews have lots of hardware-specific code in them. This is something most of the other Ironic

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

for the requestor, of course keeping in mind that the request has to be correct and get's reviewed and approved by infra guys)*. Kudos to you guys :-) Regards, Ramesh On Sun, Mar 1, 2015 at 12:49 AM, Anita Kuno ante...@anteaya.info wrote: On 02/28/2015 01:28 AM, Ramakrishnan G wrote: Hello All

Re: [openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd

In my opinion, Ironic has a (better) way for doing deploy aborts. During a deploy in a real-world case, major chunk of time for the deploy is spent in booting up the bare metal. The state of node during this time is wait-call-back. It is possible today to abort the deploy when state of the node

Re: [openstack-dev] [Ironic] [RFC/FFE] Finishing state machine work for Kilo

+1 from me. Since we don't have ENROLL state as per the state machine, I think it should be MANAGEABLE when we enroll a node. At least, it can also prevent nodes getting into a ready state even before an operator getting hands on it. One comment on #2. Before we make a new client release with

[openstack-dev] [Ironic] boot-deploy interface separation

Hi All, *What this mail is about ?* As part of the below blueprint, we are planning for a boot deploy interface separation in Ironic. https://blueprints.launchpad.net/ironic/+spec/new-boot-interface *Whom does this concern ?* * If you have an out of the tree driver for Ironic * If you are in

Re: [openstack-dev] [Ironic] ironic-lib library

Seems to me like we can keep ironic-lib git repository as a git submodule of the ironic and ironic-python-agent repositories. Any commit in Ironic or Ironic-python-agent can change ironic-lib independently. Also, looks like our CI system supports it by automatically pushing commits in the

[openstack-dev] [Ironic] Adopting ironic-lib in Ironic

Hi All, Some time back we created a new repository[1] to move all the reusable code components of Ironic to a separate library. The branched out code has changed and there has been a review out to sync it [2]. But unfortunately, it has got stale again as some more changes have gone in to the

Re: [openstack-dev] [Ironic] ironic-lib library

Thanks everyone for the valuable feedback. Few folks in the Ironic meeting agreed as well releasing often is better idea than git submodules, and we will go ahead with that if no one has any objection. On Wed, Jun 17, 2015 at 9:50 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-17

[openstack-dev] [Ironic] Vendor tools related to Ironic

Hi All, This is an informational mail for both vendor tool developers and Ironic community. For vendor tool developers - We decided the last week's Ironic meeting [1] that vendors who want to share tools/scripts related to Ironic, can do so in their own preferred way (personal github

Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state

My opinion: - If a new API is desirable by operators who would like to skip a few steps in Ironic before making it active, then we should do it. I mean we should allow them to skip the enroll state and manageable state, thereby giving them an opportunity to land the node in manageable or

Re: [openstack-dev] [Ironic] Was there a meeting yesterday (August 4, 2015 at 0500 UTC)

There wasn't one. Some of us waited in the meeting room to see if someone turns up, but I just got very very few (almost none) responses. On Wed, Aug 5, 2015 at 7:02 PM, Michael Davies mich...@the-davies.net wrote: Only a few people turned up (including me who was late) so no meeting was

Re: [openstack-dev] [Ironic] Let's talk about API versions

Thanks for giving me a chance to vote. I don't have any experience talking to production/live Ironic using a client and only talk to my own devstack. Personally I vote for a *no* (for such a 1.12) the reasons that have been cited in the previous threads that 1) we need users to be aware of API

Re: [openstack-dev] [ironic] [neutron] Enforce port/portgroup MAC uniqueness constraint

My vote is for the intermediate table to store the MAC address and enforce unique constraint on the mac address field. No need of extra triggers when it can be solved in a simple way and no need to add extra code to handle it. On Tue, Oct 20, 2015 at 5:08 AM, William Stevenson

[openstack-dev] [Ironic] Driver documentation in Ironic

Hi All, This mail is related to driver-specific documentation in Ironic. First a bit of context. I work on iLO drivers in Ironic. Our team would like to document both Ironic driver related stuff (which is related to Ironic) and hardware related stuff like tested platforms, firmware information,

Re: [openstack-dev] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

Well it's nice to fix, but I really don't know if we should be fixing it. As discussed in one of the Ironic meetings before, we might need to define what is our driver API or SDK or DDK or whatever we choose to call it . Please see inline for my thoughts. On Tue, Oct 6, 2015 at 5:54 AM, Devananda

Re: [openstack-dev] [ironic] Nominating two new core reviewers

My +2 for both jlvillal and vdrok .. Thanks a lot for all your work in Ironic and welcome to ironic-core. Cheers :) On Fri, Oct 9, 2015 at 3:17 AM, Jim Rollenhagen wrote: > Hi all, > > I've been thinking a lot about Ironic's core reviewer team and how we might > make

Re: [openstack-dev] [Ironic] Stepping down from IPA core

Josh, we will surely miss you in Ironic :(. Thanks for all the work and all the best on your new job. On Mon, Sep 21, 2015 at 9:19 PM, Josh Gachnang wrote: > Hey y'all, it's with a heavy heart I have to announce I'll be stepping > down from the IPA core team on Thurs,