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
+1 for a separate interface.
On Fri, Nov 28, 2014 at 7:20 PM, Lucas Alvares Gomes
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 separated interface
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 comm
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 *"di
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 jus
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
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 wrote:
> Hi,
>
> I am following this wiki page(https://wiki.openstack.org/wiki/Baremetal), by
> using devs
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
wrote:
> Hi,
>
>
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 wrote:
> On 2015-06-17 10:10:22 -0400 (-0400
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 ve
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
wrote:
> Only a few people turned up (including me who was late) so no meeting was
> held.
>
> Hope this helps
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 repositories
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 "avai
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, 9/24. I'm leaving Rackspac
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
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 it better.
>
> I'd like to
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,
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 bra
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
subscri
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 th
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 folks
tomatic and easy *(easy 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 wrote:
> On 02/28/2015 01:28 AM, Ramakrishnan G wr
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 mod
+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 v
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
25 matches
Mail list logo