Re: [openstack-dev] [ironic] Stepping down as core

[Ruby Loo]

Sam,

Thank you so much for all your contributions to ironic! I'll miss you. I'm
glad you aren't disappearing though :)

--ruby

On Thu, Oct 11, 2018 at 4:41 AM Sam Betts (sambetts) 
wrote:

> As many of you will have seen on IRC, I've mostly been appearing AFK for
> the last couple of development cycles. Due to other tasks downstream most
> of my attention has been drawn away from upstream Ironic development. Going
> forward I'm unlikely to be as heavily involved with the Ironic project as I
> have been in the past, so I am stepping down as a core contributor to make
> way for those more involved and with more time to contribute.
>
> That said I do not intend to disappear, Myself and my colleagues plan to
> continue to support the Cisco Ironic drivers, we just won't be so heavily
> involved in core ironic development and its worth noting that although I
> might appear AFK on IRC because my main focus is on other things, I always
> have an ear to the ground and direct pings will generally reach me.
>
> I will be in Berlin for the OpenStack summit, so to those that are
> attending I hope to see you there.
>
> The Ironic project has been (and I hope continues to be) an awesome place
> to contribute too, thank you
>
> Sam Betts
> sambetts
>
>
> __
> 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][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes

[Ruby Loo]

What is there to say? ++ :) and :(.

--ruby

On Thu, Aug 23, 2018 at 2:24 PM Julia Kreger 
wrote:

> Greetings everyone!
>
> In our team meeting this week we stumbled across the subject of
> promoting contributors to be sub-project's core reviewers.
> Traditionally it is something we've only addressed as needed or
> desired by consensus with-in those sub-projects, but we were past due
> time to take a look at the entire picture since not everything should
> fall to ironic-core.
>
> And so, I've taken a look at our various repositories and I'm
> proposing the following additions:
>
> For sushy-core, sushy-tools-core, and virtualbmc-core: Ilya
> Etingof[1]. Ilya has been actively involved with sushy, sushy-tools,
> and virtualbmc this past cycle. I've found many of his reviews and
> non-voting review comments insightful and willing to understand. He
> has taken on some of the effort that is needed to maintain and keep
> these tools usable for the community, and as such adding him to the
> core group for these repositories makes lots of sense.
>
> For ironic-inspector-core and ironic-specs-core: Kaifeng Wang[2].
> Kaifeng has taken on some hard problems in ironic and
> ironic-inspector, as well as brought up insightful feedback in
> ironic-specs. They are demonstrating a solid understanding that I only
> see growing as time goes on.
>
> For sushy-core: Debayan Ray[3]. Debayan has been involved with the
> community for some time and has worked on sushy from early on in its
> life. He has indicated it is near and dear to him, and he has been
> actively reviewing and engaging in discussion on patchsets as his time
> has permitted.
>
> With any addition it is good to look at inactivity as well. It saddens
> me to say that we've had some contributors move on as priorities have
> shifted to where they are no longer involved with the ironic
> community. Each person listed below has been inactive for a year or
> more and is no longer active in the ironic community. As such I've
> removed their group membership from the sub-project core reviewer
> groups. Should they return, we will welcome them back to the community
> with open arms.
>
> bifrost-core: Stephanie Miller[4]
> ironic-inspector-core: Anton Arefivev[5]
> ironic-ui-core: Peter Peila[6], Beth Elwell[7]
>
> Thanks,
>
> -Julia
>
> [1]: http://stackalytics.com/?user_id=etingof=marks
> [2]: http://stackalytics.com/?user_id=kaifeng=marks
> [3]: http://stackalytics.com/?user_id=deray=marks=all
> [4]: http://stackalytics.com/?metric=marks=all_id=stephan
> [5]: http://stackalytics.com/?user_id=aarefiev=marks
> [6]: http://stackalytics.com/?metric=marks=all_id=ppiela
> [7]:
> http://stackalytics.com/?metric=marks=all_id=bethelwell=ironic-ui
>
> __
> 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] Stepping down from Ironic core

[Ruby Loo]

Hi John,

So sorry to hear this but totally understandable! Thanks for letting us
know and for everything you've done! Enjoy life without ironic :)

--ruby

On Tue, Aug 21, 2018 at 10:39 AM John Villalovos 
wrote:

> Good morning Ironic,
>
> I have come to realize that I don't have the time needed to be able to
> devote the attention needed to continue as an Ironic core.
>
> I'm hopeful that in the future I will work on Ironic or OpenStack again! :)
>
> The Ironic (and OpenStack) community has been a great one and I have
> really enjoyed my time working on it and working with all the people. I
> will still be hanging around on IRC and you may see me submitting a patch
> here and there too :)
>
> Thanks again,
> John
> __
> 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-staging-drivers: what to do?

[Ruby Loo]

Hi,

On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger 
wrote:

> Greetings fellow ironicans!
>
> As many of you might know an openstack/ironic-staging-drivers[1]
> repository exists. What most might not know is that it was
> intentionally created outside of ironic's governance[2].
> ...
>
> This topic has come up in passing at PTGs and most recently on IRC[9],
> and I think we ought to discuss it during our next weekly meeting[10].
> I've gone ahead and added an item to the agenda, but we can also
> discuss via email.
>
>
We had a short discussion on this in our meeting today [1]. To summarize,
we did not discuss whether to put it under the ironic governance. We did
agree that it would be ok to have the ironic cores be cores in
ironic-staging-drivers. There would be no guarantee (of course) that the
ironic cores would actually review any of these. Julia will get in touch
with the cores in ironic-staging-drivers, to see if they would like to add
ironic-cores as cores.

--ruby

[1]
http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-08-20-15.00.log.html#l-118
__
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-staging-drivers: what to do?

[Ruby Loo]

Hi Julia,

Thanks for bringing this up.


On Mon, Aug 13, 2018, 2:41 PM Julia Kreger, 
wrote:

> Greetings fellow ironicans!
>
> As many of you might know an openstack/ironic-staging-drivers[1]
> repository exists. What most might not know is that it was
> intentionally created outside of ironic's governance[2].
>
> At the time it was created ironic was moving towards removing drivers
> that did not meet our third-party CI requirement[3] to be in-tree. The
> repository was an attempt to give a home to what some might find
> useful or where third party CI is impractical or cost-prohibitive and
> thus could not be officially part of Ironic the service. There was
> hope that drivers could land in ironic-staging-drivers and possibly
> graduate to being moved in-tree with third-party CI. As our community
> has evolved we've not stopped and revisited the questions.
>
> With our most recent release over, I believe we need to ask ourselves
> if we should consider moving ironic-staging-drivers into our
> governance.
>
> Over the last couple of releases several contributors have found
> themselves trying to seek out two available reviewers to merge even
> trivial fixes[4]. Due to the team being so small this was no easy
> task. As a result, I'm wondering why not move the repository into
> governance, grant ironic-core review privileges upon the repository,
> and maintain the purpose and meaning of the repository. This would
> also result in the repository's release becoming managed via the
> release management process which is a plus.
>

If I understand, it seems like the main issue is lack of reviewers. As
mentioned by others, I would not be opposed to adding existing ironic cores
to this repo.
Whether folks review is a different question.

We could then propose an actual graduation process and help alleviate
> some of the issues where driver code is iterated upon for long periods
> of time before landing. At the same time I can see at least one issue
> which is if we were to do that, then we would also need to manage
> removal through the same path.
>

I am not sure I see any advantages to this. The ansible driver was in the
staging repo for awhile before it went into ironic so we know that is
do-able :)


> I know there are concerns over responsibility in terms of code
> ownership and quality, but I feel like we already hit such issues[5],
> like those encountered when Dmitry removed classic drivers[6] from the
> repository and also encountered issues just prior to the latest
> release[7][8].
>

I don't mind making changes or reviewing changes to this repo, especially
if there are unit tests. However, that is the most responsibility I am
comfortable having with this repo.

Right now, I don't see any good reasons for putting it under the ironic
governance. I am, of course, open to being convinced otherwise!

--ruby


> This topic has come up in passing at PTGs and most recently on IRC[9],
> and I think we ought to discuss it during our next weekly meeting[10].
> I've gone ahead and added an item to the agenda, but we can also
> discuss via email.


> -Julia
>
> [1]:
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571
> [2]:
> http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16
> [3]:
> https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html
> [4]: https://review.openstack.org/#/c/548943/
> [5]: https://review.openstack.org/#/c/541916/
> [6]: https://review.openstack.org/567902
> [7]: https://review.openstack.org/590352
> [8]: https://review.openstack.org/590401
> [9]:
> http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
> [10]:
> https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
>
> __
> 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] use of storyboard (was [TC] Stein Goal Selection)

[Ruby Loo]

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat
guilty about not being vocal wrt Storyboard. Yes, ironic migrated to
Storyboard in the beginning of this cycle. To date, I have not been pleased
with replacing Launchpad with Storyboard. I believe that Storyboard is
somewhat still-in-progress, and that there were/are some features (stories)
that are outstanding that would make its use better.

>From my point of view (as a developer and core, not a project manager or
PTL) using Storyboard has made my day-to-day work worse. Granted, any
migration is without headaches. But some of the main things, like searching
for our RFEs (that we had tagged in Launchpad) wasn't possible. I haven't
yet figured out how to limit a search to only the 'ironic' project using
that 'search' like GUI, so I have been frustrated trying to find particular
bugs that I *knew* existed but had not memorized the bug number.

I haven't been as involved upstream this cycle, so perhaps I have missed
other emails that have mentioned how to get around or do things with
Storyboard. I would caution folks that are thinking about migrating; I wish
we had delayed it until there was better support/features/stories
implemented with Storyboard. At the time, I was also negligent about
actually trying out Storyboard before we pushed the button (because I
assumed it would be ok, others were using it, why wouldn't it suffice?)
Perhaps Storyboard can address most of my issues now? Maybe updated
documentation would help? (I believe the last time I tried to use
Storyboard was 2 weeks ago, when I was 'search'ing for an old bug in
Storyboard. I gave up.)

I apologize for not writing a detailed email with specific examples of what
is lacking (for me) and in hindsight should have sent out email at the time
I encountered issues/had questions. I guess I am hoping that others can
fill-in-the-blanks and ask for things that would make Storyboard (more)
usable.

No, I didn't watch any videos about using Storyboard, just like I've never
watched any video about using Launchpad, Trello, jira, . I did
try looking for documentation at some point though and I don't recall
finding what I was looking for.

--ruby


On Thu, Jun 7, 2018 at 4:25 PM, Kendall Nelson 
wrote:

> Hello :)
>
> I think that these two goals definitely fit the criteria we discussed in
> Vancouver during the S Release Goal Forum Session. I know Storyboard
> Migration was also mentioned after I had to dip out to another session so I
> wanted to follow up on that.
>
> I know it doesn't fit the shiny user facing docket that was discussed at
> the Forum, but I do think its time we make migration official in some
> capacity as a release goal or some other way. Having migrated Ironic and
> having TripleO on the schedule for migration (as requested during the last
> goal discussion) in addition to having migrated Heat, Barbican and several
> others in the last few months we have reached the point that I think
> migration of the rest of the projects is attainable by the end of Stein.
>
> Thoughts?
>
> -Kendall (diablo_rojo)
>
>
__
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] Proposing Mark Goddard to ironic-core

[Ruby Loo]

++. Great suggestion!

--ruby

On Sun, May 20, 2018 at 10:45 AM, Julia Kreger 
wrote:

> Greetings everyone!
>
> I would like to propose Mark Goddard to ironic-core. I am aware he
> recently joined kolla-core, but his contributions in ironic have been
> insightful and valuable. The kind of value that comes from operative use.
>
> I also make this nomination knowing that our community landscape is
> changing and that we must not silo our team responsibilities or ability to
> move things forward to small highly focused team. I trust Mark to use his
> judgement as he has time or need to do so. He might not always have time,
> but I think at the end of the day, we’re all in that same boat.
>
> -Julia
>
>
> __
> 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][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Ruby Loo]

On Fri, May 11, 2018 at 7:50 AM, Julia Kreger 
wrote:

> Greetings folks,
>
> Is there any objection if we re-add Jim to the ironic-stable-maint
> team?  He was a member prior to his brief departure and I think it
> would be good to have another set of hands that can approve the
> changes as three doesn't seem like quite enough when everyone is busy.
>
>
Glad you brought it up cuz I wanted to re-add him to this, when we re-added
him back as an ironic core :)

Thanks for making it happen,
--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

Re: [openstack-dev] [ironic] Monthly bug day?

[Ruby Loo]

Hi Mike,

If we hold it, I'll (try to) be there :)

Thanks for spearheading this!

--ruby

On Mon, Apr 23, 2018 at 8:04 AM, Michael Turek 
wrote:

> Hey everyone!
>
> We had a bug day about two weeks ago and it went pretty well! At last
> week's IRC meeting the idea of having one every month was thrown around.
>
> What does everyone think about having Bug Day the first Thursday of every
> month?
>
> Thanks,
> Mike Turek
>
>
> __
> 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 Bug Day on Thursday April 12th @ 1:00 PM - 3:00 PM (UTC)

[Ruby Loo]

Hi Mike,

This works for me. We can refine/discuss at the bug squashing event.

Thanks!
--ruby

On Wed, Apr 11, 2018 at 2:53 PM, Michael Turek 
wrote:

> Sorry this is so late but as for the format of the event I think we should
> do something like this:
>
> 1) Go through new bugs
> -This is doable in storyboard. Sort by creation date
> -Should be a nice warm up activity!
> 2) Go through oldest bugs
> -Again, doable in storyboard. Sort by last updated.
> -Older bugs are usually candidates for some clean up. We'll decide if
> bugs are still valid
>  or if we need to reassign/poke owners.
> 3) Open Floor
> -If you have a bug that you'd like to discuss, bring it up here!
> 4) Storyboard discussion
> -One of the reasons we are doing this is to get our feet wet in
> storyboard. Let's spend
>  10 to 20 minutes discussing what we need out of the tool after
> playing with it.
>
> Originally I was hoping that we could sort by task priority but that
> currently seems to be
> unavailable, or well hidden, in storyboard . If someone knows how to do
> this, please reply.
>
> Does anyone else have any ideas on how to structure bug day?
>
> Thanks!
> Mike 
>
>
> On 4/11/18 9:47 AM, Michael Turek wrote:
>
>> Hey all,
>>
>> Ironic Bug Day is happening tomorrow, April 12th at 1:00 PM - 3:00 PM
>> (UTC)
>>
>> We will be meeting on Julia's bluejeans line:
>> https://bluejeans.com/5548595878
>>
>> Hope to see everyone there!
>>
>> Thanks,
>> Mike Turek 
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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 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] team dinner at Dublin PTG?

[Ruby Loo]

On Mon, Feb 5, 2018 at 5:42 PM, Loo, Ruby  wrote:

> Hi ironic-ers,
>
> Planning for the Dublin PTG has started. And what's the most important
> thing (and most fun event) to plan for? You got it, the team dinner! We'd
> like to get an idea of who is interested and what evening works for all or
> most of us.
>
> Please indicate which evenings you are available, at this doodle:
> https://doodle.com/poll/d4ff6m9hxg887n9q
>
> If you're shy or don't want to use doodle, send me an email.
>
> Please respond by Friday, Feb 16 (same deadline as PTG
> topics-for-discussion), so we can find a place and reserve it.
>
> Thanks!
> --ruby
>
>
Reminder to doodle [1] if you haven't done so already. Also, because we're
all so keen to know when and where we're going, we want to decide sooner,
so please respond by tomorrow (Tues, Feb 13). Thanks!

--ruby

[1] https://doodle.com/poll/d4ff6m9hxg887n9q
__
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] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Ruby Loo]

On Mon, Dec 18, 2017 at 11:29 PM,  wrote:

> Thanks for response.
> My recommendation is:
> 1. only allow patches into openstack/ironic-tempest-plugin
> 2. Give Ironic CI owners time period (3 weeks?) to switch their setup to
> only use openstack/ironic-tempest-plugin and not master and report back
> to Ironic CI team if it works for them. If yes, go ahead and switch if not,
> report back.
> 3. At the end of that time, if majority of Ironic CI site complete their
> transition to ironic-tempest-plugin we switch.
>
> Thanks,
> Arkady
>
>
I think this is reasonable. I cringe at knowingly doing something that will
most likely break the third party CI when people are away and cannot
address it. Also, apart from the danger that the third party CIs are
running old versions of the tempest plugins (I doubt that we'll be doing
major overhaul of that in the next 2+ weeks), the reason we have 3rd party
CI is to make sure patches work against those HW. Having most or all of
them being unavailable due to this breakage means that there won't be any
feedback that someone's code would have broken 3rd party CI outside of the
tempest changes.

John, don't you have a patch that removes the tempest plugin from master?
Do most/all of the 3rd party CIs fail due to that? (Or is it not as simple
as that?) Ah, yes, https://review.openstack.org/#/c/527733/ shows that all
the 3rd party CI fail (although I don't know if it is due to that patch or
if they were already failing prior to that).

--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

Re: [openstack-dev] [ironic] reminder about deadlines

[Ruby Loo]

On Fri, Dec 15, 2017 at 9:15 AM, Dmitry Tantsur  wrote:

> Hi all!
>
> Half of the Queens cycle is behind us. I'd like to remind about a few
> deadlines and how they affect us:
>
> 1. Jan 18th is the non-client library release deadline. It affects
> ironic-lib and sushy. The latter has a few outstanding changes - please try
> to find some time to get them a bit of attention. We have one months left,
> minus holidays.
>
> 2. Jan 25th is the client release deadline. If you work on new API, it has
> to land before that point with its client change to end up in ironicclient
> Queens.
>
> 3. Jan 25th is also the feature freeze. We haven't had a formal feature
> freeze for a few cycles. But after troubles with releasing Pike we decided
> to get back to it.
>

Note that this date is not only ironic's feature freeze. If your feature
needs ironic changes to land before changes can be done in another project
(eg nova or neutron), there is less time for you to get the ironic portion
landed.


>
> Feature freeze exceptions *may* be given to priority work, low-impact
> vendor changes and low-impact work substantially improving operator's
> and/or user's experience. Feature freeze exceptions are unlikely to be
> granted to major API additions or breaking changes.
>
> If you think your work may be affected by the feature freeze, please start
> planning accordingly.
>
> Thank you and happy winter holidays,
> 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] Summary of ironic sessions from Sydney

[Ruby Loo]

Thank you Julia, for sacrificing yourself and going to Australia; I'm glad
the koalas didn't get you :)

This summary is GREAT! I'm trying to figure out how we take all these asks
into consideration with all the existing asks and TODOs that are on our
plate. I guess the best plan of action (and a bit more procrastination) is
to discuss this at our virtual mid-cycle meetup next week [1].

--ruby

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124725.html


On Tue, Nov 14, 2017 at 11:18 AM, Julia Kreger 
wrote:

> Greetings ironic folk!
>
> Like many other teams, we had very few ironic contributors make it to
> Sydney. As such, I wanted to go ahead and write up a summary that
> covers takeaways, questions, and obvious action items for the
> community that were raised by operators and users present during the
> sessions, so that we can use this as feedback to help guide our next
> steps and feature planning.
>
> Much of this is from my memory combined with notes on the various
> etherpads. I would like to explicitly thank NobodyCam for reading
> through this in advance to see if I was missing anything at a high
> level since he was present in the vast majority of these sessions, and
> dtantsur for sanity checking the content and asking for some
> elaboration in some cases.
>
> -Julia
>
>
>
> Ironic Project Update
> =
>
> Questions largely arose around use of boot from volume, including some
> scenarios we anticipated that would arise, as well as new scenarios
> that we had not considered.
>
> Boot nodes booting from the same volume
> ---
>
> From a technical standpoint, when BFV is used with iPXE chain loading,
> the chain loader reads the boot loader and related data from the
> cinder (or, realistically, any iSCSI volume). This means that a
> skilled operator is able to craft a specific volume that may just turn
> around and unpack a ramdisk and operate the machine solely from RAM,
> or that utilize an NFS root.
>
> This sort of technical configuration would not be something an average
> user would make use of, but there are actual use cases that some large
> scale deployment operators would make use of and that would provide
> them value.
>
> Additionally, this topic and the desire for this capability also come
> up during the “Building a bare metal cloud is hard” talk Q
>
> Action Item: Check the data model to see if we prohibit, and consider
> removing the prohibition against using the same volume across nodes,
> if any.
>
> Cinder-less BFV support
> ---
>
> Some operators are curious about booting Ironic managed nodes without
> cinder in a BFV context. This is something we anticipated and built
> the API and CLI interfaces to support this. Realistically, we just
> need to offer the ability for the data to be read and utilized.
>
> Action Item: Review code and ensure that we have a some sort of no-op
> driver or method that allows cinder-less node booting. For existing
> drivers, it would be the shipment of the information to the BMC or the
> write-out of iPXE templates as necessary.
>
> Boot IPA from a cinder volume
> -
>
> With larger IPA images, specifically in cases where the image contains
> a substantial amount of utilized or tooling to perform cleaning,
> providing a mechanism to point the deployment Ramdisk to a cinder
> volume would allow more efficient IO access.
>
> Action Item: Discuss further - Specifically how we could support as we
> would need to better understand how some of the operators might use
> such functionality.
>
> Dedicated Storage Fabric support
> 
>
> A question of dedicated storage fabric/networking support arose. For
> users of FibreChannel, they generally have a dedicated storage fabric
> by the very nature of separate infrasturcture. However, with ethernet
> networking where iSCSI software initiators are used, or even possibly
> converged network adapters, things get a little more complex.
>
> Presently, with the iPXE boot from volume support, we boot using the
> same interface details for the neutron VIF that the node is attached
> with.
>
> Moving forward, with BFV, the concept was to support the use of
> explicitly defined interfaces as storage interfaces, which could be
> denoted as "volume connectors" in ironic by type defined as "mac". In
> theory, we begin to get functionality along these lines once
> https://review.openstack.org/#/c/468353/ lands, as the user could
> define two networks, and the storage network should then fall to the
> explicit volume connector interface(s). The operator would just need
> to ensure that the settings being used on that storage network are
> such that the node can boot and reach the iSCSI endpoint, and that a
> default route is not provided.
>
> The question then may be, does Ironic do this quietly for the user
> requesting the VM or not, and how 

