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

[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] 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 rlooya...@gmail.com wrote:




 On 17 August 2015 at 20:20, Robert Collins robe...@robertcollins.net
 wrote:

 On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com 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 be consistent with v1.11+
 or
 ?


 2. What would it mean to set the initial provision state to something
 other than 'enroll'?

 manageable
 
 In our state machinery[0], a node 

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 mich...@the-davies.net
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 rlooya...@gmail.com 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 j...@jimrollenhagen.com
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 fu...@yuggoth.org 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 lucasago...@gmail.com
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 dtant...@redhat.com 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 dtant...@redhat.com 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 ante...@anteaya.info 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/vendor/ 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

[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/vendor/ 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 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 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 ifar...@redhat.com 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 cl...@fewbar.com 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
http://10.105.214.179:6385/v1/nodes/2d70d135-85b5-4f75-b741-0ead90a42b29/vendor_passthru/get_firmware_info




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: html\n head\n  title404 Not Found/title\n
 /head\n body\n  h1404 Not Found/h1\n  The resource could not be
 found.br /br /\n\n\n\n /body\n/html}


 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 cl...@fewbar.com 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 lhcxx0...@gmail.com 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