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

[Ramakrishnan G]

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,
>
> In reference to comments on a patchset[1], port/portgroup addresses
> should be unique. Please also see the irc log[1] which includes
> earlier discussion regarding rationale.
>
> Q: How can we enforce this uniqueness across tables?
>
>
> [1]
> https://review.openstack.org/#/c/206232/26/ironic/db/sqlalchemy/alembic/versions/5ea1b0d310e_added_port_group_table_and_altered_ports.py
> [2] http://ix.io/luF/irc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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, firmware issues, etc (which is not related to Ironic) in the
documentation. Today we keep it at two places - ironic related one in
ironic tree and (ironic + non-ironic) related one in wiki. It's hard for
both people who work on documentation and people who read this
documentation to update/refer information in two places.  Hence we decided
to raise the review [0] to move the content completely to wiki.  It got
mixed response.  While some people are okay with it, but some others
(including our ptl :)) feel it's worth putting it in-tree and try to
address the problems.

So what all are the problems ?
1) Ability to update the driver documentation not-related to Ironic easily
without waiting.
2) To save some core reviewers time who might not be familiar with the
hardware.

To solve the actual problem of updating the documentation easily while
keeping it in-tree, I checked with infra folks if a subset of a repository
can be +2ed/+Aed by another group.  They confirmed it's not possible
(unless there was a communication gap in that conversation, folks can
correct me if I am wrong).

The following are the options that I can think of to address this:

1) Easy approvals for patches solely related to driver documentation. Once
the driver team feels the documentation is ready, it can be +Aed by a core
team member skipping the normal process of review. Of course, fixing any
comments that come by, but not waiting for the normal rule of 2x+2s.

2) A separate repository for driver documentation controller by driver
developers (a bad idea ??)

3) Allow to push driver documentation to wiki for those who wish to.

Thoughts ???

[0] https://review.openstack.org/#/c/225602/

Regards,
Ramesh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 grow the team more through trust and mentoring. We should be
> able to promote someone to core based on a good knowledge of *some* of
> the code base, and trust them not to +2 things they don't know about. I'd
> also like to build a culture of mentoring non-cores on how to review, in
> preparation for adding them to the team. Through these pieces, I'm hoping
> we can have a few rounds of core additions this cycle.
>
> With that said...
>
> I'd like to nominate Vladyslav Drok (vdrok) for the core team. His reviews
> have been super high quality, and the quantity is ever-increasing. He's
> also started helping out with some smaller efforts (full tempest, for
> example), and I'd love to see that continue with larger efforts.
>
> I'd also like to nominate John Villalovos (jlvillal). John has been
> reviewing a ton of code and making a real effort to learn everything,
> and keep track of everything going on in the project.
>
> Ironic cores, please reply with your vote; provided feedback is positive,
> I'd like to make this official next week sometime. Thanks!
>
> // jim
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 van der Veen <
devananda@gmail.com> wrote:

> tldr; the boot / deploy interface split we did broke an out of tree
> driver. I've proposed a patch. We should get a fix into stable/liberty too.
>
> Longer version...
>
> I was rebasing my AMTTool driver [0] on top of master because the in-tree
> one still does not work for me, only to discover that my driver suddenly
> failed to deploy. I have filed this bug
>   https://bugs.launchpad.net/ironic/+bug/1502980
> because we broke at least one out of tree driver (mine). I highly suspect
> we've broken many other out of tree drivers that relied on either the
> PXEDeploy or AgentDeploy interfaces that were present in Kilo release. Both
> classes in Liberty are making explicit calls to "task.driver.boot" -- and
> kilo-era driver classes did not define this interface.
>


I would like to think more about what really our driver API is ? We have a
couple of well defined interfaces in ironic/drivers/base.py which people
may follow, implement an out-of-tree driver, make it a stevedore entrypoint
and get it working with Ironic.

But

1) Do we promise them that in-tree implementations of these interfaces will
always exist.  For example in boot/deploy work done in Liberty, we removed
the class PxeDeploy [1].  It actually got broken down to PXEBoot and
ISCSIDeploy.  In the first place, do we guarantee that they will exist for
ever in the same place with the same name ? :)

2) Do we really promise the in-tree implementations of these interfaces
will behave the same way ? For example, the broken stuff AgentDeploy which
is an implementation of our DeployInterface.  Do we guarantee that this
implementation will always keep doing what ever it was every time code is
rebased ?

[1] https://review.openstack.org/#/c/166513/19/ironic/drivers/modules/pxe.py



>
> I worked out a patch for the AgentDeploy driver and have proposed it here:
>   https://review.openstack.org/#/c/231215/1
>
> I'd like to ask folks to review it quickly -- we should fix this ASAP and
> backport it to stable/liberty before the next release, if possible. We
> should also make a similar fix for the PXEDeploy class. If anyone gets to
> this before I do, please reply here and let me know so we don't duplicate
> effort.
>