Re: [openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

[Ruby Loo]

Thanks for bringing this up Dmitry. See inline...

On Tue, Nov 14, 2017 at 5:05 PM, Alex Schultz  wrote:

> On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur 
> wrote:
> > Hi folks!
> >
> > This was raised several times, now I want to bring it to the wider
> audience.
> > We're planning [1] to deprecate classic drivers in Queens and remove
> them in
> > Rocky. It was pointed at the Forum that we'd better provide an automatic
> > migration.
> >
> > I'd like to hear your opinion on the options:
> >
> > (1) Migration as part of 'ironic-dbsync upgrade'
> >
> > Pros:
> > * nothing new to do for the operators
> >
> > Cons:
> > * upgrade will fail completely, if for some nodes the matching hardware
> > types and/or interfaces are not enabled in ironic.conf
> >
>

ironic-dbsync upgrade has always (I think) been used to *only* update the
database schema. Not change the actual data in the database. I don't think
this is the right place to be doing this 'migration'.


> > (2) A separate script for migration
> >
> > Pros:
> > * can be done in advance (even while still on Pike)
> > * a failure won't fail the whole upgrade
> > * will rely on drivers enabled in actually running conductors, not on
> > ironic.conf
> >
> > Cons:
> > * a new upgrade action before Rocky
> > * won't be available in packaging
> > * unclear how to update nodes that are in some process (e.g. cleaning),
> will
> > probably have to be run several times
> >
> > (3) Migration as part of 'ironic-dbsync online_data_migration'
> >
> > Pros:
> > * nothing new to do for the operators, similar to (1)
> > * probably a more natural place to do this than (1)
> > * can rely on drivers enabled in actually running conductors, not on
> > ironic.conf
> >
> > Cons:
> > * data migration will fail, if for some nodes the matching hardware types
> > and/or interfaces are not enabled in ironic.conf
> >
>

The online_data_migration exists for situations just like this; migration
of data :) So this is my vote. It is fine if the call fails, this lets the
operators know that they will need to make changes. If we go with this, I
envision it working something like:

Queens: deprecate classic drivers
Queens: 'ironic-dbsync online_data_migrations' is run (at any point in
time, while ironic services are running). Among other things, it would
migrate classic drivers to hardware types, failing if needed hardware types
or interfaces are not enabled in the config file.
This must succeed before upgrading to Rocky
Rocky: if you try to upgrade to Rocky and the above Queens' ironic-dbsync
online_data_migrations fails, you will not be able to upgrade.


> Rather than fail in various ways, why not do like what nova has with a
> pre-upgrade status check[0] and then just handle it in ironic-dbsync
> upgrade?   This would allow operators to check prior to running the
> upgrade to understand what might need to be changed.  Additionally the
> upgrade command itself could leverage the status check to fail nicely.
>
>
I like the idea of a status check, although I am doubtful that it is
do-able in Queens, given the goals we have. But of course, that can be up
for discussion etc.


> > (4) Do nothing, let operators handle the migration.
> >
>
> Please no.
>
> >
> > The most reasonable option for me seems (3), then (4). What do you think?
> >
>
> So this was chatted about in relation to some environment tooling we
> have where we currently have where older 'pxe_ipmitool' defined and
> this will need to switch to be 'ipmi'[1]. The issue with the hard
> cutover on this one is any tooling which may have been written that
> currently works with multiple openstack releases to generate the
> required json for ironic will now have to take that into account.  I
> know in our case we'll be needing to support newton for longer so
> making the tooling openstack aware around this is just further
> tech-debt that we'll be creating. Is there a better solution that
> could be done either in ironic client or in the API to gracefully
> handle this transition for a longer period of time?  I think this may
> be one of those decisions that has a far reaching impact on
> deployers/operators due changes they will have to make to support
> multiple versions or as they upgrade between versions and they aren't
> fully aware of yet as many may not be on Ocata.  This change seems
> like it has a high UX impact and IMHO should be done very carefully.
>


It seems to me that if this going to cause undue hardship, that we consider
prolonging the deprecation period for eg. another cycle. I guess I'd like
to get an idea of how long is reasonable, to handle this transition... How
do we get more data points on this, or is Alex the representative for our
users out there? :)

--ruby


>
> Thanks,
> -Alex
>
> [0] https://docs.openstack.org/nova/pike/cli/nova-status.html
> [1] http://eavesdrop.openstack.org/irclogs/%23tripleo/%
> 23tripleo.2017-11-14.log.html#t2017-11-14T15:36:45
>
>
> > Dmitry

Re: [openstack-dev] [ironic] moving the weekly meeting to our channel?

[Ruby Loo]

On Wed, Nov 15, 2017 at 3:35 AM, Dmitry Tantsur  wrote:

> Hi all,
>
> Due to a technical issue we had to have our weekly meeting in our main
> channel this time. And we liked it :) I wonder if we should switch to it.
>
> Pros:
> * easier to find
> * no channel switching
>
> Cons:
> * potential conflicts with other meetings (already a problem, given how
> many rooms we have)
> * blocks the main channel for 1 hour for other business
>
> Opinions?
>
> __
> 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
>

I think it is a great idea. No nays is a good sign. Let's do it. It'll be
one fewer things to deal with. Anyone that has other business, will find
out what they've been missing.

--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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Ruby Loo]

On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker 
wrote:

> Thank you. I too vote for 'Option 1'.
>
> Thanks and Regards
> Shiv
>
>
>
> On Wed, Nov 15, 2017 at 1:03 AM, Villalovos, John L <
> john.l.villalo...@intel.com> wrote:
>
>> Thanks for sending this out.
>>
>>
>>
>> I would vote for Option 1.
>>
>>
>>
>> Thanks,
>>
>> John
>>
>>
>>
>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* [openstack-dev] [ironic] inclusion of
>> openstack/networking-generic-switch project under OpenStack baremetal
>> program
>>
>>
>>
>> Hi all,
>>
>>
>>
>> as this topic it was recently brought up in ironic IRC meeting, I'd like
>> to start a discussion on the subject.
>>
>>
>>
>> A quick recap - networking-generic-switch project (n-g-s) was born out of
>> necessity to do two things:
>>
>>
>>
>> -  test the "network isolation for baremetal nodes" (a.k.a.
>> multi-tenancy) feature of ironic on upstream gates in virtualized
>> environment and
>>
>> - do the same on cheap/simple/dumb hardware switches that are not
>> supported by other various openstack/networking-* projects.
>>
>>
>>
>> Back when it was created AFAIR neutron governance (neutron stadium) was
>> under some changes, so in the end n-g-s ended up not belonging to any
>> official program.
>>
>>
>>
>> Over time n-g-s grew to be an essential part of ironic gate testing
>> (similar to virtualbmc). What's more, we have reports that it is already
>> being used in production.
>>
>>
>>
>> Currently the core reviewers team of n-g-s consists of 4 people (2 of
>> those are currently core reviewers in ironic too), all of them are working
>> for the same company (Mirantis). This poses some risk as companies and
>> people come and go, plus since some voting ironic gate jobs depend on n-g-s
>> stability, a more diverse group of core reviewers from baremetal program
>> might be beneficial to be able to land patches in case of severe gate
>> troubles.
>>
>>
>>
>> Currently I know of 3 proposed ways to change the current situation:
>>
>>
>>
>> 1) include n-g-s under ironic (OpenStack Baremetal program) governance,
>> effectively including ironic-core team to the core team of  n-g-s similar
>> to how ironic-inspector currently governed (keeping an extended sub-core
>> team). Reasoning for addition is the same as with virtualbmc/sushy
>> projects, with the debatable difference that the actual scope of n-g-s is
>> quite bigger and apparently includes production use-cases;
>>
>>
>>
>> 2) keep things as they are now, just add ironic-stable-maint team to the
>> n-g-s core reviewers to decrease low diversity risks;
>>
>>
>>
>> 3) merge the code from n-g-s into networking-baremetal project which is
>> already under ironic governance.
>>
>>
>>
>> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
>> fond of 3) as it kind of stretches the networking-baremetal scope too much
>> IMHO.
>>
>>
>>
>> Eager to hear your comments and proposals.
>>
>>
>>
>> Cheers,
>>
>> --
>>
>> Dr. Pavlo Shchelokovskyy
>>
>> Senior Software Engineer
>>
>> Mirantis Inc
>>
>> www.mirantis.com
>>
>>
 I'm good with 1 or 2. Since we have two 1's and no nays (so far), let's go
with 1 and move on :)

Thanks for bringing this up!

--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

Re: [openstack-dev] [nova][neutron][cinder][infra] openstack-tox-py27 job is not executed when spec files are added or modified in nova-specs

[Ruby Loo]

On Thu, Nov 16, 2017 at 1:17 PM, Matt Riedemann  wrote:

> On 11/16/2017 12:15 PM, Matt Riedemann wrote:
>
>> On 11/16/2017 9:58 AM, Jeremy Stanley wrote:
>>
>>> On 2017-11-16 15:17:58 +0900 (+0900), Takashi Natsume wrote:
>>>
 In nova-specs project, there is an 'openstack-tox-py27' job (in
 Zuul check or Zuul gate). The job checks whether spec files comply
 with the template or not, line length, etc. But there are cases
 that the job is not executed even if a spec file is added or
 modified.

>>> [...]
>>>
>>> Most projects want to have their unit test jobs skipped on changes
>>> which only alter documentation. The nova-specs repo is unusual in
>>> that it's attempting to leverage a unit testing job to validate
>>> documentation formatting rather than the sorts of docs linters other
>>> projects rely on.
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> Yeah, in other words, the job definition skips the files that we care
>> about in nova-specs:
>>
>> https://github.com/openstack-infra/openstack-zuul-jobs/blob/
>> 00168bf82cf4a13ac6339736667dd532eeeff4e9/zuul.d/jobs.yaml#L238
>>
>> So we'll probably need to change the definition of the nova-specs py27
>> job to run these linter type tests in the pep8 run.
>>
>>
> By the way, it looks like neutron-specs and cinder-specs are going to have
> the same problem.
>
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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
>


We had a similar problem with ironic-specs, and ended up going with
openstack-tox-linters because we do doc8 and some unit tests that do
fancy-schmancy (i.e. I don't remember what) checking :)

--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

Re: [Openstack-operators] [openstack-dev] [ironic] replace node "tags" with node "traits"

[Ruby Loo]

Hi,

Thanks for your 3 votes. Every vote counts; you've convinced me of the
usefulness of having both tags and traits as separate features. I shall
advocate for you all :)

--ruby


On Fri, Oct 27, 2017 at 5:41 AM, Vladyslav Drok  wrote:

>
>
> On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes  wrote:
>
>> On 10/25/2017 12:55 PM, Mathieu Gagné wrote:
>>
>>> Hi,
>>>
>>> On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:
>>>
 Hello ironic'ers,

 A while ago, we approved a spec to add node tag support to ironic [1].
 The
 feature itself did not land yet (although some of the code has). Now
 that
 the (nova) community has come up with traits, ironic wants to support
 node
 traits, and there is a spec proposing that [2]. At the ironic node
 level,
 this is VERY similar to the node tag support, so the thought is to drop
 (not
 implement) the node tagging feature, since the node traits feature
 could be
 used instead. There are a few differences between the tags and traits.
 "Traits" means something in OpenStack, and there are some restrictions
 about
 it:

 - max 50 per node

 - names must be one of those in os-traits library OR prefixed with
 'CUSTOM_'

 For folks that wanted the node tagging feature, will this new node
 traits
 feature work for your use case? Should we support both tags and traits?
 I
 was wondering about e.g. using ironic standalone.

 Please feel free to comment in [2].

 Thanks in advance,

 --ruby

 [1]
 http://specs.openstack.org/openstack/ironic-specs/specs/appr
 oved/nodes-tagging.html

 [2] https://review.openstack.org/#/c/504531/


>>> Are tags/traits serving a different purpose? One serves the purpose of
>>> helping the scheduling/placement while the other is more or less aims
>>> at grouping for the "end users"?
>>> I understand that the code will be *very* similar but who/what will be
>>> the consumers/users?
>>> I fell they won't be the same and could artificially limit its use due
>>> to technical/design "limitations". (must be in os-traits or be
>>> prefixed by CUSTOM)
>>>
>>> For example which I personally foresee:
>>> * I might want to populate Ironic inventory from an external system
>>> which would also injects the appropriate traits.
>>> * I might also want some technical people to use/query Ironic and
>>> allow them to tag nodes based on their own needs while not messing
>>> with the traits part (as it's managed by an external system and will
>>> influence the scheduling later)
>>>
>>> Lets not assume traits/tags have the same purpose and same user.
>>>
>>
>> I agree with Matthieu 100% here.
>>
>> Traits are structured, formalized, and set by the system or the operator
>> against resource providers.
>>
>> Tags are for end-users to, well, tag their instances with whatever
>> strings they want.
>>
>> Best,
>> -jay
>
>
> I'd also vote for having them separate. We can refactor the common bits of
> code instead.
>
> -Vlad
>
>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

[Ruby Loo]

Hi,

Thanks for your 3 votes. Every vote counts; you've convinced me of the
usefulness of having both tags and traits as separate features. I shall
advocate for you all :)

--ruby


On Fri, Oct 27, 2017 at 5:41 AM, Vladyslav Drok  wrote:

>
>
> On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes  wrote:
>
>> On 10/25/2017 12:55 PM, Mathieu Gagné wrote:
>>
>>> Hi,
>>>
>>> On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:
>>>
 Hello ironic'ers,

 A while ago, we approved a spec to add node tag support to ironic [1].
 The
 feature itself did not land yet (although some of the code has). Now
 that
 the (nova) community has come up with traits, ironic wants to support
 node
 traits, and there is a spec proposing that [2]. At the ironic node
 level,
 this is VERY similar to the node tag support, so the thought is to drop
 (not
 implement) the node tagging feature, since the node traits feature
 could be
 used instead. There are a few differences between the tags and traits.
 "Traits" means something in OpenStack, and there are some restrictions
 about
 it:

 - max 50 per node

 - names must be one of those in os-traits library OR prefixed with
 'CUSTOM_'

 For folks that wanted the node tagging feature, will this new node
 traits
 feature work for your use case? Should we support both tags and traits?
 I
 was wondering about e.g. using ironic standalone.

 Please feel free to comment in [2].

 Thanks in advance,

 --ruby

 [1]
 http://specs.openstack.org/openstack/ironic-specs/specs/appr
 oved/nodes-tagging.html

 [2] https://review.openstack.org/#/c/504531/


>>> Are tags/traits serving a different purpose? One serves the purpose of
>>> helping the scheduling/placement while the other is more or less aims
>>> at grouping for the "end users"?
>>> I understand that the code will be *very* similar but who/what will be
>>> the consumers/users?
>>> I fell they won't be the same and could artificially limit its use due
>>> to technical/design "limitations". (must be in os-traits or be
>>> prefixed by CUSTOM)
>>>
>>> For example which I personally foresee:
>>> * I might want to populate Ironic inventory from an external system
>>> which would also injects the appropriate traits.
>>> * I might also want some technical people to use/query Ironic and
>>> allow them to tag nodes based on their own needs while not messing
>>> with the traits part (as it's managed by an external system and will
>>> influence the scheduling later)
>>>
>>> Lets not assume traits/tags have the same purpose and same user.
>>>
>>
>> I agree with Matthieu 100% here.
>>
>> Traits are structured, formalized, and set by the system or the operator
>> against resource providers.
>>
>> Tags are for end-users to, well, tag their instances with whatever
>> strings they want.
>>
>> Best,
>> -jay
>
>
> I'd also vote for having them separate. We can refactor the common bits of
> code instead.
>
> -Vlad
>
>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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 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-operators] [openstack-dev] [ironic] replace node "tags" with node "traits"

[Ruby Loo]

Sending again, I don't think it went to openstack-operators@.

--ruby

On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:

> Hello ironic'ers,
>
>
>
> A while ago, we approved a spec to add node tag support to ironic [1]. The
> feature itself did not land yet (although some of the code has). Now that
> the (nova) community has come up with traits, ironic wants to support node
> traits, and there is a spec proposing that [2]. At the ironic node level,
> this is VERY similar to the node tag support, so the thought is to drop
> (not implement) the node tagging feature, since the node traits feature
> could be used instead. There are a few differences between the tags and
> traits. "Traits" means something in OpenStack, and there are some
> restrictions about it:
>
> - max 50 per node
>
> - names must be one of those in os-traits library OR prefixed with
> 'CUSTOM_'
>
>
>
> For folks that wanted the node tagging feature, will this new node traits
> feature work for your use case? Should we support both tags and traits? I
> was wondering about e.g. using ironic standalone.
>
>
>
> Please feel free to comment in [2].
>
>
>
> Thanks in advance,
>
> --ruby
>
>
>
> [1] http://specs.openstack.org/openstack/ironic-specs/specs/
> approved/nodes-tagging.html
>
> [2] https://review.openstack.org/#/c/504531/
>
> __
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

[Ruby Loo]

Sending again, I don't think it went to openstack-operators@.

--ruby

On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:

> Hello ironic'ers,
>
>
>
> A while ago, we approved a spec to add node tag support to ironic [1]. The
> feature itself did not land yet (although some of the code has). Now that
> the (nova) community has come up with traits, ironic wants to support node
> traits, and there is a spec proposing that [2]. At the ironic node level,
> this is VERY similar to the node tag support, so the thought is to drop
> (not implement) the node tagging feature, since the node traits feature
> could be used instead. There are a few differences between the tags and
> traits. "Traits" means something in OpenStack, and there are some
> restrictions about it:
>
> - max 50 per node
>
> - names must be one of those in os-traits library OR prefixed with
> 'CUSTOM_'
>
>
>
> For folks that wanted the node tagging feature, will this new node traits
> feature work for your use case? Should we support both tags and traits? I
> was wondering about e.g. using ironic standalone.
>
>
>
> Please feel free to comment in [2].
>
>
>
> Thanks in advance,
>
> --ruby
>
>
>
> [1] http://specs.openstack.org/openstack/ironic-specs/specs/
> approved/nodes-tagging.html
>
> [2] https://review.openstack.org/#/c/504531/
>
> __
> 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] Team dinner at the PTG?

[Ruby Loo]

Thanks Julia, for taking this on. I'm actually fine if we take a cab to
wherever, it seems like the PTG is in some sort of 'dead' zone wrt great
food for large groups :-(  Having said that, stapleton-caseys works for me,
especially if they take reservations.

My personal preference is for sushi since I love that. However, I would bet
that I am the anomaly there and that most folks would prefer
stapleton-caseys even if they don't speak up :)

--ruby

On Mon, Sep 4, 2017 at 11:23 AM, Julia Kreger 
wrote:

> I did some searching around yesterday near the venue for places to
> eat. The area is very spread out, but
> http://coloradopubco.com/stapleton-caseys/ is with-in walking
> distance. I spoke with some of the staff, and they said they were good
> with large groups, and that Mondays is somewhat hit or miss regarding
> being busy or not.
>
> I've been thinking it might be best for us to descend upon the bar,
> and kind of go from there, but I'll call and see if they they can do
> reservations. That being said, the space really doesn't lend it's self
> to a large reservation. There is also a sushi restaurant next door as
> an alternative.
>
> -Julia
__
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][docs] I see, you see, we all see red*

[Ruby Loo]

Hi Alex,

Sorry, I don't know much about the docs stuff; Andreas' links were useful
for enlightening me.

Clearly, I'm biased and would prefer no difference in colour. What about
that (darker?) blue from [0], where it sez (I'm referring to the
upper-cased words here) 'Modern color theory uses either the ... RED-CYAN,
GREEN-MAGENTA, BLUE-YELLOW'. Would that blue clash with the blue you are
mentioning? (Well, maybe it is the bold + blue that I like, not just the
blue.)