This isn't going to be as same as above as there is no longer a PXEDeploy
class any more.  We might need to create a new class PXEDeploy which
probably inherits from ISCSIDeploy and has task.driver.boot worked around
in the same way as the above patch.



>
> Also, Jim already spotted something in the review that is a bit
> concerning. It seems like the IloVirtualMediaAgentVendorInterface class
> expects the driver it is attached to *not* to have a boot interface and
> *not* to call boot.clean_up_ramdisk. Conversely, other drivers may be
> expecting AgentVendorInterface to call boot.clean_up_ramdisk -- since that
> was its default behavior in Kilo. I'm not sure what the right way to fix
> this is, but I lean towards updating the in-tree driver so we remain
> backwards-compatible for out of tree drivers.
>
>
> -Devananda
>
> [0] https://github.com/devananda/ironic/tree/new-amt-driver
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 Rackspace for a
> healthcare startup (Triggr Health) and won't have the time to dedicate to
> being an effective OpenStack reviewer.
>
> Ever since the OnMetal team proposed IPA all the way back in the
> Icehouse midcycle, this community has been welcoming, helpful, and all
> around great. You've all helped me grow as a developer with your in depth
> and patient reviews, for which I am eternally grateful. I'm really sad I
> won't get to see everyone in Tokyo.
>
> I'll still be on IRC after leaving, so feel free to ping me for any reason
> :)
>
> - JoshNang
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 "available" state
by default.

- Default state (by default) should be "enroll" as that's where the state
of a node in Ironic begins. May be optionally it can be tweaked in
ironic.conf.

- I don't like the idea to land a node directly in active state.  The main
reason being it differs from driver to driver, what it takes to bring a
node to active and what is required for a take over for the active node.
For example, while deploying a partition image (by pxe or virtual media
drivers), the uuid of the root partition should be available in the
driver_internal_info for take_over to happen.  So, it would mean that even
for existing drivers, we would need to at least provide a mechanism for
writing driver_internal_info from the API which is not desirable.  It is
very much a valid use case to do import.  From first thought, I think we
should have a new API endpoint to request such an import and a new method
in DeployInterface (not an abstract method) for importing bare metals from
another system.  The API should allow parameters to be passed from the
driver to do the import, optionally requesting to reboot the bare metal
after it is imported (to make sure that Ironic can properly manage the node
again).  The new method in DeployInterface should do what it takes to
import the bare metal given the parameters.  But, that might be a different
story :).

Regards,
Ramesh

On Wed, Aug 19, 2015 at 5:35 AM, Ruby Loo  wrote:

>
>
>
>>> On 17 August 2015 at 20:20, Robert Collins 
>>> wrote:
>>>
 On 11 August 2015 at 06:13, Ruby Loo  wrote:
 > Hi, sorry for the delay. I vote no. I understand the rationale of
 trying to
 > do things so that we don't break our users but that's what the
 versioning is
 > meant for and more importantly -- I think adding the ENROLL state is
 fairly
 > important wrt the lifecycle of a node. I don't particularly want to
 hide
 > that and/or let folks opt out of it in the long term.
 >
 > From a reviewer point-of-view, my concern is me trying to remember
 all the
 > possible permutations/states etc that are possible to make sure that
 new
 > code doesn't break existing behavior. I haven't thought out whether
 adding
 > this new API would make that worse or not, but then, I don't really
 want to
 > have to think about it. So KISS as much as we can! :)

 I'm a little surprised by this, to be honest.

 Here's why: allowing the initial state to be chosen from
 ENROLL/AVAILABLE from the latest version of the API is precisely as
 complex as allowing two versions of the API {old, new} where old
 creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
 difference I can see is that eventually someday if {old} stops being
 supported, then and only then we can go through the code and clean
 things up.

 It seems to me that the costs to us of supporting graceful transitions
 for users here are:

 1) A new version NEWVER of the API that supports node state being one
 of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
 AVAILABLE when not supplied.
 2) Supporting the initial state of AVAILABLE indefinitely rather than
 just until we *delete* version 1.10.
 3) CD deployments that had rolled forward to 1.11 will need to add the
 state parameter to their scripts to move forward to NEWVER.
 4) Don't default the client to the veresions between 1.10 and NEWVER
 versions at any point.

 That seems like a very small price to pay on our side, and the
 benefits for users are that they can opt into the new functionality
 when they are ready.

 -Rob