I don't really think a complementary colour is good, orange is marginally
better than red. I'd like it to be highlighted but I guess I like subtle,
not strong.

Having said all that, I'm a reader/viewer of these documents and this is
*just* my opinion. It seems to me that there might be research into what
works best? Anyone know?

Thanks,
--ruby

On Thu, Aug 24, 2017 at 6:19 AM, Alexandra Settle 
wrote:

> Hey Ruby!
>
>
>
> Good point – thanks for bringing it up :)
>
>
>
> I was brought up to think that red was one of those colours that people
> had different (and sometimes really negative) associations with. When I
> look at our latest and greatest! ironic documentation (e.g. [1]), I see
> red. Not only do I see red, but the term has a different background colour
> and is bordered (or whatever it is called). Are we using the wrong .rst
> syntax, should we be highlighting terms differently? And/or is there some
> way to change the appearance of highlighted terms? I much prefer something
> simple, like bold black text in some uniform font. On the other hand,
> perhaps lots of others like this and I'm in the minority.
>
>
>
> Andreas is right – the red definitely correct, and this is how we have
> always done it in manuals. But that doesn’t mean we have to continue. We
> just need to come up with another strong, inoffensive colour that matches;
> I believe the red was chosen to simply contrast the blue. A compromise, and
> complementary colour[0], would be orange. How would you feel about this?
>
>
>
> I hesitated about sending this due to the wonderful bike shedding that
> could happen, don't disappoint me, cuz I'm sure we all have opinions about
> colour. :)
>
>
>
> Not going to lie, also afraid of all the bike shedding! But you bring up a
> good point – and I don’t want others to also feel negatively about our
> documentation. We should be as inclusive as we can.
>
>
>
> Also, this email thread isn't about discussing the green and orange
> colours used for the code blocks; feel free to start your own thread about
> that if you want!
>
>
>
> No thanks, if I can avoid it :P
>
>
>
> Cheers,
>
>
>
> Alex
>
>
>
> [0] https://en.wikipedia.org/wiki/Complementary_colors
>
> __
> 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] [nova][docs] Concerns with docs migration

[Ruby Loo]

On Wed, Aug 2, 2017 at 10:55 AM, Matt Riedemann  wrote:

> ...
>
> b) I think that if we're going to refactor the Nova devref home page to be
> a certain format, then we should really consider doing the same thing in
> the other projects, because today they are all different formats [5][6][7].
> This is likely a cross-project discussion for the Queens PTG to determine
> if the home page for the projects should look similar. It seems they should
> given the uniformity that the Foundation has been working toward lately.
> ...

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
> st/120418.html
> [2] https://review.openstack.org/#/c/489650/
> [3] https://review.openstack.org/#/c/489641/
> [4] https://review.openstack.org/#/c/478485/
> [5] https://docs.openstack.org/cinder/latest/
> [6] https://docs.openstack.org/glance/latest/
> [7] https://docs.openstack.org/neutron/latest/
>
>
We had this discussion in ironic-land as well. I don't even consider it a
devref home page any more; it seems more like a landing page for 'all
things '. I may be opinionated sometimes ;), but if
some people could come to an agreement on how we could make these landing
pages consistent amongst most, if not all, of the openstack projects, I'll
follow :)

--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

Re: [openstack-dev] [nova] Performance concerns over all the new notifications

[Ruby Loo]

On Wed, Oct 19, 2016 at 11:07 PM, Joshua Harlow 
wrote:

> Matt Riedemann wrote:
>
>> There are a lot of specs up for review in ocata related to adding new
>> versioned notifications for operations that we didn't have notifications
>> on before, like CRUD operations on resources like flavors and server
>> groups.
>>
>> We've got a lot of legacy notifications for server actions, like
>> server.pause.start and server.pause.end. Those are pretty simple.
>>
>> The thing that has me concerned about the CRUD operation notifications
>> on resources is the extra DB query overhead to create the payloads which
>> might not even get sent out.
>>
>> For example, I was reviewing this spec about adding notifications for
>> CRUD ops on server groups:
>>
>> https://review.openstack.org/#/c/375316/
>>
>> Looking at the code for InstanceGroup, when a member is added to or
>> removed from the group, the hosts field implicitly changes, but to
>> calculate the hosts field we have to get all of the instances (members)
>> in the group and then built the list of instance.host values.
>>
>> This is probably less of an issue if the server group object in scope
>> already has the hosts field set, but if it doesn't and we're
>> constructing it just for the notification, that's extra DB and RPC
>> overhead - and notifications might not even be setup.
>>
>> I was thinking about it like logging details at debug level. If I need
>> to build some large object or get some data for debugging something
>> that's not in scope, I'd wrap that in a conditional:
>>
>> if LOG.isEnabledFor(logging.DEBUG):
>> LOG.debug('gimme da deets: %s', self.build_da_deets())
>>
>> But do we have anything like that for notifications? Basically, tell me
>> if I should even bother building payloads for notifications.
>>
>>
> A valid concern IMHO, seems like we might want a isEnabledFor() on the
> Notifier class in https://github.com/openstack/o
> slo.messaging/blob/master/oslo_messaging/notify/notifier.py#L175 (I am
> assuming here that the underlying drivers can even provide the knowledge to
> know that, which may or may not be a big assumption?)
>
> -Josh


+1. I can see this being useful. In ironic, we've managed to avoid the
issue so far, but notification is still in its infancy (< 1 month old) and
as it grows I think we will have to deal with this too. Ironic also has a
[default]notification_level config option [1]; do you think that there will
be a similar config option in oslo instead?

--ruby

[1]
https://github.com/openstack/ironic/blob/a67facf208289b8bef3d7a8189e707d9d0ef6b9f/etc/ironic/ironic.conf.sample#L108-L112
__
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] Event notification descriptors/schemas (? swagger ?)

[Ruby Loo]

On Fri, Oct 14, 2016 at 7:14 PM, Joshua Harlow 
wrote:

>
>> This is exactly what we are planning to do.  Work is ongoing to add
>> to_json_schema
>> support for every VersionedObject field [1]. Then we would like to add a
>> small
>> tool to nova that makes it possible to generate the json schemas for the
>> versioned
>> notifications [2]. Meanwhile we continue to transform legacy
>> notifications to a versioned
>> format [3].
>>
>> As soon as you have json schema you can find (or create) tools that
>> generate an object
>> model and a parser from the json schema of the notifications in any
>> modern language.
>>
>> I hope this work in nova will servers as an example for other OpenStack
>> project and
>> in the end OpenStack will have well defined and easy to consume
>> notifications.
>>
>> Any feedback on our plans are highly appreciated.
>>
>> Cheers,
>> gibi
>>
>> [1] https://review.openstack.org/#/q/topic:bp/json-schema-for-ve
>> rsioned-object,n,z
>> [2] https://blueprints.launchpad.net/nova/+spec/json-schema-for-
>> versioned-notifications
>> [3] https://vntburndown-gibi.rhcloud.com/index.html
>>
>>
> Great! :)
>
> Any thoughts on the ideas/burndown for the other projects that emit events
> (aka, going and doing similar changes, is there a list of other projects
> that need to have changes, ie glance, neutron, keystone (I think))?
>
> -Josh
>
>
ironic just added notifications (like, the first notifications went in this
week). ironic believes in re-use and that there are smart people in
OpenStack, so it is mostly based on nova's work :) I don't have any other
thoughts on the matter at the moment...

--ruby
(note, these are my opinions, not the ironic community's :))
__
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] [infra] RFC: consolidating and extending Ironic CI jobs

[Ruby Loo]

On Wed, Oct 12, 2016 at 2:13 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

>
>
> On 10/12/2016 05:01 AM, Dmitry Tantsur wrote:
> > Hi folks!
> >
> > I'd like to propose a plan on how to simultaneously extend the coverage
> of our
> > jobs and reduce their number.
> >
> > Currently, we're running one instance per job. This was reasonable when
> the
> > coreos-based IPA image was the default, but now with tinyipa we can run
> up to 7
> > instances (and actually do it in the grenade job). I suggest we use 6
> fake bm
> > nodes to make a single CI job cover many scenarios.
> >
> > The jobs will be grouped based on driver (pxe_ipmitool and
> agent_ipmitool) to be
> > more in sync with how 3rd party CI does it. A special configuration
> option will
> > be used to enable multi-instance testing to avoid breaking 3rd party CI
> systems
> > that are not ready for it.
> >
> > To ensure coverage, we'll only leave a required number of nodes
> "available", and
> > deploy all instances in parallel.
> >
> > In the end, we'll have these jobs on ironic:
> > gate-tempest-ironic-pxe_ipmitool-tinyipa
> > gate-tempest-ironic-agent_ipmitool-tinyipa
> >
> > Each job will cover the following scenarious:
> > * partition images:
> > ** with local boot:
> > ** 1. msdos partition table and BIOS boot
> > ** 2. GPT partition table and BIOS boot
> > ** 3. GPT partition table and UEFI boot  <*>
> > ** with netboot:
> > ** 4. msdos partition table and BIOS boot <**>
> > * whole disk images:
> > * 5. with msdos partition table embedded and BIOS boot
> > * 6. with GPT partition table embedded and UEFI boot  <*>
> >
> >  <*> - in the future, when we figure our UEFI testing
> >  <**> - we're moving away from defaulting to netboot, hence only one
> scenario
> >
> > I suggest creating the jobs for Newton and Ocata, and starting with
> Xenial right
> > away.
> >
> > Any comments, ideas and suggestions are welcome.
>
> Huge +1 on this from me, as well.
>
> I am also in favor of some of the other suggestions on this thread, namely,
> moving API testing over to functional tests so that those can be run more
> quickly / with less resources / without affecting tempest scenario tests.
>
> I also think we should begin defining additional scenario tests to cover
> things
> we are not covering today  (eg, adopt a running instance), as Vasyl already
> pointed out. But I don't think that conflicts or prevents the changes
> you're
> suggesting, Dmitry.
>
> -Deva
>
>
++

Thanks for bringing this up Dmitry! Might I suggest, if we don't already
have it, that this would be a good time to track (in a spreadsheet-like
form), the jobs with the tests covered by each job (or desired but not
covered yet). I can never remember what we are testing vs not testing.
(e.g. I thought we had adoption of a running instance.)

--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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[Ruby Loo]

On Tue, Oct 11, 2016 at 12:08 PM, Chris Dent  wrote:

>
> Based on the turnout numbers and a bit of unscientific number
> crunching on the voting results it seems that the electorate was
> rather more engaged this time around. That's _great_.
>
> As others have said I imagine some significant part of that was
> because of more than one mailing of the ballots to help everyone
> remember. I think there were probably other factors too:
>

 Would it be useful to have a not-so-scientific poll, to find out from
folks why they voted and why they didn't vote in previous elections?
Assuming folks respond to the poll :)

--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

Re: [openstack-dev] [OpenStack-docs] Admin guide in-tree?

[Ruby Loo]

>From my point of view, the rush is so that we can be more efficient with
all of our time/efforts. In ironic, we have a bit of a mess. We now have
duplicated (and perhaps out-of-sync) admin-related information in our
developer docs [1] as well as in the official admin guide [2] -- the latter
content was added but I am unaware of that knowledge/coordination being
done with the ironic community :-(

Should we :
A. move our admin-related information from our developer docs to the
existing admin guide; then move the admin guide to the new in-tree solution
later

B. replace what is in the existing admin guide with a pointer to the
developer docs; then move the admin content to the new in-tree solution
later

C. status quo until the new in-tree solution is available

--ruby

[1] http://docs.openstack.org/developer/ironic/
[2] http://docs.openstack.org/admin-guide/baremetal.html


On Mon, Oct 10, 2016 at 7:07 PM, Lana Brindley 
wrote:

> On 10/10/16 16:25, Andreas Jaeger wrote:
> > On 2016-10-10 01:37, Steve Martinelli wrote:
> >> On Oct 9, 2016 6:57 PM, "Lana Brindley"  >> > wrote:
> >>>
> >>> Why the rush?
> >>
> >> I think its more eagerness than rush. Project teams made a lot of head
> >> way with the API ref and install guides being in-tree that they want to
> >> keep the momentum with the admin guide.
> >
> > Those teams are more than welcome to contribute today to the
> > openstack-manuals repository! Is there anything we can help these?
> >
> > Andreas
> >
>
> Yes, Andreas makes a good point. If there's content you want in the guides
> now, we can help you with that.
>
> Lana
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> 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] openstack/python-ironicclient

[Ruby Loo]

On Mon, Sep 12, 2016 at 12:38 PM, Dean Troyer <dtro...@gmail.com> wrote:

> On Mon, Sep 12, 2016 at 10:51 AM, Ruby Loo <opensr...@gmail.com> wrote:
>
>> My preference is:
>>
>> * openstack baremetal driver show --raid-logical-disk-properties
>>
>
> Agreed here.
>
> The process we encourage is always to first identify the resource you are
> operating on.  I would add that a 'property' is not a resource, it
> describes a resource, there may be many of them per resource, etc.  Here,
> the resource is 'baremetal driver'.
>
> because we already have 'openstack baremetal driver show' as a command,
>> and other than wanting to see a description of the logical disk properties,
>> the only other command related to the disk properties is 'openstack
>> baremetal node set --target-raid-config'.
>>
>
> Possible confusion on my part... the properties you want to display as
> part of 'baremetal driver show' are set with 'baremetal node set'?  That
> assymetry may be part of the reason this was ambiguous to start with.
>

A baremetal node has an associated driver; it is the driver that handles
the node (powering, booting, deploying, RAID configuration, ...). The RAID
logical disk properties describe the information that the driver needs, for
doing RAID configuration. e.g. [1]. Maybe it should be
--raid-logical-disk-property-descriptions?  But the actual configuration is
specific to a particular node, and that is set via the ..node set
--target-raid-config (which can specify one or more logical disks). e.g.
[2].

Maybe we could make it easier on ourselves by not providing an API to get
descriptions of things, but "just" document them. :)

--ruby

[1]
http://developer.openstack.org/api-ref/baremetal/index.html?expanded=show-driver-logical-disk-properties-detail
[2]
http://developer.openstack.org/api-ref/baremetal/index.html?expanded=set-raid-config-detail
__
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] openstack/python-ironicclient

[Ruby Loo]

On Tue, Sep 6, 2016 at 8:11 AM, Galyna Zholtkevych <
gzholtkev...@mirantis.com> wrote:

> Dear all,
>
> Ironic community needs a help to decide on the specification
>
> of the openstack client command that provide the same functionality as
>
> 'ironic driver-raid-logical-disk-properties' .
>
> Some propositions violate openstack client conventions for a user.
>
> For now the available propositions are:
>
> * openstack baremetal driver raid-logical-disk-properties show
>
> * openstack baremetal driver show --raid-logical-disk-properties
>
> * openstack baremetal driver raid logical disk properties show
>
> * openstack baremetal driver show raid-logical-disk-properties
>
> * openstack baremetal driver show raid logical-disk-properties
>
>
> Reference to the appropriate discussion: https://bugs.launchpad.net/
> python-ironicclient/+bug/1619052
>
>
>
Hi Galyna,

Thanks for asking. These two won't work because 'openstack baremetal driver
show' exists as a command, and the code won't be able to interpret these as
different commands:

   * openstack baremetal driver show raid-logical-disk-properties

   * openstack baremetal driver show raid logical-disk-properties


I think the OSC way is to use English so of these two, probably the second
one is the right way:

* openstack baremetal driver raid-logical-disk-properties show

* openstack baremetal driver raid logical disk properties show


My preference is:

* openstack baremetal driver show --raid-logical-disk-properties


because we already have 'openstack baremetal driver show' as a command, and
other than wanting to see a description of the logical disk properties, the
only other command related to the disk properties is 'openstack baremetal
node set --target-raid-config'.


The problem, though, is that this only shows the disk properties, nothing
else about the driver. The information is different, so that trying to use
this command to show the driver information AND the disk property
descriptions, doesn't make sense either.


If we thought that we might have some 'openstack baremetal driver raid
' command in the future, then 'openstack baremetal driver
raid logical disk properties show' might make more sense. (Now I'm leaning
towards this one.)


Do we really want a way for the user to get this information? Another
choice is not to provide any command for this. (Just kidding.)


--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

[openstack-dev] [ironic][OpenStackClient] deprecated commands (was Re: Upcoming OpenStackClient 3.0 Release (Monday))

[Ruby Loo]

Hi,

On Sun, Aug 21, 2016 at 9:08 PM, Dean Troyer  wrote:

> We're excited to pre-announce the release of OSC 3.0.0. The release is
> expected to be approved by the release team during their working hours on
> Monday 22 Aug 2016.
>
> This is a **huge** release, and we shuffled things around so we've bumped
> our major version. We tried our darndest to not break anything, and where
> applicable we deprecated things instead. We have a small number of known,
> documented breaking changes, which is why we did a major version bump,
> please keep this in mind when upgrading.
> ...
>
The known breaking changes are:
>   - The `ip floating` commands have been renamed to `floating ip` -- check
> the help output for details.  The old commands are still present but
> deprecated and no longer appear in help output.
>
>
For the deprecated commands -- will they be supported forever, or is there
some deprecation policy that OSC follows? In ironic, we have three OSC
commands that we've deprecated, but we don't know when/if we can ever
delete them.

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are yodelling to present this week's subteam report for Ironic. As
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 18 July 2016)
- Ironic: 216 bugs (+15) + 204 wishlist items (+3). 21 new (+8), 160 in
progress (+15), 0 critical, 31 high (+2) and 19 incomplete (-2)
- Inspector: 11 bugs (+2) + 20 wishlist items (-1). 0 new, 11 in progress
(+3), 0 critical, 2 high and 2 incomplete
- Nova bugs with Ironic tag: 11 (+2). 0 new, 0 critical, 1 high (+1)

Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)

* trello:
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- working on potential FFE for nova things

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
- dtantsur has to catch up with recent gate changes, several jobs seem to
be added
- likely xenial jobs? some names changed too but those should be
replacements
- there was a refactoring that seems to have added a lot of jobs to
JJB, see the full list in the pad below
- discussed the number of jenkins jobs with openstack-infra team last week,
with some proposals on how to reorganize our jobs
- https://etherpad.openstack.org/p/ironic-jjb-matrix

Node search API (jroll, lintan, rloo)
=
* trello: https://trello.com/c/j35vJrSz/24-node-search-api
- probably not a priority with new scheduling/multi-compute plans

Node claims API (jroll, lintan)
===
* trello: https://trello.com/c/3ai8OQcA/25-node-claims-api
- probably not a priority with new scheduling/multi-compute plans

Multiple compute hosts (jroll, devananda)
=
* trello: https://trello.com/c/OXYBHStp/7-multiple-compute-hosts
- We have a simple path forward: https://review.openstack.org/#/c/348443/
- uses a hash ring to distribute nodes between compute services
- Nova team has agreed to let that in this cycle

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Specification updated
- Code being actively developed, although requires volume connection
informa
tion.
- Volume connection information changes need reviews as they are required
for boot-from-volume
-
https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1526231

Agent top-level API promotion (dtantsur)

* trello:
https://trello.com/c/37YuKIB8/28-promote-agent-vendor-passthru-to-core-api
- the heartbeat implementation was approved (fails in gate though), now
rebasing everything else

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- blocked by ongoing discussion about interfaces defaults
- to a lesser extent blocked by agent API promotion

OpenStackClient plugin for ironic (thrash, dtantsur, rloo)
==
* trello: https://trello.com/c/ckqtq3kG/16-openstackclient-plugin-for-ironic
- port and chassis commands:
https://review.openstack.org/#/q/topic:bug/1526479
- baremetal create command: https://review.openstack.org/328955

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- Update August 1st, 2016
- Patches for notifications base class and power state notification up
for review
- Mario still has to respond to comments on base class patch,
should have another patch set up today
- yuriyz has proposed a spec for notifications on provision state
changes

Keystone policy support (JayF, devananda)
=
* trello: https://trello.com/c/P5q3Es2z/15-keystone-policy-support
- code complete, fixing minor issues, hope to land today.

Active node creation (TheJulia)
===
* trello: https://trello.com/c/BwA91osf/22-active-node-creation
- Tempest test and test substrate changes need reviews
https://review.openstack.org/#/q/topic:bug/1526315+status:open

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- console_utils: merged
- IPMITool driver interface: merged
- follow-on patches: need review
- https://review.openstack.org/#/c/335378/
- https://review.openstack.org/#/c/349400/
- install guide: needs review (being reviewed by primary contacts)
https://review.openstack.org/#/c/293872/

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- A proper grenade job is now running in our gate \o/
- switching to voting if/when it proofs stable enough
- ironic-inspector-client to be released soon

.

Until 

Re: [openstack-dev] [ironic] API docs now publishing from our tree

[Ruby Loo]

Sweet. Thanks Jim (and everyone else that made this happen).

I do want to make sure there is one "source of truth" to the API
documentation. We are already generating REST API documentation at
http://docs.openstack.org/developer/ironic/webapi/v1.html. The info for
this comes from docstrings etc in our code files.