>>>
>>>
> 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 that
> enroll state exists :)
>
> Earlier today on IRC, Devananda mentioned that "there's a very strong case
> for allowing a node to be created in any of the stable states (enroll,
> manageable, available, active)". Maybe he'll elaborate later on this. I
> know that there's a use case where there is a desire to import nodes (with
> instances on them) from another system into ironic, and have them be active
> right away. (They don't want the nodes to go from
> enroll->verifying->manageable->cleaning!!!->available!!!->active).
>
> 1. What would the default provision state be, if it wasn't specified?
> A. 'available' to be backwards compatible with pre-v1.11
> or
> B. 'enroll' to b

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

[Ramakrishnan G]

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 or
stackforge/openstack github repositories ((provided it gets accepted))).
Such vendor tools can be listed in Ironic wiki[3].  These vendor tools will
not be reviewed/maintained by the Ironic community.

For Ironic community - After having taken the action item for wikifying
them, I have just written down wiki pages ([2] and [3]), and linked them to
the main page of our wiki[4].  This just captures what we discussed in the
meeting, plus a bit of additions from my side.  Please feel free to discuss
and edit them as required.

[1]
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-08-17-17.00.log.txt
[2] https://wiki.openstack.org/wiki/Ironic/ThirdPartyVendorToolsDeveloperDoc
[3] https://wiki.openstack.org/wiki/Ironic/ThirdPartyVendorToolsList
[4] https://wiki.openstack.org/wiki/Ironic

Thanks.

Regards,
Ramesh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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,
>
> Michael...
>
> On Wed, Aug 5, 2015 at 10:43 PM, Ruby Loo  wrote:
>
>> Hi,
>>
>> Was there an ironic meeting yesterday (August 4, 2015 at 0500 UTC)? I
>> don't see any meeting logs from then.
>>
>> --ruby
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Michael Davies   mich...@the-davies.net
> Rackspace Cloud Builders Australia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 versions (so I also would want them to
pin it if they wanted a stable one, so don't default in their automation
and keep testing and updating to the newer api versions)
2) it's already released, and i also tend to consider anything released
could already being used right now


On Tue, Aug 4, 2015 at 9:50 PM, Jim Rollenhagen 
wrote:

> On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:
> >
> > Now we've landed a patch[0] with a new version (1.11) that is not
> > backward compatible. It causes newly added Node objects to begin life in
> > the ENROLL state, rather than AVAILABLE. This is a good thing, and
> > people should want this! However, it is a breaking change. Automation
> > that adds nodes to Ironic will need to do different things after the
> > node-create call.
> >
> > Our API versioning scheme makes this opt-in (by specifying the API
> > version). However, some folks have a problem with releasing this change
> > as-is. The logic is that we might release a client that defaults to 1.11
> > or higher, or the user may request 1.12 later to get a new feature, thus
> > breaking their application that enrolls nodes.
>
> So after much deliberation, we took an informal vote in IRC this morning
> between 5 out of our 9 cores.
>
> The question was: "should we do a 1.12 api version that allows the user
> to pick begining provision state in (AVAILABLE, ENROLL), defaulting to
> AVAILABLE?"
>
> The results were 3 for no, 2 for yes. So that's the plan.
>
> Other Ironic cores (Haomeng, Yuriy, Ramesh, Ruby): please chime in if
> you have opinions on this. :)
>
> Otherwise we'll be getting to work on releasing a server as-is in the
> next few days.
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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), Doug Hellmann wrote:
> > Excerpts from Ramakrishnan G's message of 2015-06-17 12:50:25 +0530:
> > > 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
> > > subscribed projects [1].  Sounds like that should be better instead of
> > > making a new release of ironic-lib and waiting for it to be published
> to
> > > make changes in Ironic or Ironic-python-agent.
> >
> > Please don't do this. It's similar to the incubator model used in Oslo,
> > but the benefits there (being able to evolve the API of code formerly
> > tightly coupled to an application) don't apply here. You're writing new
> > code, and can create a library directly. Releasing libraries is easy. We
> > do it often enough that people complain about the extra email.
> [...]
>
> Also, while the software we use does support Git submodules, our
> infrastructure admins are not supporting use of Git submodules in
> projects we host for a variety of reasons. The benefits of a
> submodule over a completely separate Git repository are slim, and
> usually a sign that you're working around poor design in the
> involved repos. Further, submodules pose significant potential for
> confusion among developers, especially those for whom this is their
> first experience interacting with Git--it's confusing enough--we
> should strive to keep things as simple as possible for them when the
> cost of doing so is not particularly high.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 the process of writing a new implementation of
DeployInterface for a driver in Ironic
* If you have a fully working implementation of DeployInterface that you
are planning to upstream

If you don't belong to any of the above, this mail shouldn't concern you as
such, and you may skip reading this.  But it might be worth reading.

*What is boot/deploy interface ?*

The reasoning for boot/deploy interfaces is explained in the spec:
http://specs.openstack.org/openstack/ironic-specs/specs/liberty/new-boot-interface.html

This is mainly to make it easy to add new drivers by abstracting the boot
and deploy functions separately.  The specification should explain problem
and proposed change in detail.