To make it easier and so that documentation doesn't get out of sync, I
don't really want people to have to remember to update the code/docstrings
as well as the new files that were added to generate this new api-ref
documentation.

--ruby


On Wed, May 4, 2016 at 5:10 PM, Jim Rollenhagen 
wrote:

> Hey y'all,
>
> I did the push this week to move the api-ref into our tree, and it's now
> publishing. \o/
>
> The docs are here: http://developer.openstack.org/api-ref/baremetal/
>
> The source is here:
> http://git.openstack.org/cgit/openstack/ironic/tree/api-ref/source
>
> I know devananda is doing a push to update some things there. If you'd
> like to help clean up and improve our docs, please sync with him. They
> need a lot of love, so all help is welcome. :)
>
> // 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

[openstack-dev] [ironic] Newton priorities and primary contacts

[Ruby Loo]

Hi,

At the Austin summit, we had a session where we discussed and decided on
what the top priorities would be for ironic, in the newton development
cycle. The etherpad [1] captures that discussion, and there is a patch up
to add the newton priorities to our specs [2].

Everyone, and in particular all ironic cores, should take a look at the
priorities [2] because as a community, we should all have the same
understanding and be working towards the same goals. Of course, side goals
are fine too :D

I also wanted to mention the primary contacts for these priorities, because
I'm not sure that I have the same understanding as others, as to what it
means.

My understanding is that the primary contacts are the folks that would take
the lead for an item. Their responsibilities would include knowing the
status of it, and to do their 'best' to get it done, regardless of whether
they themselves did the design, code, documentation, review, etc. Ideally,
I'd prefer to see one primary contact per item, but if people want to work
together, that is fine, as long as it works.

If you are interested in a particular feature on this list, or would like
to contribute code towards that end, or would like to help review, or test,
that is wonderful and I thank you so much for your interest and desire to
contribute. However, I would really like to see primary contacts do more,
as described above. To take responsibility and (try to) commit the
time/effort it will take to see this priority items through.

Is this in line with what others think/expect from the primary contacts?

--ruby


[1] https://etherpad.openstack.org/p/ironic-newton-summit-priorities
[2] https://review.openstack.org/#/c/311530/
__
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] upgrade support between which versions of ironic?

[Ruby Loo]

Hi,

Currently, ironic doesn't support ("live", "online", "rolling", or
minimal-downtime) upgrades between named versions of ironic. (Where "named
version" is the final release or stable release that is associated with a
development cycle). So for example, Liberty -> Mitaka release.

We've been working towards that, and have a spec [1] and a design session
[2] at the Austin Summit. Upon reading the spec, I started to wonder --
what do we mean/want, when we talk about supporting upgrades. Do we want to
support:
A. sequential named releases, eg. Mitaka -> Newton
B. sequential major releases, eg 4.x -> 5.0; 5.0 -> 6.1
C. sequential minor releases, eg 5.1 -> 5.2
D. last named release to master
E. last release (major or minor) to master
F. some-SHA-more-recent-than-last-named to master. This could be some
numbered (major or minor) release.

Keep in mind that ironic may release any number of numbered releases
between two named releases, so eg. 4.3.0, 5.0.0, 5.1.0 == Mitaka, 5.2.0,
6.0.0, 6.1.0, 7.0.0, 7.1.0, 7.2.0 == Newton.

Note that there are two governance tags: supports-upgrade[3] and
supports-rolling-upgrade[4], and I believe our goal is for
supports-rolling-upgrade.

I think and hope that we can all agree that A. is a must :)

What constitutes a major release versus a minor release may have
implications in this, but that should be in a separate discussion.

What do people think?

--ruby

[1] https://review.openstack.org/299245
[2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9267
[3]
https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-upgrade.rst
[4]
https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-rolling-upgrade.rst
__
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] weekly subteam status report

[Ruby Loo]

On Mon, Apr 18, 2016 at 3:10 PM, Ruby Loo <opensr...@gmail.com> wrote:

> ...
> Network isolation (Neutron/Ironic work) (jroll)
> ===
> - Still needs review
> - cross-project session tuesday on the future of bare metal networking:
> https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
>

Oops, that should be
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9491


>
> https://etherpad.openstack.org/p/newton-baremetal-networking
> ...
>


Yes, I sometimes read these things ;)
--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are overjoyed to present this week's subteam report for Ironic. As
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 11.04.2016):
- Ironic: 203 bugs (+3) + 166 wishlist items (+3). 30 new (+5), 134 in
progress (-2), 1 critical (+1), 24 high (-2) and 18 incomplete
- Inspector: 13 bugs + 16 wishlist items (+1). 1 new, 6 in progress, 0
critical, 4 high and 0 incomplete
- Nova bugs with Ironic tag: 15 (-1). 0 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- Still needs review
- cross-project session tuesday on the future of bare metal networking:
https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
https://etherpad.openstack.org/p/newton-baremetal-networking

Live upgrades (lucasagomes, lintan)
===
- A PoC patch is ready: https://review.openstack.org/306357
- An Implementation referece to refact configdrive is also ready:
https://review.openstack.org/#/c/306358/

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- jroll working on re-writing specs

Nova Liaisons (jlvillal & mrda)
===
- mrda & jlvillal did a clean-up of the bug wiki
- https://wiki.openstack.org/wiki/Nova-Ironic-Bugs

Testing/Quality (jlvillal/krtaylor)
===
- Grenade: Interuppted by downstream work. Did have some progress but no
breakthroughs. Debugging continues.

Inspector (dtansur)
===
- rerunning introspection on stored data was merged (2 weeks ago), client
part ready for reviews
- HA spec getting updated

Drivers:

CIMC and UCSM (sambetts)

- CIMC and UCS CIs were stable as of 10:00am UTC 18th April

.

Until after the summit,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are nerdy to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 04.04.2016):
- Ironic: 200 bugs (+4) + 163 wishlist items. 25 new, 136 in progress (+1),
0 critical, 26 high and 18 incomplete (+2)
- Inspector: 13 bugs (-1) + 15 wishlist items (-1). 1 new, 6 in progress
(-1), 0 critical, 4 high and 0 incomplete (-1)
- Nova bugs with Ironic tag: 16 (+1). 1 new (+1), 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- Tests are green, needs core love
- The main meat:
- https://review.openstack.org/#/c/285852/
- (deva) some concerns on p31, brought up in ironic-neutron meeting
this morning. needs another rev to fix.
- https://review.openstack.org/#/c/206244/
- https://review.openstack.org/#/c/206144
- https://review.openstack.org/#/c/213262/

Live upgrades (lucasagomes, lintan)
===
- Propose a spec to discuss:
- https://review.openstack.org/#/c/299245/

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- expect an update on this spec before summit (hopefully this week)

Oslo (lintan)
=
- In order to make use oslo-config-generator, we should make ironic-lib
explore the options too.
- Patch is landed :https://review.openstack.org/#/c/297549/ so we need
to release a new version of ironic-lib
- release request: https://review.openstack.org/#/c/304229/

Testing/Quality (jlvillal/krtaylor)
===
- Grenade: No update this week.

Inspector (dtansur)
===
- Reprocessing stored node introspection data API merged, inspector client
patch in review

webclient (krotscheck / betherly)
=
- v1.1 has been released.

Drivers:

CIMC and UCSM (sambetts)

- Both CI down for 1hr because of HW upgrade, then should be back up and
testing.
- UCSM driver needs to prove itself then will be made voting, but seems to
be getting good results after a race condition was fixed on Monday morning.
.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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][nova][horizon] Serial console support for ironic instances

[Ruby Loo]

Yes, I think it would be good to have a summit session on that. However,
before the session, it would really be helpful if the folks with proposals
got together and/or reviewed each other's proposals, and summarized their
findings. You may find after reviewing the proposals, that eg only 2 are
really different. Or they several have merit because they are addressing
slightly different issues. That would make it easier to
present/discuss/decide at the session.

--ruby


On 12 April 2016 at 09:17, Jim Rollenhagen  wrote:

> On Tue, Apr 12, 2016 at 02:02:44AM +0800, Zhenguo Niu wrote:
> > Maybe we can continue the discussion here, as there's no enough time in
> the
> > irc meeting :)
>
> Someone mentioned this would make a good summit session, as there's a
> few competing proposals that are all good options. I do welcome
> discussion here until then, but I'm going to put it on the schedule. :)
>
> // jim
>
> >
> > On Fri, Apr 8, 2016 at 1:06 AM, Zhenguo Niu 
> wrote:
> >
> > >
> > > Ironic is currently using shellinabox to provide a serial console, but
> > > it's not compatible
> > > with nova, so I would like to propose a new console type and a custom
> HTTP
> > > proxy [1]
> > > which validate token and connect to ironic console from nova.
> > >
> > > On Horizon side, we should add support for the new console type [2] as
> > > well, here are some screenshots from my local environment.
> > >
> > >
> > >
> > > ​
> > >
> > > Additionally, shellinabox console ports management should be improved
> in
> > > ironic, instead of manually specified, we should introduce dynamically
> > > allocation/deallocation [3] mechanism.
> > >
> > > Functionality is being implemented in Nova, Horizon and Ironic:
> > > https://review.openstack.org/#/q/topic:bp/shellinabox-http-proxy
> > > https://review.openstack.org/#/q/topic:bp/ironic-shellinabox-console
> > > https://review.openstack.org/#/q/status:open+topic:bug/1526371
> > >
> > >
> > > PS: to achieve this goal, we can also add a new console driver in
> ironic
> > > [4], but I think it doesn't conflict with this, as shellinabox is
> capable
> > > to integrate with nova, and we should support all console drivers.
> > >
> > >
> > > [1] https://blueprints.launchpad.net/nova/+spec/shellinabox-http-proxy
> > > [2]
> > >
> https://blueprints.launchpad.net/horizon/+spec/ironic-shellinabox-console
> > > [3] https://bugs.launchpad.net/ironic/+bug/1526371
> > > [4] https://bugs.launchpad.net/ironic/+bug/1553083
> > >
> > > --
> > > Best Regards,
> > > Zhenguo Niu
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Zhenguo Niu
>
>
>
>
> >
> __
> > 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 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] weekly subteam status report

[Ruby Loo]

Hi,

We are merry to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 28.03.2016):
- Ironic: 196 bugs (+17) + 163 wishlist items (-1). 28 new (+3), 135 in
progress (+11), 0 critical, 26 high (+2) and 16 incomplete (+2)
- Inspector: 14 bugs (+4) + 16 wishlist items (+1). 1 new, 7 in progress
(+1), 0 critical, 4 high (+1) and 1 incomplete (+1)
- Nova bugs with Ironic tag: 15 (-1). 0 new, 0 critical, 0 high
- Monthly diff (with 07.03):
- Ironic: 196 bugs (+39) + 163 wishlist items (-12), 135 in progress (+20)
- Inspector: 14 bugs (+5) + 16 wishlist items (+1), 7 in progress (+1)
- New bugs are coming so fast :(

Network isolation (Neutron/Ironic work) (jroll)
===
- tests are green, let's review things :)

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work

Nova Liaisons (jlvillal & mrda)
===
- Bug scrub conducted.

Doc (jroll, liliars)

- http://lists.openstack.org/pipermail/openstack-dev/2016-March/090274.html

Testing/Quality (jlvillal/krtaylor)
===
- Grenade work was done due to stable/mitaka release. jlvillal now has it
to state as it was before stable/mitaka release. There are some patches
waiting to be merged.
- Grenade. Currently at state where Ironic bare-metal VM does not get its
IP address. Need to investigate why dnsmasq is configured incorrectly at
that point.

webclient (krotscheck / betherly)
=
- Incorporating UX Feedback in progress:
https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient+branch:master+topic:ux

Drivers:

CIMC (sambetts)
---
- Third party CI for this driver is stable and voting

UCSM (sambetts)
---
- Third party CI for this driver is non-voting right now while network
issues are resolved

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are lucky to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 14.03.2016):
- Ironic: 179 bugs (+12) + 164 wishlist items (-10). 25 new (+6), 124 in
progress (+3), 0 critical, 24 high and 14 incomplete (+1)
- Inspector: 10 bugs (+1) + 15 wishlist items (-1). 1 new, 6 in progress, 0
critical, 3 high (+1) and 0 incomplete
- Nova bugs with Ironic tag: 16 (+1). 0 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- bumping to newton :(

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning

Multiple compute hosts (jroll, devananda)
=
- newton

Oslo (lintan)
=
- Oslo hope oslo libraies can be implemented in more projects and list a
mature libraries list:
- https://etherpad.openstack.org/p/oslo-libraries-adoption
- We adopt most libraries except oslo-config-generator

Inspector (dtansur)
===
- python-ironic-inspector-client 1.6.0 was released for mitaka with only
requirements updates (thanks jroll)

Bifrost (TheJulia)
==
- 1.0 released last week.

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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 Julia Kreger for core reviewer

[Ruby Loo]

On 24 March 2016 at 15:08, Jim Rollenhagen  wrote:

> Hey all,
>
> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> the Bifrost project, gives super valuable reviews, is beginning to lead
> the boot from volume efforts, and is clearly an expert in this space.
>
> All in favor say +1 :)
>
> // jim
>
>
+1! Great idea. :D

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are keen to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 07.03.2016):
- Ironic: 167 bugs (+10) + 174 wishlist items (-1). 19 new (+3), 121 in
progress (-2), 0 critical, 24 high (+2) and 13 incomplete (+1)
- Inspector: 9 bugs + 16 wishlist items (+1). 1 new (+1), 6 in progress, 0
critical, 2 high and 0 incomplete
- Nova bugs with Ironic tag: 15 (-1). 0 new, 0 critical, 0 high
- dtantsur on PTO Mar 21-25

Network isolation (Neutron/Ironic work) (jroll)
===
- bumping to newton :(

RAID (lucasagomes)
==
- done \o/

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning

Multiple compute hosts (jroll, devananda)
=
- newton

Nova Liaisons (jlvillal & mrda)
===
- Bug scrub performed. No updates besides that.

Testing/Quality (jlvillal/krtaylor)
===
- Grenade: Narrowed down problem to what appears to be an issue with DHCP
not being configured correctly. As can see the DHCP address not being given
to the Ironic bare-metal node.
- Grenade: Troubleshooting/debugging continues

Inspector (dtansur)
===
- Released ironic-inspector 3.2.0 - the final release for Mitaka
- stable/mitaka was created from this release
- Released ironic-inspector 2.2.5 for Liberty with 2 bug fixes

Bifrost (TheJulia)
==
- Expecting to release 1.0 monday or tuesday.

Drivers:

OneView (gabriel-bezerra/thiagop/sinval/liliars)

- Dynamic allocation
- spec: https://review.openstack.org/#/c/275726/
- implementation: https://review.openstack.org/#/c/286192/
- docs: [wip]

CIMC (sambetts)
---
- Third Party CI for this driver is very close to complete, had to add
monkey patch for Ironic flavor in tempest
.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are jubilant to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 07.03.2016):
- Ironic: 167 bugs (+10) + 174 wishlist items (-1). 19 new (+3), 121 in
progress (-2), 0 critical, 24 high (+2) and 13 incomplete (+1)
- Inspector: 9 bugs + 16 wishlist items (+1). 1 new (+1), 6 in progress, 0
critical, 2 high and 0 incomplete
- Nova bugs with Ironic tag: 15 (-1). 0 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- bumping to newton :(

RAID (lucasagomes)
==
- just needs docs landed: https://review.openstack.org/#/c/226330/

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning

Multiple compute hosts (jroll, devananda)
=
- newton

Testing/Quality (jlvillal/krtaylor)
===
- Grenade: Attempting to determine why virtual bare-metal node fails to
come up. It fails to PXE boot. Not yet sure why it is failing. In parallel
working on scripts to help parse log files.
- Grenade: For the most part, most people are getting past the 'smoke test'
portion of stable/liberty before failing. jlvillal has two systems, one
fails in "Running base smoke test" other passes and fails in "Running
resource phase create"

Inspector (dtansur)
===
- ironic-inspector 3.1.0 is out with a bunch of features
-
http://docs.openstack.org/releasenotes/ironic-inspector/mitaka.html#id2
- we are in a soft feature freeze: please concentrate on landing bug fixes,
documentation and small improvements
- we still have one FFE, the deadline is today:
https://review.openstack.org/289825
- the release team expect us to make the final release on Thursday,
this will become the stable/mitaka
- stable/mitaka for python-ironic-inspector-client created from the 1.5.0
release
- this time it covers all the API changes we landed in mitaka, w00t :)
\o/

Bifrost (TheJulia)
==
- No update aside from gate was broken over the weekend due to bare-trusty
to ubuntu-trusty image switch.  Fix landed this morning, gate should be in
working order now.

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are itchy to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 29.02.2016):
- Ironic: 157 bugs (-5) + 175 wishlist items (-3). 16 new, 115 in progress
(-8), 0 critical, 22 high and 12 incomplete
- Inspector: 9 bugs (-1) + 15 wishlist items. 0 new, 6 in progress, 0
critical, 2 high and 0 incomplete
- Nova bugs with Ironic tag: 16. 0 new, 0 critical, 0 high
- monthly diff (with 01.02.2016):
- Ironic: 157 bugs (+6) + 175 wishlist items (+4), 115 in progress (+4)
- Inspector: 9 bugs (-5) + 15 wishlist items (-2), 6 in progress (-4)

Network isolation (Neutron/Ironic work) (jroll)
===
- API changes blocked pending driver-loading refactoring here:
https://review.openstack.org/#/c/285852/.
- Devananda is going to take over starting Monday
- Woud like to get this in for a release later this week.
- LAG support in Nova not merged yet, unlikely to land in Mitaka:
https://review.openstack.org/#/c/206163
- client patches did not make M3 milestone (Mitaka client freeze):
https://review.openstack.org/#/c/206144

Manual cleaning (rloo)
==
- Everything is done except for GET clean steps API, which is deferred to
Newton.
- Removing this subteam item.

RAID (lucasagomes)
==
- RAID CLI is now merged https://review.openstack.org/#/c/226234/
- RAID documentation still being reviewed
https://review.openstack.org/#/c/226330/

Parallel tasks with futurist (dtantsur)
===
- This was done for ironic and inspector!
- Removing this subteam item.

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning

Nova Liaisons (jlvillal & mrda)
===
- No status update

Testing/Quality (jlvillal/krtaylor)
===
- Grenade work continuing. jlvillal/mgould are attempting to root cause
current issue

Inspector (dtansur)
===
- dnsmasq dhcp ip address hash collisions resolved by a config file update
(dhcp-sequential-ip)
- I'd like to make a release as soon as the keystoneauth patch merges

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] Remember to follow RFE process

[Ruby Loo]

> Hi,
>>
>> > Ironic'ers, please remember to follow the RFE process; especially the
>> cores.
>> >
>> > I noticed that a patch [1] got merged yesterday. The patch was
>> associated
>> > with an RFE [2] that hadn't been approved yet :-( What caught my eye was
>> > that the commit message didn't describe the actual API change so I took
>> a
>> > quick look at the (RFE) bug and it wasn't documented there either.
>>
>
Thanks everyone! I see that the RFE has been approved, although I don't see
what the CLI/API change is. I'm guessing it was to add --driver or
something like that to 'ironic node-list' and a similar thing for the
openstack client plugin and API :)

--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

[openstack-dev] When to revert a patch?

[Ruby Loo]

Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process'
thread:

> Should we revert the patch [1] for now? (Disclaimer. I haven't looked at
>> the
>> > patch itself. But I don't think I should have to, to know what the API
>> > change is.)
>> >
>>
>> Thanks for calling it out Ruby, that's unfortunate that the patch was
>> merged without the RFE being approved. About reverting the patch I
>> think we shouldn't do that now because the patch is touching the API
>> and introducing a new microversion to it.
>>
>
> Exactly. I've -2'ed the revert, as removing API version is even worse than
> landing a change without an RFE approved. Let us make sure to approve RFE
> asap, and then adjust the code according to it.
>
>

This brings up another issue, which I recall discussing before. Did we
decide that we'd never revert something that touches the API/microversion?
It might be good to have guidelines on this if we don't already. IF the API
is incorrect? If the API could be improved? If the API was only in master
for eg 48 hours?

--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

[openstack-dev] [ironic] Remember to follow RFE process

[Ruby Loo]

Hi,

Ironic'ers, please remember to follow the RFE process; especially the cores.

I noticed that a patch [1] got merged yesterday. The patch was associated
with an RFE [2] that hadn't been approved yet :-( What caught my eye was
that the commit message didn't describe the actual API change so I took a
quick look at the (RFE) bug and it wasn't documented there either.

As a reminder, the RFE process is documented [3].

Spec cores need to try to be more timely wrt specs (I admit, I am guilty).
And folks, especially cores, ought to take more care when reviewing.
Although I do feel like there are too many things that a reviewer needs to
keep in mind.

Should we revert the patch [1] for now? (Disclaimer. I haven't looked at
the patch itself. But I don't think I should have to, to know what the API
change is.)

--ruby


[1] https://review.openstack.org/#/c/264005/
[2] https://bugs.launchpad.net/ironic/+bug/1530626
[3]
http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are happy to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 22.02.2016):
- Ironic: 162 bugs (+6) + 178 wishlist items (+3). 16 new (+2), 123 in
progress (+5), 0 critical, 22 high (+3) and 12 incomplete (+1)
- Inspector: 10 bugs + 15 wishlist items. 0 new, 6 in progress (-1), 0
critical, 2 high (-1) and 0 incomplete
- Nova bugs with Ironic tag: 16. 0 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- refactoring of the driver patch in progress:
- https://review.openstack.org/285850
- https://review.openstack.org/285851
- https://review.openstack.org/285852
- need reviews on this :)

Manual cleaning (rloo)
==
- done. sort of. GET clean steps API is not done; deferring to Newton.

RAID (lucasagomes)
==
- https://review.openstack.org/226234 CLI
- https://review.openstack.org/226330 documentation

Parallel tasks with futurist (dtantsur)
===
- MERGED \o/
- similar work is ongoing for inspector: https://review.openstack.org/286022

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning

Nova Liaisons (jlvillal & mrda)
===
- Did a quick check. No new activity this week as far as bug activity.

Testing/Quality (jlvillal/lekha/krtaylor)
=
- Progress was made on grenade. jlvillal was able to get it locally to run
the devstack portion successfully on the stable/liberty branch
- There is a regression issue in stable/liberty:
https://bugs.launchpad.net/bugs/1549095  jlvillal will likely propose a
work-around patch for the issue.
- Have not come to a solution on how to make Grenade only test
baremetal things. Solution that is acceptable to be pushed upstream. Having
working local solution (jlvillal)
- Verifying M2 milestone for CI test systems - first pass complete, have a
few questions on some systems
- https://etherpad.openstack.org/p/IronicCI

Inspector (dtansur)
===
- Released ironic-inspector 2.2.4 for liberty with 2 bug fixes
- feature reviews wanted: https://review.openstack.org/#/c/267637/ run
introspection on previously stored data

Drivers:

 AMT (lintan)
-
- Migrating to Ironic-staging-driver project, there will be no CI for AMT
driver :(

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are glad to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 08.02.2016):
- Ironic: 156 bugs (-1) + 175 wishlist items (+5). 14 new, 118 in progress
(+2), 0 critical, 19 high and 11 incomplete (+2)
- Inspector: 10 bugs (-2) + 15 wishlist items (-1). 0 new, 7 in progress
(-1), 0 critical, 3 high (-1) and 0 incomplete
- Nova bugs with Ironic tag: 16 (-7). 0 new (-1), 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- made good progress during midcycle
- first API patch is very close
- second patch needs a major refactoring
- network provider looks like a driver interface, let's make it the
first composable driver
- however, that spec doesn't define the API yet :(

Manual cleaning (rloo)
==
- most has landed! \o/
- docs still need review
- get clean steps from API patch needs a rebase

Live upgrades (lucasagomes, lintan)
===
- agreement during midcycle: halt work on the "no-db API service". We do
not believe this is necessary for live upgrades.
- need to get grenade tests working to validate

Parallel tasks with futurist (dtantsur)
===
- Ready for review: https://review.openstack.org/264720
- There are 2 Futurist changes that fix behaviour with extremely low thread
number (e.g. 3)
- merged, will hopefully be released this week

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning
- talked about this at midcycle
- spec to be split into two distinct specs, one for filters and one for
claims
- this part isn't actually the contentious part, rather the nova side
(pushing scheduling decisions down to ironic)  is what people are concerned
with

Nova Liaisons (jlvillal & mrda)
===
- Performed a complete bug scrub during the mid-cycle of all open bugs.
Closed 7 of 23 bugs.

Testing/Quality (jlvillal/lekha/krtaylor)
=
- Grenade: jlvillal will resurrect his patches to make the tempest tests
run the baremetal tests for grenade, like we run for our normal gate jobs
- Put work on trying to make the tempest smoke tests pass for Ironic on the
back burner for now.
- Resurrected patches:
- https://review.openstack.org/#/c/241018/
- https://review.openstack.org/#/c/241044/
- Already -1ed - what are these "tempest flags" and how do we use them?

Inspector (dtansur)
===
- Released ironic-inspector 2.2.4 for liberty with 2 bug fixes
- HA discussion is ongoing: https://review.openstack.org/253675
- API for aborting introspection landed in both the inspector and client

Bifrost (TheJulia)
==
- Gate is presently broken for bifrost -
https://review.openstack.org/#/c/283108/ will correct this issue.

webclient (krotscheck / betherly)
=
- api work fixed - working to split large patch before merging
- tests underway

Drivers:

CIMC (sambetts)
---
- Hardware aquired and accounts created, need to install test environment
now

.

Until next week,
--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,


We are elated to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

- Stats (diff with 25.01.2016):

- Ironic: 151 bugs (-1) + 171 wishlist items (+7). 14 new (-1), 111 in
progress (+3), 0 critical, 19 high (-1) and 9 incomplete

- Inspector: 14 bugs + 17 wishlist items. 0 new, 10 in progress (+1), 0
critical, 6 high and 0 incomplete

- Nova bugs with Ironic tag: 23. 0 new, 0 critical, 0 high

- January summary (diff with 04.01):

- Ironic: bugs +0, wishlist items +22, in progress +12


Network isolation (Neutron/Ironic work) (jroll)

===

- please review :D

- nova patch for portgroups will be delayed until Newton, due to length of
time it will take to land -sigh-

- Garbutt said a client API version bump to make it usable will likely
be okay, but it will also need to wait for client/api patches


RAID (lucasagomes)

==

- still waiting for manual cleaning to land (needs reviews)


Parallel tasks with futurist (dtantsur)

===

- futurist 0.10 released with my changes, we should be good to continue as
soon as we get our gate back :)


Node filter API and claims endpoint (jroll, devananda, lucasagomes)

===

- no update; deprioritized in favor of neutron work, manual cleaning

- (rloo, could you leave this note until it changes? :) sure :D


Testing/Quality (jlvillal/lekha/krtaylor)

=

- krtaylor sent out reminder about 3rd Party CI for M-2

- having trouble getting drivers paired up with test systems listed
(krtaylor)

- https://wiki.openstack.org/wiki/ThirdPartySystems - please make sure
your system account is created and registered here

-  https://etherpad.openstack.org/p/IronicCI - list the link from the
above wiki here

- jlvillal continues to work on Grenade testing. Investigating if we need
to have 3 bare- metal VMs to run tempest and do we have enough memory to do
that.


Inspector (dtansur)

===

- Our gates use IPA by default now (except for -dib check job on inspector
itself)


webclient (krotscheck / betherly)

=

- plugin wrapper almost merged upstream

- panel being separated out into sections for upstreaming into the plugin

- node details showing locally and being tested now


.


Until next week,

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Gate failures dominated the news last week and as this week starts to pick
up steam, it looks like gate failures will again dominate the news. On
other fronts...


Hi,


We are delighted to present this week's subteam report for Ironic. As
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

- Stats (diff with 18.01.2016):

- Ironic: 152 bugs (+4) + 164 wishlist items (+2). 15 new, 108 in progress
(+6), 0 critical (-1), 20 high (+2) and 9 incomplete (-1)

- Inspector: 14 bugs (-4) + 17 wishlist items. 0 new, 9 in progress (-1), 0
critical (-1), 6 high (-2) and 0 incomplete

- Nova bugs with Ironic tag: 23 (-1). 0 new, 0 critical, 0 high


Network isolation (Neutron/Ironic work) (jroll)

===

- code working well, needs reviews.

- going to need a client release before the last of the nova code lands, so
we need to get this done quickly


Manual cleaning (rloo)

==

- hiccup; vdrok pointed out that IPA needs to be updated to support this (
https://review.openstack.org/#/c/247695/)


Live upgrades (lucasagomes, lintan)

===

- Ready to review:

- https://review.openstack.org/#/c/261443/

- https://review.openstack.org/#/c/253355/


Parallel tasks with futurist (dtantsur)

===

- No updates (waiting for Futurist release)


Testing/Quality (jlvillal/lekha/krtaylor)

=

- Had weekly meeting

- More info in minutes:
http://eavesdrop.openstack.org/meetings/ironic_qa/2016/ironic_qa.2016-01-20-17.00.log.html


Inspector (dtansur)

===

- ironic-inspector 2.2.3 (liberty) released with one bug fix

- python-ironic-inspector-client 1.4.0 released

- ironic-inspector 3.0.0 released deprecating the bash ramdisk


webclient (krotscheck / betherly)

=

- User research summarising in progress for plugin and webclient

- Designs in progress for webclient and v2 plugin based on user research

- plugin being wrapped at present and working on issues re getting horizon
to accept it

- betherly helping ppiela (Peter) become setup on openstack for the first
time ready to help contribute on plugin - welcome to openstack and the team!


Drivers:



 AMT (lintan)

-

- patch for creating a shared wsman-client for AMT and DRAC drivers is up
for review: https://review.openstack.org/#/c/269122/


DRAC (ifarkas/lucas)



- patch for creating a shared wsman-client for AMT and DRAC drivers is up
for review: https://review.openstack.org/#/c/269122/


.


Until next week,

--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

[openstack-dev] [ironic] weekly status report

[Ruby Loo]

Hi,


We are cool to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

- Stats (diff with 11.01.2016):

- Ironic: 148 bugs (+1) + 162 wishlist items (+4). 15 new (+1), 102 in
progress (+3), 1 critical, 18 high (+1) and 10 incomplete (-1)

- Inspector: 18 bugs (+3) + 17 wishlist items (+1). 0 new, 10 in progress
(+3), 1 critical (+1), 8 high and 0 incomplete

- Nova bugs with Ironic tag: 24 (-2). 0 new, 0 critical, 0 high

- over 100 in-progress bugs, we/I need to start checking their status

- though never-working gate might be to blame


Network isolation (Neutron/Ironic work) (jroll)

===

- needs reviews


Manual cleaning (rloo)

==

- getting there; saw more activity this last week. one patch got merged:
247285, one patch got approved: 251995, and others are getting reviewed

- https://review.openstack.org/#/q/topic:bug/1526290


Parallel tasks with futurist (dtantsur)

===

- waiting for Futurist release (and for gate to recover) to continue

- WIP patch is still WIP: https://review.openstack.org/264720


Node filter API and claims endpoint (jroll, devananda, lucasagomes)

===

- (Not totally related but) https://review.openstack.org/#/c/267723 to
split capabilities out of properties


Oslo (lintan)

=

- A new lib(OSprofiler) under oslo umbrella was created for trace calls and
this can across multi-project too. It is suggested to send notification to
ceilometer using oslo.messaging for all HTTP/RPC/DB/Driver Calls. This is
helpful for admin to debug the bottleneck or error. It is already used by
Cinder, Heat, Glance and Nova(working), do we have a interest for this in M
release?

- https://review.openstack.org/#/c/103825/

- https://github.com/openstack/osprofiler

- [deva] yes, interested. If the patch to Ironic can land in M, great -
but definitely for N release, we should add this.


Inspector (dtansur)

===

- Gate is down due to DIB regression

- the fix has landed, waiting for the DIB release to happen and to hit
the gate


Bifrost (TheJulia)

==

- Gate was fixed last week, special thanks goes out ot Infra.

- No additional updates.


.


Until next week,

--ruby


[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] [oslo][osdk] PrettyTable needs a home in OpenStack

[Ruby Loo]

On 11 January 2016 at 10:27, Doug Hellmann  wrote:

> ...
>
>
> There are a few libraries on the list, too (automaton, ironic-lib), and
> that's confusing. It would be interesting to know how they're using
> table output.
>
> Doug
>
>
As far as ironic-lib goes, I took a look. It isn't using PrettyTable so out
it goes: https://review.openstack.org/267213.

Thanks for mentioning it Doug!

--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

[openstack-dev] [ironic] weekly subteam report

[Ruby Loo]

Hi,


We are buzzed to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

- Stats (diff with 04.01.2016):

- Ironic: 147 bugs (-4) + 158 wishlist items (+9). 14 new (-9), 99 in
progress (+7), 1 critical (+1), 17 high (+3) and 11 incomplete (+2)

- Inspector: 15 bugs + 16 wishlist items (+1). 0 new, 7 in progress (+2), 0
critical (-1), 8 high (+1) and 0 incomplete

- Nova bugs with Ironic tag: 26. 1 new, 0 critical, 0 high

- Important issues:

- https://bugs.launchpad.net/ironic/+bug/1532174
gate-ironicclient-dsvm-functional failed after moving ironic to devstack
plugin


Network isolation (Neutron/Ironic work) (jroll)

===

- very close, seems to work, needs reviews


Manual cleaning (rloo)

==

- Have 2 +2's, need +A: https://review.openstack.org/#/c/247285/ &
https://review.openstack.org/#/c/247695/


Live upgrades (lucasagomes, lintan)

===

- Propose a patch to seperate the configs for api and conductor seperately,
this will help users to run Ironic with multi-conductors easily

- https://review.openstack.org/#/c/261443


Parallel tasks with futurist (dtantsur)

===

- WIP posted: https://review.openstack.org/#/c/264720/ (dsvm passes, unit
tests not updated yet)

- required change in futurist: https://review.openstack.org/#/c/265360/

- nice-to-have change in futurist: https://review.openstack.org/#/c/264250/


Testing/Quality (jlvillal/lekha/krtaylor)

=

- Work continues on fixing grenade testing. jlvillal has been working on
setting up a local testing environment. Ran into some issues like:

- httplib2 not understanding CIDR addressing in 'no_proxy' (tempest)
https://github.com/jcgregorio/httplib2/issues/323

- devstack halting while runniing apt-get. Patch submitted to fix
issue. https://bugs.launchpad.net/devstack/+bug/1532080

- Was able to run the ironic tempest job successfuly, but the grenade
job is failing in a different area. Investigation continues.

- mimic was added to the global-requirements file. So it can now be used in
Ironic.


Inspector (dtansur)

===

- fixed gate issues related to ironic switch to a devstack plugin

- switching to IPA as a main ramdisk:

- in inspector: https://review.openstack.org/#/c/263730/

- in project-config: https://review.openstack.org/#/c/264168/


Bifrost (TheJulia)

==

- Bifrost gate is presently broken due to infra mysql module upgrade which
had a subtle but adverse change for "bare" nodepool test instances -
https://review.openstack.org/#/c/265348/


.


Until next week,

--ruby


[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are amazed to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 21.12.2015):
- Ironic: 151 bugs (+8) + 149 wishlist items. 23 new (+5), 92 in progress
(+1), 0 critical, 14 high and 9 incomplete
- Inspector: 15 bugs (+3) + 15 wishlist items (+1). 0 new, 5 in progress, 1
critical (+1), 7 high and 0 incomplete
- Nova bugs with Ironic tag: 26. 1 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- patches under review

Live upgrades (lucasagomes, lintan)
===
- patches ready to review:
- https://review.openstack.org/#/q/topic:refactor-object-registry
- https://review.openstack.org/#/q/topic:bp/online-upgrade-support

Inspector (dtansur)
===
- gate is broken again by ironic's move to a plugin:
https://bugs.launchpad.net/devstack/+bug/1530675 :(
- fix is approved