*How does this concern you ?*

* *If you have an out of the tree driver for Ironic*

We *are not *breaking/changing any of the existing interfaces in Ironic.  A
completely out of the tree implementation of DeployInterface should still
work fine (by complete, I mean an implementation that is not dependent on
any of the upstream implementations).  However, if you had created your own
out of the tree implementation of DeployInterface by extending from one of
the upstream implementations of it (for example, extending from
ironic.driver.modules.pxe.PXEDeploy), then your code might break.  Please
follow-up with the patches for the blueprint that are being/will be
proposed.

* *If you are in the process of writing a new implementation of
DeployInterface for a driver in Ironic*

You might want to check if your implementation of DeployInterface can be
broken down into a separate boot and deploy interfaces.  This is not *mandated
*but will be the recommended way going forward.

* *If you have a fully working implementation of DeployInterface that you
are planning to upstream*

Again just like above, it is recommended to separate boot and deploy
interfaces if it's applicable to your deploy mechanism.  All upstream
drivers will be changed to this model soon.

If you have any questions, feel free to reply back to this mail or follow
up with the Ironic community on this in the IRC channel #openstack-ironic.

Thanks.

Regards,
Ramesh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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
subscribed projects [1].  Sounds like that should be better instead of
making a new release of ironic-lib and waiting for it to be published to
make changes in Ironic or Ironic-python-agent.

[1] https://review.openstack.org/Documentation/user-submodules.html


On Tue, Jun 16, 2015 at 9:24 PM, Lucas Alvares Gomes 
wrote:

> Hi,
>
> > I haven't paid any attention to ironic-lib; I just knew that we wanted to
> > have a library of common code so that we didn't cut/paste. I just took a
> > look[1] and there are files there from 2 months ago. So far, everything
> is
> > under ironic_lib (ie, no subdirectories to group things). Going forward,
> are
> > there guidelines as to where/what goes into this library?
>
> I don't think we have guidelines for the struct of the project, we
> should of course try to organize it well.
>
> About what goes into this library, AFAICT, this is place where code
> which is used in more than one project under the Ironic umbrella
> should go. For example, both Ironic and IPA (ironic-python-agent)
> deals with disk partitioning, so we should create a module for disk
> partitioning in the ironic-libs repository which both Ironic and IPA
> will import and use.
>
>
> > I think it would be good to note down the process wrt using this library.
> > I'm guessing that having this library will most certainly delay things
> wrt
> > development. Changes will need to be made to the library first, then
> need to
> > wait until a new version is released, then possibly update the min
> version
> > in global-requirements, then use (and profit) in ironic-related projects.
> >
> >
> > With the code in ironic, we were able to do things like change the
> arguments
> > to methods etc. With the library -- do we need to worry about backwards
> > compatibility?
>
> I would say so, those are things that we have to take in account when
> creating a shared library. But it also brings benefits:
>
> 1. Code sharing
> 2. Bug are fixed in one place only
> 3. Flexibility, I believe that more projects using the same code will
> require it to be more flexible
>
> > How frequently were we thinking of releasing a new version? (Depends on
> > whether anything was changed there that is needed really soon?)
>
> Yes, just like the python-ironicclient a release can be cut when needed.
>
> Thanks for starting this thread, it would be good to the community
> evaluate whether we should go forward with ironic-libs or not.
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 branched
out code.  To avoid repeated efforts of such syncing, I suggest we sync the
latest code from Ironic to ironic-lib (in appropriate files) and
immediately change Ironic to start using it.

I suggest we can do the following:
1) Decide on a timeline for the change (1 or 2 days)
2) Stop +Aing changes in Ironic to the files/code being moved to ironic-lib
3) Sync the latest code in ironic-lib and merge it
4) Make a new release of ironic-lib
5) Make changes in Ironic to use ironic-lib and make sure gate is back up
and running again (I can't think of anything that will break gate on
switching to ironic-lib as it's just a pip install)
6) Make new reviews in ironic-lib for any pending reviews in Ironic

If we come to an agreement on #1 and #2 above, Syed Ismail Faizan Barmawer
can continue to work on #3 - #5

Let me know if it will work out or if there are any better plans (or I am
missing something)

Thanks.

[1] https://github.com/openstack/ironic-lib
[2] https://review.openstack.org/#/c/162162/

Regards,
Ramesh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 is wait-call-back (by doing set-provision-state deleted).

I guess same can apply for inband inspection which requirs node to be
booted up.  It should be reasonable to allow people (for debugging) to
abort it during this time.

+1 from me for doing in similar lines - allow inband inspection to be
aborted if discoverd is waiting for a callback from the node.

This should cover a big chunk of time in a real bare metal.


On Tue, Apr 21, 2015 at 5:12 PM, Dmitry Tantsur  wrote:

> Hi folks.
>
> Recently I got several requests to implement API aborting introspection in
> discoverd. This is useful mostly when debugging, when you know that
> introspection has failed, and you want to stop it right now. I've put a
> blueprint
> https://blueprints.launchpad.net/ironic-discoverd/+spec/abort-introspection
> to track it.
>
> Such API would cause discoverd to set error state for the node immediately
> and issue a power off request for it. The technical side is not a big deal.
>
> What I'm worried about is whether we want to introduce such a feature at
> all. Some Ironic processes (deploy, in-band cleaning) are async as well,
> they also may hang, and IIUC we don't have means of aborting them. Does
> debugging justify introducing new API?
>
> This looks somewhat similar to our discussion about breaking locks in
> Ironic: it might be useful, but it's an API which we'll support and which
> can be easily misused.
>
> But with introspection the only case where lack of this feature can't be
> easily worked around is when people want to recreate a node. I've been
> arguing for some time that recreating a node is not a good way to solve
> problems. In other cases one can just power off the node via Ironic API and
> restart the introspection again afterwards.
>
> What do you think?
>
> Cheers,
> Dmitry
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

+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 v1.6,
shouldn't the behaviour of the 0.x.x python-ironicclient be that, newly
enroll nodes have provision_state as NOSTATE again instead of AVAILABLE ?


On Fri, Apr 3, 2015 at 1:59 PM, Dmitry Tantsur  wrote:

> Hi all!
>
> Today I got an internal email, stating that new ironicclient brakes
> ironic-discoverd. Indeed, after rebase to the latest ironicclient git
> master, discoverd started receiving "AVAILABLE" state instead of "None" for
> newly enrolled nodes. It's not a valid state for introspection, valid are
> "MANAGEABLE" (discoverd stand-alone usage), "INSPECTING" (discoverd via
> Ironic driver) and None (Juno + discoverd stand-alone). Looks like despite
> introducing microversions we did manage to break 3rdparty apps relying on
> states... Also we're in a bit weird situation where nodes appear ready for
> scheduling, despite us having a special state for managing nodes _before_
> being ready for scheduling.
>
> I find the situation pretty confusing, and I'd like your comments on the
> following proposal to be implemented before RC1:
>
> 1. add new micro-version 1.7. nodes created by API with this version will
> appear in state MANAGEABLE;
> 2. make a client release with current API version set to 1.6 (thus
> excluding change #1 from users of this version);
> 3. set current API version for ironicclient to 1.7 and release
> ironicclient version 2.0.0 to designate behavior changes;
> 4. document the whole thingy properly
>
> #1 should be a small change, but it definitely requires FFE.
> Thoughts?
>
> Dmitry
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 hardware which supports UEFI.
> Ironic added support for UEFI in Juno. This is an incremental improvement,
> allowing those users to benefit more from their hardware's security
> features.
>
> After this morning's final round of reviews to get features in, we agreed
> to
> defer the pxe_ilo driver changes, as those are the highest risk component
> of
> the secure boot blueprint, but grant a short extension for the other two
> drivers (iscsi_ilo and agent_ilo) which do not require PXE booting.
>
> The remaining changes are already either approved or very close to, and
> we're
> confident this can be landed in the next couple days without impact
> outside of
> those drivers.
>
> As such, I have blocked the pxe_ilo patch [1], retargeted the blueprint to
> RC1,
> and am granting an exception for those drivers. I'll re-review the status
> of
> this on Monday, March 23rd.
>
> [0] https://blueprints.launchpad.net/ironic/+spec/uefi-secure-boot
>
> [1] https://review.openstack.org/#/c/159322/
>
> - -Devananda
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iEYEARECAAYFAlUK/woACgkQhFvuBniJg6demgCgxiSlIAPPSqNwUK8gGo2qOpxF
> gsEAoM65a5bTlBlaPKOKfpcJsN67INnW
> =bdk6
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

> You may not realize you do a disservice to those reading this post and
> those reviewing future patches if you set unreasonable expectations.

> Telling others that they can expect a patch merged in the same day is
> not reasonable, even if that has been your experience. While we do our
> best to keep current, we all are very busy and requests for repos are
> increasing. If folks want a repo they can submit a patch to create one,
> here is a good guide:
> http://docs.openstack.org/infra/manual/creators.html and it will be
> reviewed along with all other patches to project-config.

Anita,

Thanks for correcting me.  Yeah, I just quoted *my experience with
openstack-infra *blindly.  Sorry for that.

Rather I also wanted to point out to our folks, things in infra are so
automated that putting an openstack-related module into stackforge has been
become fully automatic 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 wrote:
> > 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 cannot understand unless they go and read the hardware
> > manuals of the vendor hardware about what is being done.  Otherwise we
> just
> > need to blindly mark the file as reviewed.
> >
> > Now let me pitch in with our story about this.  We added a vendor driver
> > for HP Proliant hardware (the *ilo drivers in Ironic).  Initially we
> > proposed this same thing in Ironic that we will add all the hardware
> > specific code in Ironic itself under the directory drivers/modules/ilo.
> > But few of the Ironic folks didn't agree on this (Devananda especially
> who
> > is from my company :)). So we created a new module proliantutils, hosted
> in
> > our own github and recently moved it to stackforge.  We gave a limited
> set
> > of APIs for Ironic to use - like get_host_power_status(),
> set_host_power(),
> > get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here
> >
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py
> > ).
> >
> > We have only seen benefits in doing it.  Let me bring in some examples:
> >
> > 1) We tried to add support for some lower version of servers.  We could
> do
> > this without making any changes in Ironic (Review in proliantutils
> > https://review.openstack.org/#/c/153945/)
> > 2) We are adding support for newer models of servers (earlier we use to
> > talk to servers in protocol called RIBCL, newer servers we will use a
> > protocol called RIS) - We could do this with just 14 lines of actual code
> > change in Ironic (this was needed mainly because we didn't think we will
> > have to use a new protocol itself when we started) -
> > https://review.openstack.org/#/c/154403/
> >
> > Now talking about the advantages of putting hardware-specific code in
> > Ironic:
> >
> > *1) It's reviewed by Openstack community and tested:*
> > No. I doubt if I throw in 600 lines of new iLO specific code that is
> here (
> >
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py
> )
> > for Ironic folks, they will hardly take a look at it.  And regarding
> > testing, it's not tested in the gate unless we have a 3rd party CI for
> it.
> >  [We (iLO drivers) also don't have 3rd party CI right now, but we are
> > working on it.]
> >
> > *2) Everything gets packaged into distributions automatically:*
> > Now the hardware-specific code that we add in Ironic under
> > drivers/modules// will get packaged into distributions, but this
> > code in turn will have dependencies  which needs to be installed manually
> > by the operator (I assume vendor specific dependencies are not considered
> > by Linux distributions while packaging Openstack Ironic). Anyone
> installing
> > Ironic and wanting to manage my company's servers will again need to
> > install these dependencies manually.  Why not install the wrapper if
> there
> > is one too.
> >
> > I assume we only get these advantages by moving all of hardware-specific
> > code to a wrapper module in stackforge and just exposing some APIs for
> > Ironic to use:
&g

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