webclient (krotscheck / betherly)
=
- plugin:
- the plugin is in a slight limbo position waiting to see if someone
will send me through work on converting the panel to plugin (we split the
work and then she left her job) - hopefully i wont have to redo that
section :’(
- on a happier note we are well on the way to the ironic plugin project
being official in openstack and ready to start pushing things up
- webclient
- Intel is working on the UI trying to finish-up user research
- been a little pushback from intel UX on "Hey why does this look like
horizon"
- The ironic-webclient will permit significant changes to the UI
from the horizon base template, IF those changes do not compromise code
reuse.
- (This basically means that nothing in the ./src/api/--.js may
be modified, but that's really only API abstractions).

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are eager to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- (no diff)
- Ironic: 143 bugs + 149 wishlist items. 18 new, 89 in progress, 0
critical, 14 high and 9 incomplete
- Inspector: 12 bugs + 14 wishlist items. 0 new, 5 in progress, 0 critical,
7 high and 0 incomplete
- Nova bugs with Ironic tag: 26. 1 new, 0 critical, 0 high
- dashboard updated to count wishlist items separately

Network isolation (Neutron/Ironic work) (jroll)
===
- no update, patches in review failing all tests :(

Multiple compute hosts (jroll, devananda)
=
- Time to push forward

ironic-lib adoption (rloo)
==
- Done! patch was merged: https://review.openstack.org/#/c/184443/

Nova Liaisons (jlvillal & mrda)
===
- mrda & jlvillal conducted bug scrub
- 3 bugs considered since last meeting
- Total of 25 bugs outstanding

Doc (jroll, liliars)

- Official docs install guide
- Discussion going over on docs ML
-
http://lists.openstack.org/pipermail/openstack-docs/2015-December/008113.html
- folks seem more open to include some other guides for mitaka,
lets see how it goes
- Versioned in-tree docs
-
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082207.html
- solved!

Inspector (dtansur)
===
- gate is down right now: https://review.openstack.org/#/c/259393/

webclient (krotscheck / betherly)
=
- krotscheck is back from vacation.
- New info on getting a server for UX things while HPCloud shuts down.

.

Until next year,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

We are overjoyed to present this week's subteam report for Ironic. As
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
(diff with Dec 7)
- Open: 179 (+4). 16 new (+4), 58 in progress (-3), 0 critical (-1), 13
high (-3) and 9 incomplete
- Nova bugs with Ironic tag: 25 (+1). 0 new, 0 critical, 0 high
- Inspector bugs: 28 (+14). 0 new, 0 critical, 7 high (+1)
- no panic: substantial bug number increase is probably due to move to RFE
process

Network isolation (Neutron/Ironic work) (jroll)
===
- in review
- ironic:
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/network_provider,n,z
- nova:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ironic-networks-support,n,z
- devstack support:
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/ironic-ml2-integration,n,z

Manual cleaning (rloo)
==
- awaiting reviews:
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/manual-cleaning,n,z

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- POC code for indexing the node's properties field:
https://review.openstack.org/#/c/252531/

Multiple compute hosts (jroll, devananda)
=
- basically stuck in a place where we can't make everyone happy
- started a thread on the ML, hoping to get some action there

ironic-lib adoption (rloo)
==
- *almost* there. patch +A'd, waiting for Jenkins to be happy:
https://review.openstack.org/#/c/184443/

Doc (jroll, liliars)

- the admin guide has a baremetal/trouble-shooting section. Yay!
-
http://docs.openstack.org/admin-guide-cloud/baremetal.html#troubleshooting
- please make sure we don't have duplicated info (like the
troubleshooting).
http://docs.openstack.org/developer/ironic/4.3.0/deploy/troubleshooting.html.
Eg, put link in our dev docs to admin guide
- official docs: release-specific pages
- only install guide (doesn't include us) and config-reference
(includes us)
- to change old versions of such docs we need to send a patch tagged
with the specific version and they will updtate accordingly. not an
automatic process as we wanted/expected;
- official docs: install guides page
- consensus is pointing to the creation of  a second, supplementary
Install Guide for other components.
- Manila folks started a thread on this (
http://lists.openstack.org/pipermail/openstack-docs/2015-December/008051.html
)

Testing/Quality (jlvillal/lekha/krtaylor)
=
- CI spec merged! https://review.openstack.org/#/c/241294/
- vendor/driver communication sent
- current discussion on what to do with valuable drivers that are not fully
CI tested, contrib progect repo?
- this weeks subteam meeting (Wed 16-Dec 1700 UTC) is the last meeting for
the year

Inspector (dtansur)
===
- We've moved from blueprints to RFE bugs
- HA architecture is being discussed, we welcome more opinions:
https://review.openstack.org/253675

Bifrost (TheJulia)
==
- 0.1.0 was released on 12/14.

webclient (krotscheck / betherly)
=
- designs underway for v2 of the plugin
- v1 (panel wrapped in plugin) working on getting node details viewing
correctly

Drivers:

iRMC (naohirot)
---
https://review.openstack.org//#/q/owner:+naohirot+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- iRMC out of band inspection (FRE Bug: #1525108)
- Status: Active
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- Add 'abort' support for Soft Power Off and Inject NMI
(bp/task-control-functions-for-long-running-tasks)
- iRMC OOB rescue mode support (bp/irmc-oob-rescue-mode-support)

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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 operations on nodes in maintenance mode

[Ruby Loo]

On 23 November 2015 at 18:35, Shraddha Pandhe 
wrote:

> Hi,
>
> I would like to know how everyone is using maintenance mode and what is
> expected from admins about nodes in maintenance. The reason I am bringing
> up this topic is because, most of the ironic operations, including manual
> cleaning are not allowed for nodes in maintenance. Thats a problem for us.
>
>
So what are the reasons for not allowing manual cleaning when a node is in
maintenance (and in manageable state)?

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,


We are pleased to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

(diff with Nov 30)

- Open: 175 (+1). 12 new (+1), 61 in progress (+1), 1 critical (+1), 16
high and 9 incomplete (-2)

- Nova bugs with Ironic tag: 24. 0 new, 0 critical, 0 high

- Inspector bugs: 14 (+1). 0 new, 0 critical, 6 high



Network isolation (Neutron/Ironic work) (jroll)

===

- devstack and project-config patches are up to provide CI

- 01: https://review.openstack.org/#/c/247513/

- 02: https://review.openstack.org/#/c/248048/

- 03: https://review.openstack.org/#/c/249717/

- 04: https://review.openstack.org/#/c/248074/

- ironic patches still need review

- nova spec was merged, patches are being reviewed/updated



Manual cleaning (rloo)

==

- patch with API to do manual cleaning is now available

- patches to be reviewed:
https://review.openstack.org/#/q/topic:bp/manual-cleaning,n,z



Live upgrades (lucasagomes, lintan)

===

- Propose add config to set version cap for rpc api:

- https://review.openstack.org/#/c/253355/



Node filter API and claims endpoint (jroll, devananda, lucasagomes)

===

- Spec for reestructing the database
https://review.openstack.org/#/c/253605/



Multiple compute hosts (jroll, devananda)

=

- no news / review seems to be stuck



ironic-lib adoption (rloo)

==

- ironic-lib 0.5.0 has been released; waiting for requirements to be
updated: https://review.openstack.org/#/c/250002/

- patch for ironic to use ironic-lib 0.5.0:
https://review.openstack.org/#/c/184443/



Doc (jroll, liliars)



- conversation with docs team about install guide

- apparently we are not in the scope for the official page

- AI (jroll) -> send email to ML confirming this and/or see what we can
do about it

- identified some points of improvement on cloud admin guide

- AI (liliars) -> dig some more info on versioned docs

- jroll also proposing a thing about this in the email mentioned above ^



Testing/Quality (jlvillal/lekha/krtaylor)

=

- A patch to use the Tempest plugin has been proposed for Ironic:
https://review.openstack.org/246161

- driver CI test requirements have been communicated with vendor teams

- new CI spec is near completion, hopefully will be approved soon?

- ironic testing wiki has been updated with some of the highlights of the
coming process (thanks thingee)



Inspector (dtansur)

===

- our docs are now published at
http://docs.openstack.org/developer/ironic-inspector/

- spec process is in effect:
https://github.com/openstack/ironic-inspector-specs/

- python-ironic-inspector-client 1.3.0 released

-
http://docs.openstack.org/releasenotes/python-ironic-inspector-client/unreleased.html#id1
(slightly outdated)

- ironic-inspector 2.3.0 released

-
http://docs.openstack.org/releasenotes/ironic-inspector/unreleased.html#id1



Bifrost (TheJulia)

==

- Inspection support has landed.

- Compatability issues with Debian Jessie have been identified which will
hold us from releasing at this time.



webclient (krotscheck / betherly)

=

- UX is peforming interviews, we've already got our initial feedback up on
invision and are incorporating it as we go.

- Waiting on update from BadCub on potential hardware lab resources.

- UX Demo site is at http://15.126.254.85/#/ironic , we're investigating
whether we can do patch-based UX testing as well.



Drivers:



iRMC (naohirot)

---

https://review.openstack.org//#/q/owner:+naohirot+status:+open,n,z

- Status: Reactive (solicited for core team's review)

- iRMC out of band inspection (bp/ironic-node-properties-discovery)

- Status: Active

- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)

- Add 'abort' support for Soft Power Off and Inject NMI
(bp/task-control-functions-for-long-running-tasks)

- iRMC OOB rescue mode support (bp/irmc-oob-rescue-mode-support)


.


Until next week,

--ruby


[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] Announcing Third Party CI for Proliant iLO Drivers

[Ruby Loo]

On 30 November 2015 at 11:25, Gururaj Grandhi 
wrote:

> Hi,
>
>
>
>  This is to announce that  we have  setup  a  Third Party CI
> environment  for Proliant iLO Drivers. The results will be posted  under
> "HP Proliant CI check" section in Non-voting mode.   We will be  running
> the basic deploy tests for  iscsi_ilo and agent_ilo drivers  for the
> check queue.  We will first  pursue to make the results consistent and
> over a period of time we will try to promote it to voting mode.
>
>
>
>For more information check the Wiki:
> https://wiki.openstack.org/wiki/Ironic/Drivers/iLODrivers/third-party-ci
> , for any issues please contact ilo_driv...@groups.ext.hpe.com
>
>
>
>
>
> Thanks & Regards,
>
> Gururaja Grandhi
>
> R Project Manager
>
> HPE Proliant  Ironic  Project
>
>
>
(I now know that these announcements shouldn't be posted but since this
was, I think it merits ...)

Yay, that's awesome! Thanks for setting this up so quickly. Good thing
we're not competitive; otherwise I'd say this is a challenge to the other
vendors out there :D

--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

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

[Ruby Loo]

On 30 November 2015 at 10:19, Derek Higgins  wrote:

> Hi All,
>
> A few months tripleo switch from its devtest based CI to one that was
> based on instack. Before doing this we anticipated disruption in the ci
> jobs and removed them from non tripleo projects.
>
> We'd like to investigate adding it back to heat and ironic as these
> are the two projects where we find our ci provides the most value. But we
> can only do this if the results from the job are treated as voting.
>

What does this mean? That the tripleo job could vote and do a -1 and block
ironic's gate?


>
> In the past most of the non tripleo projects tended to ignore the
> results from the tripleo job as it wasn't unusual for the job to broken for
> days at a time. The thing is, ignoring the results of the job is the reason
> (the majority of the time) it was broken in the first place.
> To decrease the number of breakages we are now no longer running
> master code for everything (for the non tripleo projects we bump the
> versions we use periodically if they are working). I believe with this
> model the CI jobs we run have become a lot more reliable, there are still
> breakages but far less frequently.
>
> What I proposing is we add at least one of our tripleo jobs back to both
> heat and ironic (and other projects associated with them e.g. clients,
> ironicinspector etc..), tripleo will switch to running latest master of
> those repositories and the cores approving on those projects should wait
> for a passing CI jobs before hitting approve. So how do people feel about
> doing this? can we give it a go? A couple of people have already expressed
> an interest in doing this but I'd like to make sure were all in agreement
> before switching it on.
>
> This seems to indicate that the tripleo jobs are non-voting, or at least
won't block the gate -- so I'm fine with adding tripleo jobs to ironic. But
if you want cores to wait/make sure they pass, then shouldn't they be
voting? (Guess I'm a bit confused.)

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,


We are elated to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

(diff with Nov 23)

- Open: 174 (+3). 11 new, 60 in progress, 0 critical, 16 high and 11
incomplete

- Nova bugs with Ironic tag: 24. 0 new, 0 critical, 0 high

- Inspector bugs: 13 (-1). 0 new, 0 critical, 6 high

- bug number is slowly growing since 28.09.2015 (135 open bugs)

- bugs to be aware of before the release this week:

- https://bugs.launchpad.net/ironic/+bug/1507738 - gives headache to people
with CentOS 7, might be considered a regression (status: fix on review)

- https://bugs.launchpad.net/ironic/+bug/1512544 - "grenade jobs are
failing" does not sound promising (status: in progress, no patch attached)

- https://bugs.launchpad.net/ironic/+bug/1408067 - do we still experience
these?



Network isolation (Neutron/Ironic work) (jroll)

===

- nova spec has landed; 2/3 patches are updated and passing unit tests

- ironic reviews still ongoing...



Live upgrades (lucasagomes, lintan)

===

- Submit a patch to add test to enforce object version bump correctly

- https://review.openstack.org/#/c/249624/ MERGED



Boot interface refactor (jroll)

===

- done!

- let's remove this one for next meeting \o/



Parallel tasks with futurist (dtantsur)

===

- still refactoring manager.py a bit:
https://review.openstack.org/#/c/249938/ is WIP



Node filter API and claims endpoint (jroll, devananda)

==

- spec still in review - https://review.openstack.org/#/c/204641



Multiple compute hosts (jroll, devananda)

=

- dependant on node filter API


ironic-lib adoption (rloo)

==

- ironic-lib 0.4.0 has been released and updated in requirements, patch is
almost ready (needs reno) but holding off til after ironic release:
https://review.openstack.org/#/c/184443/



Nova Liaisons (jlvillal & mrda)

===

- No meetiing/updates



Testing/Quality (jlvillal/lekha/krtaylor)

=

- No meeting/updates



Inspector (dtansur)

===

- Fully switched to Reno for both inspector projects

- e.g
http://docs.openstack.org/releasenotes/python-ironic-inspector-client/unreleased.html

- Documentation is now using Sphinx, will appear on
docs.openstack.org/developer/ironic-inspector this week

- python-ironic-inspector-client to be released this week, ironic-inspector
does not seem to have enough changes

- ironic-inspector-specs addition is proposed to the TC



Bifrost (TheJulia)

==

- Gate job is working again, presently looking at refactoring non-voting
test job.



webclient (krotscheck / betherly)

=

- Panel currently being wrapped in plugin. Actions on the nodes are
working. Details page to do then start port



Drivers:



DRAC (ifarkas/lucas)



- patches refactoring the driver to use python-dracclient instead of
pywsman are on gerrit


iLO (wanyen)



- 3rd party CI:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080806.html


iRMC (naohirot)

---

https://review.openstack.org//#/q/owner:+naohirot+status:+open,n,z

- Status: Reactive (solicited for core team's review)

- iRMC out of band inspection (bp/ironic-node-properties-discovery)

- Status: Active

- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)

- Add 'abort' support for Soft Power Off and Inject NMI
(bp/task-control-functions-for-long-running-tasks)

- iRMC OOB rescue mode support (bp/irmc-oob-rescue-mode-support)

- Status: Done, thanks!

- New boot driver interface for iRMC drivers (bp/new-boot-interface)


.


Until next week,

--ruby


[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] Releases and things

[Ruby Loo]

On 25 November 2015 at 18:02, Jim Rollenhagen 
wrote:

> Hi all,
>
> We're approaching OpenStack's M-1 milestone, and as we have lots of good
> stuff in the master branch, and no Mitaka release yet, I'd like to make
> a release next Thursday, December 3.
>
> First, I've caught us up (best I can tell) on missing release notes
> since our last release. Please do review them:
> https://review.openstack.org/#/c/250029/
>
> Second, please make sure when writing and reviewing code, that we are
> adding release notes for anything significant, including important bug
> fixes. See the patch above for examples on things that could be
> candidates for the release notes. Basically, if you think it's something
> a deployer or operator might care about, we should have a note for it.
>
> How to make a release note:
> http://docs.openstack.org/developer/reno/usage.html
>
>
Jim, thanks for putting together the release notes! It isn't crystal clear
to me what ought to be mentioned in release notes, but I'll use your
release notes as a guide :)

This is a heads up to folks that if you have submitted a patch that
warrants mention in the release notes, you ought to update the patch to
include a note. Otherwise, (sorry,) it will be -1'd.



> Last, I'd love if cores could help test the master branch and try to
> dislodge any issues there, and also try to find any existing bug reports
> that feel like they should definitely be fixed before the release.
>
>
I think this also means that we shouldn't land any patches this coming
week, that might be risky or part of an incomplete feature.


> After going through the commit log to build the release notes patch, I
> think we've done a lot of great work since the 4.2 release. Thank you
> all for that. Let's keep pushing hard on our priority list and have an
> amazing rest of the cycle! :D
>

Hear, hear!

--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

Re: [openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

[Ruby Loo]

On 20 November 2015 at 18:32, Ben Nemec  wrote:

> On 11/19/2015 06:00 AM, Lucas Alvares Gomes wrote:
> > Hi,
> >
> >> Also keep in mind that DEBUG logging, while still should have some
> masking
> >> of data, since it is explicitly called out (or should be) as not safe
> for
> >> production, can contain some " sensitive" data. Credentials should
> still be
> >> scrubbed, but I would say the swift temp URL is something that may line
> up
> >> with this more flexible level of filtering logs.
> >>
> >> Now, if the service (and I don't think ironic suffers from this issue)
> is
> >> only really runnable with debug on (because there is no useful
> information
> >> otherwise) then I would aim to fix that before putting even potentially
> >> sensitive data in DEBUG.
> >>
> >> The simple choice is if there is even a question, don't log it (or log
> it in
> >> a way that obscures the data but still shows unique use).
> >>
> >
> > I agree with Morgan's statement here.
> >
> > And just throwing an idea in the wind here, we could make use of the
> > python logging filters to create a filter for sensitive information.
> > We probably need one already to avoid having to do things like [1] in
> > the code.
>
> We actually have a thing to do that:
>
> https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L215
>
> You might need to add a new key to the list of things to mask, but I
> think it should be able to handle masking the log message for you.  I
> don't know whether configdrive is a globally sensitive key, but if not
> then we probably need to revisit the question of whether to allow
> extending the key list dynamically in the consuming application instead
> of having only the one hard-coded list.  More context here:
> https://bugs.launchpad.net/oslo.utils/+bug/1407811
>
>
The problem is that the developer WANTS to see the temporary URL, so
masking it defeats the whole purpose.

The only thing I was thinking of (besides the developer modifying their
code to spit it out) is to have some additional level of debugging that
doesn't filter anything sensitive and/or add a config in ironic to log
'only-in-non-production-environments-shows-sensitive-info' with some big
warning...

My take on this (thanks everyone) is that it is a potential security risk
to expose the URL in the logging, so we shouldn't allow it without some
other way (besides expecting/documenting INFO level or higher) to prevent
it from showing up in production.

--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

Re: [openstack-dev] [ironic] specs process for ironic-inspector

[Ruby Loo]

On 19 November 2015 at 08:39, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi all,
>
> +1 for specs in general, big features require a proper review and
> discussion for which LP is not a good choice.
>
> +1 for not requiring a spec for small features, LP BP is enough for just
> time/release tracking, but of course cores can request a proper spec to be
> proposed if feeling feature is worth discussion.
>
> 0 for using ironic-specs. It will increase visibility to wider ironic
> community, sure. But it seems ironic-inspector has to decide how integrated
> it should be with the other ironic project infra pieces as well. For
> example, there is now a patch on review to build a proper sphinx docs for
> ironic-inspector. Should those then be published and where? Should
> ironic-inspector have own doc site e.g.
> http://docs.openstack.org/developer/ironic-inspector/, or somehow be
> incorporated in ironic doc site? IMO decision on specs and docs should be
> consistent.
>
>>

I tend to agree with Pavlo. I think it will be more consistent with the
ironic-inspector docs, bugs, launchpad if the specs are in their own
ironic-inspector-specs directory. Also, just looking at
http://specs.openstack.org/openstack/ironic-specs/, it isn't obvious to me
where/how to reorganize it to include ironic-inspector. And then we'd
probably want to address how to incorporate other projects eg IPA, bifrost
specs as well, which I'd rather not have to think about. :-)

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,


We are stoked to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.


Bugs (dtantsur)

===

(diff with Nov 16)

- Open: 171 (+4). 11 new (+1), 60 in progress (-1), 0 critical, 16 high
(+2) and 11 incomplete

- Nova bugs with Ironic tag: 24. 0 new (-1), 0 critical, 0 high

- Inspector bugs: 14. 0 new, 0 critical, 7 high



Network isolation (Neutron/Ironic work) (jroll)

===

- reviews in progress

- actively working on nova side:
https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+branch:master+topic:bp/ironic-networks-support,n,z

- have a solid plan for doing CI on this



Manual cleaning (rloo)

==

- state machine has been updated to allow manual clean flow

- code patches ready for review: https://review.openstack.org/#/c/247285/1
https://review.openstack.org/#/c/247695/,
https://review.openstack.org/#/c/247701/

- still need code patches for API-related parts, as well as documentation
and reno release notes



Live upgrades (lucasagomes, lintan)

===

- Propose a code guide for change of RPC/Object version

- https://review.openstack.org/#/c/248647/


ironic-lib adoption (rloo)

==

- ironic-lib 0.4.0 released with 'root_helper' config

- ironic patch to use ironic-lib: https://review.openstack.org/#/c/184443/.
Getting really close...- code sets default value for ironic-lib's
'root-helper' config using value from 'rootwrap_config' config. But
ironic.conf.sample shows 'root-helper' default as ''. Two thoughts:
1. do not show root-helper config in the .sample (is that a
hack/misleading)? or 2. in ironic-lib, would it have been better to add a
method to set a global 'root-helper' variable instead of having the config?


Nova Liaisons (jlvillal & mrda)

===

- No update this week. jlvillal was in training


Oslo (lintan)

=

- oslo_config will set enforce_type=True by default, which means config
option's value should be correct type and valid value even in tests. Ironic
should fix violations ASAP.

- https://review.openstack.org/#/c/243430/



Doc (jroll, liliars)



- no updates, liliars is out for a bit



Testing/Quality (jlvillal/lekha/krtaylor)

=

- CI spec making progress, nearing merge?

- subteam meeting mainly centered around CI, all driver dependency checking



Inspector (dtansur)

===

- still debugging IPA gate, suspected cause is low memory for VM's



Drivers:



iLO (wanyen)



- iLO driver document has been submitted since Sept. and it is still under
review.  To make the review easier, we have splitted this document patch
into 5 smaller patches :

- https://review.openstack.org/240132- Updates ilo documentation for
mistakes

- https://review.openstack.org/240136- Adds Swift HTTPS information

- https://review.openstack.org/240141-Converts the deploy process
documentation to diagrams

- https://review.openstack.org/241893-Adds documentation for Swiftless
deploy

- https://review.openstack.org/242333-refactor ilo documentation for
duplicate information

- https://review.openstack.org/242771- Adds information on HTTPs based
deploy

- https://review.openstack.org/242774- Adds Standalone ilo drivers
documentation.

- Since the up-to-date  iLO driver document did not make to Liberty, we
really need to land these patches in master branch so that users can have
documentation for iLO driver's Liberty features.  Your review will be
highly appreciated.


iRMC (naohirot)

---

https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z

- Status: Active

- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)

- OOB rescue mode support (bp/oob-rescue-mode-support)

- Status: Reactive (solicited for core team's review)

- New boot driver interface for iRMC drivers (bp/new-boot-interface)

- iRMC out of band inspection (bp/ironic-node-properties-discovery)


.


Until next week,

--ruby


[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

On 17 November 2015 at 01:34, Naohiro Tamura 
wrote:

> Ruby,
>
> Thanks for taking care of our weekly status report.
> I'd like to just let you know that the iRMC part is somehow consolidated
> with old statuses which I reported two and three weeks ago.
> If this report were generated by a script, I thought it would be necessary
> to update. :-)
>
> Best regards,
> Naohiro
>
>
Oh. Whoops. Thanks for letting me know!

--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

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

[Ruby Loo]

On 19 November 2015 at 09:25, Brad P. Crochet  wrote:

> I have pushed up a draft of the spec. Let's move comments there.
>
> I tried to incorporate as much as I could from the discussion here.
> There was a lot of disjointed suggestions and was a bit difficult to
> follow. So I've taken what I can. It can be refined in the spec
> itself.
>
> https://review.openstack.org/247539


Thanks!

--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

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

[Ruby Loo]

> > Another idea I floated last week was to do a virtual midcycle of sorts.
> > Treat it like a normal midcycle in that everyone tells their management
> > "I'm out for 3-4 days for the midcycle", but they don't travel anywhere.
> > We come up with an agenda, see if there's any planning/syncing work to
> > do, or if it's all just hacking on code/reviews.
> >
> > Then we can set up some hangouts (or similar) to get people in the same
> > "room" working on things. Time zones will get weird, but we tend to
> > split into smaller groups at the midcycle anyway; this is just more
> > timezone-aligned. We can also find windows where time zones overlap when
> > we want to go across those boundaries. Disclaimer: people may need to
> > work some weird hours to do this well.
>

 I'm willing to try it if the timing works out. I'm mostly upstream anyway.
But weird hours isn't my 'thing'. So maybe I am a +1/2? :)

People that want to work together on something should feel free to get
together with hangout or whatever and not wait for some designated date to
do so.

--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

[openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

[Ruby Loo]

Hi,

I think we all agree that it isn't OK to log credentials (like passwords)
in DEBUG logs. However, what about other information that might be
sensitive? A patch was recently submitted to log (in debug) the SWIFT
temporary URL [1]. I agree that it would be useful for debugging, but since
that temporary URL could be used (by someone that has access to the logs
but no admin access to ironic/glance) eg for fetching private images, is it
OK?

Even though we say that debug shouldn't be used in production, we can't
enforce what folks choose to do. And we know of at least one company that
runs their production environment with the debug setting. Which isn't to
say we shouldn't put things in debug, but I think it would be useful to
have some guidelines as to what we can safely expose or not.

I took a quick look at the security web page [2] but nothing jumped out at
me wrt this issue.

Thoughts?

--ruby

[1] https://review.openstack.org/#/c/243141/
[2] https://security.openstack.org
__
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] [neutron][ironic] Ironic-Neutron meeting cancellation notice

[Ruby Loo]

On 15 November 2015 at 16:47, Sukhdev Kapur  wrote:

> Folks,
>
> We are canceling this week's Ironic-neutron integration meeting. I have a
> family obligation to take care of and I have not been able to find a
> replacement person who can chair this meeting. Therefore, we will cancel
> this week's meeting.
>
> Next meeting will take place on Monday, January 23 at the usual time at
> usual place.
>
>
That's Monday, November 23, not January 23 :D

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are stoked to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

(diff with Nov 9)
- Open: 167 (-4). 10 new (-2), 61 in progress (-2), 0 critical, 14 high and
11 incomplete (+1)
- Nova bugs with Ironic tag: 24 (-1). 1 new, 0 critical, 0 high
- Inspector bugs: 14 (-1). 0 new, 0 critical, 7 high (+1)

Network isolation (Neutron/Ironic work) (jroll)
==
- code still in review

Manual cleaning (rloo)
=
- spec approved:
http://specs.openstack.org/openstack/ironic-specs/specs/approved/manual-cleaning.html

Live upgrades (lucasagomes, lintan)

- Working on isolation ir-api from DB
- https://review.openstack.org/#/c/243497/

Boot interface refactor (jroll)
==
- patch landed: Refactor iscsi_ilo driver to use new boot interface
https://review.openstack.org/#/c/216538/
- 3 more patches to land - https://review.openstack.org/#/c/221371/
(iscsi_irmc), https://review.openstack.org/#/c/221577/ (agent_irmc),
https://review.openstack.org/#/c/217102/ (agent_ilo)

Node filter API and claims endpoint (jroll, devananda)
=
- spec under review
- planning to split to two specs this week - the api and the db things

Multiple compute hosts (jroll, devananda)
- waiting on claims api

ironic-lib adoption (rloo)
==
- patch for ironic to use ironic-lib: https://review.openstack.org/184443.
It is currently blocked due to rloo (and deva) being unhappy with how
configs are being handled between ironic & ironic-lib.
- We will migrate (and deprecate) deploy's 'efi_system_partition_size',
'dd_block_size', 'iscsi_verify_attempts' configs to ironic-lib.
- ironic-lib includes code that makes system calls (via oslo's
processutils.execute()). For ironic, some of these calls need to be run as
root and rootwrap/filter information. Apparently, for IPA, none of them
need to be run as root. So we're going to modify ironic-lib as follows:
- modify ironic-lib to take one 'root_helper' config instead of having
'rootwrap_config' & 'rootwrap_helper_cmd' configs:
https://bugs.launchpad.net/ironic-lib/+bug/1515943. ironic will set this
value as 'sudo ironic-wrap /etc/ironic/rootwrap.conf'
- ironic-lib will need to provide sample rootwrap_filters file and will
need to document usage of if. ironic will modify /etc/ironic/rootwrap.d to
include the new file.
- All executes that had (when in ironic) 'run_as_root' set will only
have it set if root_helper is set.
- do we deprecate ironic's rootwrap_config?
- In (almost) hindsight, I wonder if it would have been useful to have had
a spec to point out/resolve these issues before we created ironic-lib or
maybe these are the details to be hammered out when coding.

Oslo (lintan)
==
- oslo libraries will drop python 2.6 compatibility, but
python-ironicclient are still support py2.6. We should drop this recently,
any objections?
- https://review.openstack.org/244275
- let's drop it with the rest of the clients, which seems like right
about now :) // jroll
- I'll investigate if there's any additional details here and do
whatever is needed
- Oslo remove apiclient from oslo-incubation recently, apiclient and clutil
were widely used by python-*-clients. As suggested by oslo team, here is
the plan:
- Make a local copy of clituils and apiclient and maintain by ourself
- Adopt cliff+keystoneauth when it is necessary in future
- https://review.openstack.org/#/c/243578/

Doc (jroll, liliars)
=
- no updates from jroll
- initial discussion on splitting/improving install guide /liliars
- haven't contacted openstack docs team yet /liliars

Testing/Quality (jlvillal/lekha/krtaylor)

- meeting held last Wed at 1700UTC
- CI spec making good progress, documenting/agreement on details, krtaylor
to rev spec with all latest comments
- no update on grenade or functional testing

Inspector (dtansur)
===
- added non-voting IPA job. does not pass, something seems wrong around
TFTP/PXE. Investigating.

Drivers
==
AMT (lintan)
-
- (deva) in-tree AMT driver has been working reliably for past few weeks,
so I may stop maintaining my out-of-tree driver

iLO (wanyen)
--
- Need reviews on some iLO driver specs that have been around for a while:
- Add Zapping support to iLO drivers -
https://review.openstack.org/145404
- Add support for UEFI iSCSI boot - https://review.openstack.org/207337
- Enhance ilo drivers to do inband inspection -
https://review.openstack.org/201904

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- 

Re: [openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

[Ruby Loo]

On 10 November 2015 at 11:31, Dmitry Tantsur  wrote:

> On 11/10/2015 05:21 PM, Brad P. Crochet wrote:
>
>> On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur 
>> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to seek consensus (or at least some opinions) on patch
>>> https://review.openstack.org/#/c/206119/
>>> It proposed the following command:
>>>
>>>
>> I think it's time to actually just write up a spec on this. I think we
>> would be better served to spell it out now, and then more people can
>> contribute to both the spec and to the actual implementation once the
>> spec is approved.
>>
>> WDYT?
>>
>
> +1
>
> I'll block the first patch until we get consensus. Thanks for working on
> it!
>
>
+2. Sorry for not paying attention to this. In retrospect, it would have
been good to have had a spec before we landed any of the code.

When the subject has 'Quick' in it, it isn't quick, but thanks for raising
the issue Dmitry! :)

--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

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

[Ruby Loo]

On 10 November 2015 at 12:08, Dmitry Tantsur  wrote:

> On 11/10/2015 05:45 PM, Lucas Alvares Gomes wrote:
>
>> Hi,
>>
>> In the last Ironic meeting [1] we started a discussion about whether
>> we need to have a mid-cycle meeting for the Mitaka cycle or not. Some
>> ideas about the format of the midcycle were presented in that
>> conversation and this email is just a follow up on that conversation.
>>
>> The ideas presented were:
>>
>> 1. Normal mid-cycle
>>
>> Same format as the previous ones, the meetup will happen in a specific
>> venue somewhere in the world.
>>
>
> I would really want to see you all as often as possible. However, I don't
> see much value in proper face-to-face mid-cycles as compared to improving
> our day-to-day online communications.


+2.

My take on mid-cycles is that if folks want to have one, that is fine, I
might not attend :)

My preference is 4) no mid-cycle -- and try to work more effectively with
people in different locations and time zones.

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

(diff with Oct 19)
- Open: 171 (+11). 12 new (+9), 63 in progress (+22), 0 critical, 14 high
(+3) and 10 incomplete (-1)
- Nova bugs with Ironic tag: 25. 1 new (-1), 0 critical, 0 high
- Inspector bugs: 15. 1 new (+1), 0 critical, 6 high (-1)

dtantsur is finally back and has to catch up with bug triaging


ironic-lib adoption (rloo)
==
patch for disk partitioner code to use ironic-lib:
https://review.openstack.org/#/c/184443/, rloo +deva not happy with configs
moved to ironic-lib


Nova Liaisons (jlvillal & mrda)
===
Conducted bug scrub and did reviews of proposed patches.


Testing/Quality (jlvillal/lekha/krtaylor)

- Had first kickoff of weekly meeting.
https://wiki.openstack.org/wiki/Meetings/Ironic-QA
- jlvillal has been working on making Grenade work. Running into a few
roadblocks. jroll has been providing some assistance.
- First roadblock is that the Tempest 'smoke' job fails for Ironic. One
test is failing.
- Functional testing patch merged for python-ironicclient. The functional
tests are now passing in python-ironicclient.
- CI Spec/blueprint started: https://review.openstack.org/#/c/241294/
- Etherpad for testing/CI etc revived
https://etherpad.openstack.org/p/IronicCI


Inspector (dtansur)
===
- Inspector is release:managed now
- autodiscovery is being discussed (again), please see the mailing list:
-
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078166.html
- We now have a neutron RFE to support DHCP opts per network/subnet instead
of just per port:
-
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078172.html
- https://bugs.launchpad.net/neutron/+bug/1512666


Bifrost (TheJulia)
=
- Revisions for inspection support have been posted and could use some
reviews.
- Hoping to release next version of bifrost once inspection support has
landed.


Drivers
==

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)

   -
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Active (Resumed from Nov. 9th after the summit)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- OOB rescue mode support (bp/oob-rescue-mode-support)
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)


As discussed in today's ironic meeting [1], we will include subteam reports
(if available) for the mitaka project priorities [2] in the future.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
[1]
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-11-09-17.00.log.html
[2]
http://specs.openstack.org/openstack/ironic-specs/priorities/mitaka-priorities.html#network-isolation
__
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] Driver documentation in Ironic

[Ruby Loo]

>
> 2) Driver docs may not be backported to stable branches. This is a
> stable maintenance policy, not an Ironic policy. This problem is
> somewhat unique to Ironic as most major projects have deployer docs in
> the Ops guide repo, rather than in the code repo. I'm going to chat with
> some docs/stable maintenance people in Tokyo about this, however I also
> encourage you to do the same.
>
>
I think the issue of updating documentation on stable branches goes beyond
driver docs. I question whether we should be bundling the release-related
documentation with the code if it is near impossible to update that
documentation after a branch is created. For example, we have links to
release-related documentation, but they aren't correct. We released 4.2.1
(on stable/liberty branch), and the release notes there [0] don't show
release information for 4.2.1. You have to go to master [1] to see it :-(

How do the other projects do it (correctly), or is ironic the only one so
far that has in-tree documentation? It seems that after a stable branch is
cut for (some) projects, the docs team has 1 month or so beyond that to get
the documentation out. It would be great if the docs we currently maintain
in-tree could follow a similar schedule. (And how does the doc team deal
with updates to documentation for prior releases?)

--ruby

[0] http://docs.openstack.org/developer/ironic/4.2.1/releasenotes/index.html
[1] http://docs.openstack.org/developer/ironic/releasenotes/index.html
__
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] Driver documentation in Ironic

[Ruby Loo]

Hi Ramesh,

On 15 October 2015 at 11:53, Ramakrishnan G 
wrote:

>
>
> 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.
>

To date, when there is a driver documentation patch that is submitted, does
the driver team review them? Are there past cases where this has occurred
and there wasn't any 'useful' feedback from other reviewers before it got
the +A?


>
> 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.
>

My preference is for the driver documentation to be outside any ironic
repository that I feel responsible for reviewing. I.e., I want to reduce
the number of patches that need to be reviewed :) I would love if the
driver documentation was outside, reviewed by the driver folks (however
they want to review it) and their own tech writers or whatever.

I took a look at Jim's comments on that patch and I'll copy some of it here
(hope you don't mind Jim):

-

Totally opposed to documentation on the wiki. Docs should be reviewed
(anyone with an Launchpad account can edit the wiki without review).

Also, in-tree docs are so much prettier, and can be tied to a release if we
decide to do so. :)

If there's too much overhead with keeping docs in tree, let's solve *that*
problem rather than just removing the docs.

--

Ramesh -- assuming I'm the odd person out and most people want the
documentation in-tree, let's try to look at and address the overhead with
keeping docs in tree. Perhaps you could elaborate on the problems (the 2
points you mention in your email). Eg, do people feel like there are too
many nits or other unnecessary comments that cause too many revisions for
very-little-benefit, or that no one 'ever' looks at the patch, or that even
a 1-day delay in getting a patch merged is too long, or what?

--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

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

[Ruby Loo]

Hi Wan-yen,

On 19 October 2015 at 01:46, Wan-yen Hsu  wrote:

>
>
>  I fully agreed with Ramesh.  There is a need for driver owners to be able
> to quickly update their driver’s document.  Particularly, vendor's drivers
> have strong
>

What do you mean by 'quickly'? Quicker than it has been in the past I
assume, but what time frame do you think is reasonable?


> dependencies on their platform’s firmware.  For instance, a new release of
> firmware may have impact on vendor’s driver and may require a specific
> firmware settings or some workaround in driver configuration.  Therefore
> driver owners need to be able to update their driver documents to reflect
> support of firmware versions or hardware platforms, document firmware
> issues that have impacts to the drivers, …etc.   Also, as more and more
> features added to the
>

Driver owners ARE able to update their driver documents by submitting
patches.


> drivers and some features are related, sometimes it requires restructuring
> of the document to make it easier for readers to follow and understand.  I
> would very much
>

If restructuring is needed to make the documentation better, I would
welcome that very much.


> like to get tech writers to help my driver’s document but with current
> document review process and release schedule, it’s just very hard to do.
> As the result, document quality
>
suffers.  I really wish that we can give driver owner’s
>

I don't understand this. If you cannot get tech writers to help with your
driver documentation and your doc quality suffers, how does giving the
driver owner (who presumably wrote the driver doc that is suffering) more
control help? The doc quality will still suffer, won't it?


> more control of their documents and be able to update their driver
> documents when needed.
>
>
>

Perhaps you could define what 'more control' means and how you feel like
you've been restricted from doing this in the past. That would make it
easier for me to try to help come up with something that can address this
issue.

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

(diff with Oct 12, no diff for inspector)
- Open: 150 (+7). 3 new (+1), 41 in progress (+5), 2 critical (+2), 11 high
(-1) and 11 incomplete (+1)
- Nova bugs with Ironic tag: 25 (+1). 2 new (+1), 0 critical, 0 high
- Inspector bugs: 15 (+3). 0 new, 0 critical, 7 high (+3)


Neutron/Ironic work (jroll)

- Spec for nova work is up: https://review.openstack.org/237067
- Open question: how do we enforce uniqueness between port.address and
portgroup.address?
- reviews in progress


Testing/Quality (jlvillal/lekha/krtaylor)

- started work on patch to stand-up and tear-down ironic-api and
ironic-conductor services for functional testing. Code borrowed from Glance
project.
- parent patch proposed to allow running ironic-api and ironic-conductor
with "python -m ironic.cmd.api" or "python -m ironic.cmd.conductor"


Inspector (dtansur)
===
- Releasing ironic-inspector 2.2.2 this week due to a couple of bugs:
- https://bugs.launchpad.net/ironic-inspector/+bug/1506419
- https://bugs.launchpad.net/ironic-inspector/+bug/1506160


webclient (krotscheck / betherly)
=
- Update on the ironic panel in horizon: If we continue writing this in
angular it will NOT be merged for months because of the upstream battle on
horizon to work out angular standards. And even when it gets through the
waiting period it will likely have to change to adopt all the changes made
to the way angular should be written in horizon. Are you happy for me to
move ahead with this as a python panel and a good looking front end as a
temporary measure to using the webclient and working out how to improve
general front end in the longer term?


Drivers
==

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until the week of Nov. 9,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

- (diff with Oct 5, no diff for inspector)
- Open: 143 (+6). 2 new (-2), 36 in progress (+2), 0 critical, 12 high
(+5) and 10 incomplete (-3)
- Nova bugs with Ironic tag: 24 (-1). 1 new, 0 critical, 0 high
- Inspector bugs: 12. 0 new, 0 critical, 4 high
- liberty-rc-potential:
- https://bugs.launchpad.net/ironic/+bug/1502903


Neutron/Ironic work (jroll)

- This seems to be working end to end, reviews welcome
- Putting up a nova blueprint/spec this week and hacking on that part of it


ironic-lib adoption (dtantsur)
==
- patch is being worked on
- ironic-lib g-r patch still not merged:
https://review.openstack.org/#/c/231368/


Nova Liaisons (jlvillal & mrda)
===
Nothing to report. Did bug scrub as usual


Oslo (lintan)
=
- Ironic is missing a header X-Openstack-Request-Id in API response. In
order to track operations cross projects,  many services like
Nova/Glance/Neutron/Cinder/Keystone have a such request ID header with HTTP
responsed. Python-ironicclient also should save this header and return to
caller.  It sounds like a feature but file a bug for this at the moment:
https://bugs.launchpad.net/ironic/+bug/1505119
- can we actually file a blueprint (no spec) for this? Probably with a
link to the cross project spec // jroll
- Sure, add one blueprint:
https://blueprints.launchpad.net/ironic/+spec/add-x-openstack-request-id-header


Testing/Quality (jlvillal/lekha/krtaylor)

- jlvillal started investigating how Nova does their functional testing.
- Will start initial code work this week.
- Can we learn/help or is it not multiperson work?


Inspector (dtansur)
===
- etherpad for summit discussions:
https://etherpad.openstack.org/p/mitaka-ironic-inspector


webclient (krotscheck / betherly)
=
- work continuing on upstream ironic panel
- work continuing on ironic webclient also as longer term solution


Drivers
==

AMT (lintan)

- More comments and discussion are welcome for amt driver
https://etherpad.openstack.org/p/new-ironic-amt-driver


iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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

[Ruby Loo]

Looking forward to more cores!!!

On 8 October 2015 at 17:47, Jim Rollenhagen  wrote:

> Hi all,
>
> ...

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.
>

+2


> 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.
>

+2

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

- (diff with Sep 28, no diff for inspector)
- Open: 137 (+2). 4 new (-5), 34 in progress (-2), 0 critical, 7 high
and 13 incomplete (+4)
- Nova bugs with Ironic tag: 25 (+1). 1 new (+1), 0 critical, 1 high
- Inspector bugs: 12. 0 new, 0 critical, 4 high
- Need help with triaging:
- https://bugs.launchpad.net/ironic/+bug/1444631
- https://bugs.launchpad.net/ironic/+bug/1479128
- IPA got its own bug tracker:
https://bugs.launchpad.net/ironic-python-agent
- I moved all bugs I found to be related to the ramdisk part there
- http://ironic-divius.rhcloud.com/ now shows IPA bugs
- http://ironic-divius.rhcloud.com/ got a new revamp, now it should be
easier to spot what requires attention


Neutron/Ironic work (jroll)

- testing is ongoing, working well, just a few things to work out
- we can begin reviewing the patch chain
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/network_provider,n,z
- nova patch:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ironic-ml2-integration,n,z
- client patch:
https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient+branch:master+topic:bp/ironic-ml2-integration,n,z
- no work has been done yet on gate testing AFAIK :(
- work etherpad https://etherpad.openstack.org/p/ironic-neutron-mid-cycle


ironic-lib adoption (dtantsur)
==
- There are still patches syncing changes from ironic to ironic-lib, please
land them ASAP
- Patch to Ironic  to make notes in functions that are moving to
ironic-lib: https://review.openstack.org/231092
- ironic patch to use ironic-lib: https://review.openstack.org/#/c/184443/


Testing/Quality (jlvillal/lekha/krtaylor)

- Had IRC meeting with jlvillal/lekha/krtaylor discussing functional
testing.
- Patch submitted and merged to prepare for functional testing.
- Discovered mimic is not yet Python 3 compatible. lekha is working on
Python 3 compatibility as not allowed to add it to global-requierements
until it is.


Inspector (dtansur)
===
- ironic-inspector 2.2.1 was released to fix a critical issue (thanks
TheJulia for reporting)


Bifrost (TheJulia)
=
- Work begining to include support for inspector in a user deployment
process.


webclient (krotscheck / betherly)
=
- work has begun upstream to make the horizon panel for ironic
- Horizon to Ironic API layer in Python has been written
- corresponding Ironic API layer in Angular in progress


Drivers
==

AMT (lintan)

- [deva] in-tree pxe_amt driver still having serious issues with my NUC, so
I've updated https://github.com/devananda/ironic/tree/new-amt-driver for
liberty

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

(diff with Sep 21)
- Open: 135 (-1). 9 new (+2), 36 in progress (-5), 0 critical, 7 high (-5)
and 9 incomplete
- Nova bugs with Ironic tag: 24 (+1). 0 new, 0 critical, 1 high

dtantsur continues to ping people and unassign abandoned bugs


Neutron/Ironic work (jroll)

no major updates, code still being worked on


ironic-lib adoption (dtantsur)
==
dsvm gate is working (though non-voting) on ironic-lib, time to switch!
-  dtantsur: yeah, meanwhile I will check and decide on the
refactoring of ironic to use ironic-lib
-  dtantsur: I think faizan told he has patch almost ready.
- rameshg87 will have update by 9/29.


Nova Liaisons (jlvillal & mrda)
===
- No updates


Testing/Quality (jlvillal/lekha)
==
- Still waiting for feature freeze to be lifted from global requirements to
add mimic requirement. Pinged dhellman on IRC on 28-Sep-2015
- jlvillal will work on initial test directory re-organization on ironic
server for functional testing
- krtaylor to look at unit test coverage
- krtaylor to document real BM CI rollout for PowerKVM
- grenade upgrade testing status


Inspector (dtansur)
===
ironic-inspector 2.2.0 released
-
http://lists.openstack.org/pipermail/openstack-announce/2015-September/000659.html
- 3 blueprints finished, 14 bugs fixed
- stable/liberty was created from this release


Bifrost (TheJulia)
=
Gate fixed, release 0.0.1 cut last week.


webclient (krotscheck / betherly)
=
- discussions with Horizon last week assured that we should be able to work
with both Horizon and downstream team successfully
- discussions with Horizon downstream (HP) team have concluded that we will
meet half way to have a UX that does not 100% resemble the existing panels
but is not so different as to confuse users
- design underway currently for submission to UX team (Piet)
- panel creation underway
- Reviews have stalled out:
https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient,n,z


Drivers
==

DRAC (ifarkas/lucas)

no update - working on python-dracclient to reach feature parity with DRAC
driver


iRMC (naohirot)
--
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

As of Mon, Sep 21 (diff with Sep 14)
- Open: 136 (-6). 7 new (-4), 41 in progress (-7), 0 critical, 12 high (+1)
and 9 incomplete
- Nova bugs with Ironic tag: 23. 0 new, 0 critical, 1 high

I've started to go through the dashboard and pinging people about their
stale (>1 month of inactivity) bugs.
- I'll unassign/abandon everything where I won't get response next
Monday.


Neutron/Ironic work (jroll)

No updates // bumped to Mitaka


ironic-lib adoption (dtantsur)
==
- library released, but we didn't switch to it in time (DepFreeze)
- therefore, there will not be a liberty/stable branch of ironic-lib
- plan to switch as soon as Mitaka opens


Nova Liaisons (jlvillal & mrda)
===
- No updates


Oslo (lintan)
==
- Oslo verisonedobjects library adoption is done, the change of oslo
library should not break Ironic easily anymore.
- need reviews on https://review.openstack.org/#/c/224079/
- Oslo team is working on a solution to reload configuration of service.
It's still under heavy construction, but maybe interesting to someone.
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074558.html


Doc (pshige)
==
No updates


Testing/Quality (jlvillal/lekha)
==
- lekha: Has submitted a patch to do functional testing of
python-ironicclient using mimic. https://review.openstack.org/225375
 Blocked until mimic is added to global-requirements, which has to wait for
freeze to end
- krtaylor and lekha have both said they would like to be part of the
Testing/Quality subteam.
- Still need tempest to accept the API microversion testing patch
https://review.openstack.org/#/c/166386/


Inspector (dtansur)
===
- stable/liberty branch created for python-ironic-inspector-client at 1.2.0
release
- IPA is a fully supported inspection ramdisk now:
- doc: https://github.com/openstack/ironic-inspector#using-ipa
- one extra patch is awaiting review:
https://review.openstack.org/#/c/225092/ (upstreaming a couple of plugins)
- ironic-inspector 2.2.0 with stable/liberty expected this Thursday, stuff
to finish is tracked here:
- https://launchpad.net/ironic-inspector/+milestone/2.2.0


Bifrost (TheJulia)
=
- Bifrost's gate is broken presently due to current work in-flight in shade
authentication support that is presently broken.


webclient (krotscheck / betherly)
=
- in debates with horizon 


Drivers
==

IPA (jroll/JayF/JoshNang)
--
- jroll and trown working on packaging releases

iRMC (naohirot)
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Active (solicit core team's spec review for Ironic 4.2.0)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Status: Reactive
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)

OneView (gabriel-bezerra/thiagop/sinval)
---
- https://review.openstack.org/#/c/191822/
- Driver status: Code complete. Wating for reviews.
- python-oneviewclient lib status: Code complete, publishing to PyPi as
soon as infra creates the "-release" team.
- 3rd Party CI status: power and management integration tests running. Full
deployment tests for iSCSI and Agent drivers with good progress.



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] subteam leads

[Ruby Loo]

Hi Subteam Leads,

In today's weekly meeting[1], it was requested that if you have no updates,
to please indicate that in the status report, so that we can distinguish
between no-update versus not-providing-a-status-report.

If you aren't sure whether you're a lead, we think you are if your name is
next to one of the subteams listed in the etherpad[2] (under 'Subteam
status reports').

Thanks,
--ruby

[1] around 17:27:01,
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-09-21-17.01.log.html
[2] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] Liberty soft freeze

[Ruby Loo]

On 17 September 2015 at 21:50, Jim Rollenhagen 
wrote:

This may also mean in-band RAID configuration may not land; the
> interface in general did land, and drivers may do out-of-band
> configuration. We assumed that in-band RAID would be done through
> zapping. However, if folks can agree on how to do it during automated
> cleaning, I'd be happy to get that in Liberty if the code is not too
> risky. If it is risky, we'll need to punt it to Mitaka as well.
>

Ramesh had worked on this but removed the part that hooks into automated
cleaning [0]. One reason being that if a target RAID config wasn't
specified, does this mean the create-raid-config clean step is skipped
(considered successful), or does it mean that the cleaning operation fails.
After a bit of discussion on IRC[1], some of us think that having the clean
operation fail makes sense.

There are two patches that will help with this [2] & [3]. The code was
extracted from [0]. I think it may need more work but I won't be able to
look into it until next week. In the meantime, hopefully someone else
(Ramesh? anyone?) will pick it up :)

--ruby

[0] https://review.openstack.org/#/c/198238/, removed from revision 21
[1] 2015-09-17T21:21:54 ish,
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2015-09-17.log
[2] https://review.openstack.org/#/c/64/
[3] https://review.openstack.org/#/c/224938/
__
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] Suggestion to split install guide

[Ruby Loo]

On 11 September 2015 at 04:56, Dmitry Tantsur  wrote:

> Hi all!
>
> Our install guide is huge, and I've just approved even more text for it.
> WDYT about splitting it into "Basic Install Guide", which will contain bare
> minimum for running ironic and deploying instances, and "Advanced Install
> Guide", which will the following things:
> 1. Using Bare Metal service as a standalone service
> 2. Enabling the configuration drive (configdrive)
> 3. Inspection
> 4. Trusted boot
> 5. UEFI
>
> Opinions?
>
>
Thanks for bringing this up Dmitry. Any idea whether there is some sort of
standard format/organization of install guides for the other OpenStack
projects? And/or maybe we should ask Ops folks (non developers :-))

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

As of Mon, Sep 14 (diff with Sep 7)
- Open: 142 (+4). 11 new (+1), 48 in progress, 0 critical, 11 high and 8
incomplete (-1)
- Nova bugs with Ironic tag: 23. 0 new, 0 critical, 1 high

dtantsur didn't have time to ping people about their in-progress bugs, help
appreciated


Neutron/Ironic work (jroll)

getting bumped to M... pretty risky at this point, patches aren't ready, no
testing, etc :(


Oslo (lintan)
==
Dan Smith thinks it would be good if we finish migrating to
oslo.versionedobjects so that he doesn't break our code :) (rloo)


Doc (pshige)
==
email discussion about re-organizing the install guide (rloo)


Testing/Quality (jlvillal)
=
(Looking for more people interested in testing)
https://wiki.openstack.org/wiki/Ironic/Quality

- raghu has volunteered to investigate other projects functional testing,
for example ironic-inspector, nova-client, and nova
- lehka is looking into working on python-ironicclient functional testing
using mimic. But there is a requirements freeze at the moment, so can't add
mimic to global-requirements


Inspector (dtansur)
===
- python-ironic-inspector-client 1.1.0 released
- still a lot of stuff to land for liberty :(


Bifrost (TheJulia)
=
- Minor cleanup in progress, hopefully cutting initial release this week.


webclient (krotscheck / betherly)
=
- Discussions underway with horizon re how we can implement the existing UI
in a Horizon panel - will require python API wrapper to be written
- Once ironic and CORS successfully working on machine and connecting to
webclient then can bypass the add cloud screen and work can begin on the
actual dashboard


Drivers
==

iRMC (naohirot)
-
Status: Active (solicit core team's spec review for Ironic 4.2.0)
- New boot driver interface for iRMC drivers
- bp/new-boot-interface

Status: Reactive
- Enhance Power Interface for Soft Reboot and NMI
- bp/enhance-power-interface-for-soft-reboot-and-nmi

Status: Reactive
- iRMC out of band inspection
- bp/ironic-node-properties-discovery



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] [all] Base feature deprecation policy

[Ruby Loo]

On 3 September 2015 at 08:22, Thierry Carrez  wrote:

> ...
> In particular, the current proposal says:
>
> "At the very minimum the feature [...] should be marked deprecated (and
> still be supported) in the next two coordinated end-of-cyle releases.
> For example, a feature deprecated during the M development cycle should
> still appear in the M and N releases and cannot be removed before the
> beginning of the O development cycle."
>
> That would be a n+2 deprecation policy. Some suggested that this is too
> far-reaching, and that a n+1 deprecation policy (feature deprecated
> during the M development cycle can't be removed before the start of the
> N cycle) would better reflect what's being currently done. Or that
> config options (which are user-visible things) should have n+1 as long
> as the underlying feature (or behavior) is not removed.
>
> Please let us know what makes the most sense. In particular between the
> 3 options (but feel free to suggest something else):
>
> 1. n+2 overall
> 2. n+2 for features and capabilities, n+1 for config options
> 3. n+1 overall
>

ironic does n+1 for config options and features. It is possible that ironic
did n+2 as well but if so, I don't recall.

Thanks for asking!

--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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

As of Mon, Aug 31 (diff with Aug 24)
- Open: 144 (+3). 9 new (+4), 50 in progress, 0 critical, 13 high and 10
(+1) incomplete
- Nova bugs with Ironic tag: 24 (-1). 1 new, 0 critical, 1 (+1) high


Oslo (lintan)
==
Oslo plan to dismiss oslo-incubator as most code are already moved to
libraries. So in the future, other projects should maintain the code under
openstack/common by themself. It is also suggested to rename the folder to
avoid misundertand.


Testing (adam_g/jlvillal)
==
Sent out email asking for interested parties for functional testing. Did
receive one response.  But believe there are at least two other people
interested in functional testing. Also JayF pointed to the 'mimic' project,
which looks useful.


Inspector (dtansur)
===
- our dsvm is now voting on ironic-inspector. next step is to make it
voting on a client
- need reviews for IPA patch: https://review.openstack.org/#/c/205587/


Bifrost (TheJulia)
=
- Gate is currently broken due to conflicting change in ironic.  Fix has
been approved ans should be landing shortly
- Our non-voting job should be passing soon once the issues with the
ironic-agent dib element get sorted out and landed.
- Cleanup under-way to cut an initial release.


webclient (krotscheck / betherly)
=
-
https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient,n,z
- https://review.openstack.org/#/c/199769


Drivers
==

iRMC (naohirot)
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z

Status: Active (solicit core team's spec review)
- Enhance Power Interface for Soft Reboot and NMI
  - bp/enhance-power-interface-for-soft-reboot-and-nmi

Status: Reactive (code review is on going)
- iRMC out of band inspection
  - bp/ironic-node-properties-discovery

Status: TODO
- New boot driver interface for iRMC drivers


Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] final release in Liberty cycle

[Ruby Loo]

Hi,

As (most of) you are aware, in this cycle, ironic decided to switch to a
feature-based release model[0].

Our first semver release, 4.0.0, was tagged this week but a few more things
need to be ironed out still (hopefully there will be an announcement about
that in the near future).

What I wanted to mention is that according to the new process, there will
be a final release of ironic that coincides with the Liberty coordinated
release. The current plan is to cut a 4.1.0 release around Liberty RC1,
which will become our stable/liberty branch. According to the schedule[1],
that would most likely happen the week of September 21 or thereabouts.
We'll have a better idea as we get closer to the date.

It isn't clear to me how ironic is affected by the DepFreeze[2] and the
global requirements. Maybe someone who understands that part, could
explain. (And perhaps how the new ironic-lib fits into this freeze, or not.)

--ruby

[0]
http://specs.openstack.org/openstack/ironic-specs/specs/liberty-implemented/feature-based-releases.html
[1] https://wiki.openstack.org/wiki/Liberty_Release_Schedule
[2] https://wiki.openstack.org/wiki/DepFreeze
__
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

[Ruby Loo]

On 20 August 2015 at 23:19, Ruby Loo rlooya...@gmail.com wrote:


 On 18 August 2015 at 17:13, Ruby Loo rlooya...@gmail.com wrote:



 On 18 August 2015 at 13:08, Lucas Alvares Gomes lucasago...@gmail.com
 wrote:

 HI

  Hi, I'd like to make sure I understand. Is it the case that ideally,
 if we

  could go back in time, we'd like to change the client so it defaults to
 1.1?

 AFAIUI, yes

  But since we can't, the next client that we ship/release will have the
 most
  reasonable oldest version? If so, then since the most recent client
 shipped
  is at 1.6, then I think we should put it back to 1.6 even though it is
 1.9
  on master. Regardless of whether there are no backwards incompatible
 changes
  between 1.6  1.9 -- because we need to stick to some
 way-of-doing-things,
  and if we use 1.9, I suspect it will be confusing. At least 1.6 was
 what we
  had at the end of kilo.
 

 The reason why I think we should release with 1.9 is because:

 1) It's already on master and people may be using it already

 2) It's compatible with the previous version that has been released
 already (1.6).

 So it won't break neither users that just get it from pip nor users
 that clone the git repository.


 The order of my preference is 1.1 (which is unrealistic as I mention
 below), 1.6 (because that's what the client had in kilo release and is the
 'closest' version to the server's 1.1), then 1.9 for the reasons you
 mentioned above, then 1.10 just cuz it is the last version that is
 backwards compatible :-)

 Devananda has a patch[0] that changes the client to 1.6, but the
 reviewers' comments there point to the mailing list (here) wrt deciding
 what it should be so what do other folks think?



 In case we don't resolve this via email, I added this topic (which default
 version should the client use) to our next meeting's agenda.

 cheers,
 --ruby



In today's ironic meeting[0], we voted to set the default version to 1.9,
in the client.

--ruby

[0]
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-08-24-17.00.html
__
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] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

As of Mon, Aug 24 (diff with Aug 10)
- Open: 141 (-1). 5 new (-1), 50 in progress, 0 critical, 13 high (+1) and
9 incomplete
- Nova bugs with Ironic tag: 25. 1 new, 0 critical, 0 high


Neutron/Ironic work (jroll)
===
(sukhdev gave update this week while jroll is on vacation)

- We are in the middle of integration testing and have discovered some
issues, which we are addressing
- One of the blocker is the authentication issue when ironic driver makes
create_port() request to neutron - the context is not set correctly, hence
it is rejected
- It's an Ironic admin context, not Nova User context
- lazy_prince is investigating
- https://etherpad.openstack.org/p/ironic-neutron-mid-cycle


ironic-lib adoption (dtantsur)
==
- devstack patch needs review: https://review.openstack.org/#/c/212491/
- project-config patch needs review:
https://review.openstack.org/#/c/212495/


Nova Liaisons (jlvillal  mrda)
===
- https://wiki.openstack.org/wiki/Nova-Ironic-Bugs
- Nova bug scrub each Tuesday


Doc (pshige)
==
- Change and edit of Ironic Installation Guide merged.
- https://review.openstack.org/#/c/191900/
- Next we’ll decide with docs team, what to do in this cycle.


Testing (adam_g/jlvillal)
==
 https://review.openstack.org/#/c/166386/ has not landed yet, and it makes
kittens sad


Inspector (dtansur)
===
- Proposed making dsvm job voting on ironic-inspector itself:
https://review.openstack.org/#/c/209050/


Bifrost (TheJulia)
=
- Enroll support via shade is still in review
- Review proposed to rename bifrost's main gate job and add a second
non-voting job.
- The main gate job should be suitable to be added to help gate Ironic.


webclient (krotscheck / betherly)
=
- CORS is still broken because pxe tests :
https://review.openstack.org/#/c/199769/


Drivers
==

DRAC (ifarkas/lucas)

- fixing jenkins jobs - openwsman library is required to install pywsman
from pypi with matching versions for both

iLO (wanyen)
--
- Standalone ilo driver changes in progress.  Spec merged:
https://review.openstack.org/193478. One code patch merged. One under
review:https://review.openstack.org/198656

iRMC (naohirot)
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z

Status: Active (solicit core team's response to the solution proposals of
two major  issues described in the spec and the POC code review)
- Enhance Power Interface for Soft Reboot and NMI
- bp/enhance-power-interface-for-soft-power-off-and-inject-nmi

Status: Reactive (code review is on going)
- iRMC out of band inspection
- bp/ironic-node-properties-discovery

Status: TODO
- iRMC Virtual Media Deploy Driver
- follow up patch to fix nits

https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z

Status: Active (solicit core team's spec review)
- Enhance Power Interface for Soft Reboot and NMI
- bp/enhance-power-interface-for-soft-reboot-and-nmi

Status: Reactive (code review is on going)
- iRMC out of band inspection
- bp/ironic-node-properties-discovery

Status: TODO
- iRMC Virtual Media Deploy Driver
- follow up patch to fix nits

OneView (gabriel-bezerra/thiagop)
--
- Spec merged!
- Code under review: https://review.openstack.org/#/c/191822/
- We're starting to set up the 3rd party CI on experimental pipeline



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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

[Ruby Loo]

On 18 August 2015 at 17:13, Ruby Loo rlooya...@gmail.com wrote:



 On 18 August 2015 at 13:08, Lucas Alvares Gomes lucasago...@gmail.com
 wrote:

 HI

  Hi, I'd like to make sure I understand. Is it the case that ideally,
 if we

  could go back in time, we'd like to change the client so it defaults to
 1.1?

 AFAIUI, yes

  But since we can't, the next client that we ship/release will have the
 most
  reasonable oldest version? If so, then since the most recent client
 shipped
  is at 1.6, then I think we should put it back to 1.6 even though it is
 1.9
  on master. Regardless of whether there are no backwards incompatible
 changes
  between 1.6  1.9 -- because we need to stick to some
 way-of-doing-things,
  and if we use 1.9, I suspect it will be confusing. At least 1.6 was
 what we
  had at the end of kilo.
 

 The reason why I think we should release with 1.9 is because:

 1) It's already on master and people may be using it already

 2) It's compatible with the previous version that has been released
 already (1.6).

 So it won't break neither users that just get it from pip nor users
 that clone the git repository.


 The order of my preference is 1.1 (which is unrealistic as I mention
 below), 1.6 (because that's what the client had in kilo release and is the
 'closest' version to the server's 1.1), then 1.9 for the reasons you
 mentioned above, then 1.10 just cuz it is the last version that is
 backwards compatible :-)

 Devananda has a patch[0] that changes the client to 1.6, but the
 reviewers' comments there point to the mailing list (here) wrt deciding
 what it should be so what do other folks think?



In case we don't resolve this via email, I added this topic (which default
version should the client use) to our next meeting's agenda.

cheers,
--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

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

[Ruby Loo]

Hi,

I want to start a different thread on this topic because I don't think this
is about whether/how to do API microversions. Rather, given that we are
going to support microversioning, how to deal with the non-backward
compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
being the provision state that a node is in, after being created/registered
in ironic.

(This was from 'Let's talk about API versions,
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html.)

I want to think about this before replying but others are more than welcome
to reply first so that I may not feel the need to reply :-)

--ruby
maybe chop off this and above when replying :-)

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

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 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] Re: New API for node create, specifying initial provision state

[Ruby Loo]

Apologies, forgot to add [ironic] to the subject.

On 18 August 2015 at 13:27, Ruby Loo rlooya...@gmail.com wrote:

 Hi,

 I want to start a different thread on this topic because I don't think
 this is about whether/how to do API microversions. Rather, given that we
 are going to support microversioning, how to deal with the non-backward
 compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
 being the provision state that a node is in, after being created/registered
 in ironic.

 (This was from 'Let's talk about API versions,
 http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html
 .)

 I want to think about this before replying but others are more than
 welcome to reply first so that I may not feel the need to reply :-)

 --ruby
 maybe chop off this and above when replying :-)

 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

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 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

[Ruby Loo]

 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 goes from enroll - verifying -
manageable. For manageble to be initial state, does it mean that
A. whatever is needed for enroll and verifying is done and succeeds (under
the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying)
or
C. no enroll or verifying is done, it goes straight to manageble

I'm fine with A.I'm not sure that B makes sense and I definitely don't
think C makes sense. To date, verifying means checking that the conductor
can get the power state on the node, to verify the supplied power
credentials. I don't think it is a big deal if we skip this step; it just
means that the next time some action is taken on the node, it might fail.

available

In our state machinery, a node goes from enroll - verifying - manageable
- cleaning - available. For available to be initial state, does it mean
that
A. whatever is needed for enroll, verifying, cleaning is done and succeeds
(under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying or
cleaning)
or
??

active

In our state machinery, a node goes from enroll - verifying - manageable
- cleaning - available-deploying-active. For active to be initial
state, does it mean that
A. whatever is needed for enroll, verifying, cleaning, deploying is done
and succeeds (under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying or
cleaning)
or
C. whatever is needed for enroll and I dunno, any 'takeover' stuff by
conductor or whatever node states need to be updated to be in active?

--ruby

[0] http://docs.openstack.org/developer/ironic/dev/states.html
__
OpenStack Development Mailing List (not for usage