[Ramakrishnan G]

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 cannot understand unless they go and read the hardware
manuals of the vendor hardware about what is being done.  Otherwise we just
need to blindly mark the file as reviewed.

Now let me pitch in with our story about this.  We added a vendor driver
for HP Proliant hardware (the *ilo drivers in Ironic).  Initially we
proposed this same thing in Ironic that we will add all the hardware
specific code in Ironic itself under the directory drivers/modules/ilo.
But few of the Ironic folks didn't agree on this (Devananda especially who
is from my company :)). So we created a new module proliantutils, hosted in
our own github and recently moved it to stackforge.  We gave a limited set
of APIs for Ironic to use - like get_host_power_status(), set_host_power(),
get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here
https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py
).

We have only seen benefits in doing it.  Let me bring in some examples:

1) We tried to add support for some lower version of servers.  We could do
this without making any changes in Ironic (Review in proliantutils
https://review.openstack.org/#/c/153945/)
2) We are adding support for newer models of servers (earlier we use to
talk to servers in protocol called RIBCL, newer servers we will use a
protocol called RIS) - We could do this with just 14 lines of actual code
change in Ironic (this was needed mainly because we didn't think we will
have to use a new protocol itself when we started) -
https://review.openstack.org/#/c/154403/

Now talking about the advantages of putting hardware-specific code in
Ironic:

*1) It's reviewed by Openstack community and tested:*
No. I doubt if I throw in 600 lines of new iLO specific code that is here (
https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py)
for Ironic folks, they will hardly take a look at it.  And regarding
testing, it's not tested in the gate unless we have a 3rd party CI for it.
 [We (iLO drivers) also don't have 3rd party CI right now, but we are
working on it.]

*2) Everything gets packaged into distributions automatically:*
Now the hardware-specific code that we add in Ironic under
drivers/modules// will get packaged into distributions, but this
code in turn will have dependencies  which needs to be installed manually
by the operator (I assume vendor specific dependencies are not considered
by Linux distributions while packaging Openstack Ironic). Anyone installing
Ironic and wanting to manage my company's servers will again need to
install these dependencies manually.  Why not install the wrapper if there
is one too.

I assume we only get these advantages by moving all of hardware-specific
code to a wrapper module in stackforge and just exposing some APIs for
Ironic to use:
* Ironic code would be much cleaner and easier to maintain
* Any changes related to your hardware - support for newer hardware, bug
fixes in particular models of hardware, would be very easy. You don't need
to change Ironic code for that. You could just fix the bug in your module,
release a new version and ask your users to install a newer version of the
module.
* python-fooclient could be used outside Ironic to easily manage foo
servers.
* Openstack CI for free if you are in stackforge - unit tests, flake tests,
doc generation, merge, pypi release everything handled automatically.

I don't see any disadvantages.

Now regarding the time taken to do this, if you have all the code ready now
in Ironic (which assume you will already have), perhaps it will take a day
to do this - half a day for putting into a separate module in python/github
and half a day for stackforge. The request to add stackforge should get
approved in the same day (if everything is all-right).

Let me know all of your thoughts on this.  If we agree, I feel we should
have some documentation on it in our Ironic docs directory.

Thanks for reading :)

Regards,
Ramesh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 common interface for doing RAID configuration which can be used
for both drivers for now, and may be followed by any driver later on who
wishes to implement RAID configuration.

In the changes proposed in the spec, the driver should be able to figure
out the disks to be used for creating RAID on the machine, when some hints
are given by the operator to Ironic.  The hints help Ironic to figure out
what disks should be used for creating RAID.  Initially we started with a
few (namely disk type (ssd vs hdd) and interface type (scsi vs sata vs
...), etc.  But later on due to request from some other folks to include
some more criterias (namely filter disks based on inputs on model, firmware
version, vendor due to various reasons), we added it to the list of hints.

Now, we have
* some set of folks *who don't want *model, firmware version, vendor as
criteria because if they are added, every driver would need to implement
them.
* some set of folks *who want *model, firmware version, vendor as criteria
because there are practical use-cases in an environment.

We have confirmed that filtering based on model, firmware version and
vendor can be done on both HP and DRAC hardware for now.

I would like to hear everyone's thoughts and probably reach a conclusion of
whether be open to include more criteria or not.

Please pour in your thoughts on the thread

Regards,
Ramakrishnan (irc: rameshg87)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

+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 allow us to composite
> a driver to do it (which is ur use case 2. ).
>
> So, +1.
>
> Lucas
>
> On Wed, Nov 26, 2014 at 3:45 PM, Imre Farkas  wrote:
>
>> On 11/26/2014 02:20 PM, Dmitry Tantsur wrote:
>>
>>> Hi all!
>>>
>>> As our state machine and discovery discussion proceeds, I'd like to ask
>>> your opinion on whether we need an IntrospectionInterface
>>> (DiscoveryInterface?). Current proposal [1] suggests adding a method for
>>> initiating a discovery to the ManagementInterface. IMO it's not 100%
>>> correct, because:
>>> 1. It's not management. We're not changing anything.
>>> 2. I'm aware that some folks want to use discoverd-based discovery [2]
>>> even for DRAC and ILO (e.g. for vendor-specific additions that can't be
>>> implemented OOB).
>>>
>>> Any ideas?
>>>
>>> Dmitry.
>>>
>>> [1] https://review.openstack.org/#/c/100951/
>>> [2] https://review.openstack.org/#/c/135605/
>>>
>>>
>> Hi Dmitry,
>>
>> I see the value in using the composability of our driver interfaces, so I
>> vote for having a separate IntrospectionInterface. Otherwise we wouldn't
>> allow users to use eg. the DRAC driver with an in-band but more powerful hw
>> discovery.
>>
>> Imre
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 which you can poll.
https://github.com/openstack/ironic/blob/master/etc/ironic/ironic.conf.sample#L527-L531




On Sat, Aug 23, 2014 at 12:04 AM, Clint Byrum  wrote:

> Excerpts from Jay Pipes's message of 2014-08-22 11:16:05 -0700:
> > On 08/22/2014 01:48 PM, Clint Byrum wrote:
> > > It has been brought to my attention that Ironic uses the biggest hammer
> > > in the IPMI toolbox to control chassis power:
> > >
> > >
> https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142
> > >
> > > Which is
> > >
> > >  ret = ipmicmd.set_power('off', wait)
> > >
> > > This is the most abrupt form, where the system power should be flipped
> > > off at a hardware level. The "short press" on the power button would be
> > > 'shutdown' instead of 'off'.
> > >
> > > I also understand that this has been brought up before, and that the
> > > answer given was "SSH in and shut it down yourself." I can respect that
> > > position, but I have run into a bit of a pickle using it. Observe:
> > >
> > > - ssh box.ip "poweroff"
> > > - poll ironic until power state is off.
> > >- This is a race. Ironic is asserting the power. As soon as it sees
> > >  that the power is off, it will turn it back on.
> > >
> > > - ssh box.ip "halt"
> > >- NO way to know that this has worked. Once SSH is off and the
> network
> > >  stack is gone, I cannot actually verify that the disks were
> > >  unmounted properly, which is the primary area of concern that I
> > >  have.
> > >
> > > This is particulary important if I'm issuing a rebuild + preserve
> > > ephemeral, as it is likely I will have lots of I/O going on, and I want
> > > to make sure that it is all quiesced before I reboot to replace the
> > > software and reboot.
> > >
> > > Perhaps I missed something. If so, please do educate me on how I can
> > > achieve this without hacking around it. Currently my workaround is to
> > > manually unmount the state partition, which is something system
> shutdown
> > > is supposed to do and may become problematic if system processes are
> > > holding it open.
> > >
> > > It seems to me that Ironic should at least try to use the graceful
> > > shutdown. There can be a timeout, but it would need to be something a
> user
> > > can disable so if graceful never works we never just dump the power on
> the
> > > box. Even a journaled filesystem will take quite a bit to do a full
> fsck.
> > >
> > > The inability to gracefully shutdown in a reasonable amount of time
> > > is an error state really, and I need to go to the box and inspect it,
> > > which is precisely the reason we have ERROR states.
> >
> > What about placing a runlevel script in /etc/init.d/ and symlinking it
> > to run on shutdown -- i.e. /etc/rc0.d/? You could run fsync or unmount
> > the state partition in that script which would ensure disk state was
> > quiesced, no?
>
> That's already what OS's do in their rc0.d.
>
> My point is, I don't have any way to know that process happened, without
> the box turning itself off after it succeeded.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 check if the above works for you ?

If not, I guess trying you can try a GET on the node to check if the GET
listing atleast works.
curl -i -X GET -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





On Fri, Jun 6, 2014 at 2:14 PM, Gopi Krishna Saripuri <
saripurig...@outlook.com> 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://10.105.214.179:6385/v1/nodes/2d70d135-85b5-4f75-b741-0ead90a42b29/vendor_passthru/get_firmware_info
>
> fails with
>
> {"error_message": "\n \n  404 Not Found\n
> \n \n  404 Not Found\n  The resource could not be
> found.\n\n\n\n \n"}
>
>
> Is there a way to test vendor_passthru from ironic cli, also I didn't see
> any support for this in python-ironicclient?
>
> I'm able to retrieve chassis/nodes/ports. But while testing
> vendor_passthru method, it is failing with 404 error.
>
> Can someone help me with testing the vendor_passthru methods.
>
> Regards
> Gopi Krishna S
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ramesh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 *"disk-image-create" *command.  Something
like
*disk-image-create fedora*

As Clint said, there is root login from console is disabled.  Another
alternative is you can use the local-config element while running
"disk-image-create" so that you can do a root login from the system where
you build the deploy image.  The local-config will add the ssh keys of the
current user building the image to the root user on the cloud image.




On Thu, Jun 5, 2014 at 10:22 AM, Clint Byrum  wrote:

> Excerpts from 严超's message of 2014-06-04 20:34:01 -0700:
> > BTW, If I run "sudo ./bin/disk-image-create -a amd64 ubuntu deploy-ironic
> > -o /tmp/deploy-ramdisk-ubuntu",
> > What is the username/password for image deploy-ramdisk-ubuntu ?
>
> There isn't one. You can write an element if you want to include a
> backdoor user. Otherwise, just use nova's SSH keypair capability when
> you deploy your image onto boxes.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ramesh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 devstack to set up a nova baremetal provision environment, but
> met one problems as below:
>
> when I use disk-image builder(
> https://github.com/openstack/diskimage-builder.git) command to build a
> image, there is no output file and the error message seems confused to me,I
> don't know what I should do next,  below is the output of the console.
>
> stack@helpme:~/diskimage-builder$ bin/disk-image-create -u base -o
> my-image
> Building elements: base  base
> Expanded element dependencies to: base
> Building in /tmp/image.LB2Dc8vH
> dib-run-parts Mon Apr 21 19:05:11 EDT 2014 Running
> /tmp/image.LB2Dc8vH/hooks/root.d/01-ccache
> dib-run-parts Mon Apr 21 19:05:11 EDT 2014 01-ccache completed
> --- PROFILING ---
>
> Target: root.d
>
> Script Seconds
> ---  --
>
> 01-ccache 0.042
>
> - END PROFILING -
> Please include at least one distribution root element.
> stack@helpme:~/diskimage-builder$ cd ~
>
>
> I think the wiki content both in Baremetal and Disk-image-builder is not
> latest updated.
>
> could someone point me how to give a try with this?
>
> thanks!!
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ramesh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ramakrishnan G]

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 wiki for ironic-python-agent below, but couldn't find
any information.
https://wiki.openstack.org/wiki/Ironic-python-agent

Could someone point me how to give a try with this.

Thanks.

-- 
Ramakrishnan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev