Re: [openstack-dev] [all] Switching to longer development cycles

[Chris K]

This is a much needed change. It will ease the effort required by operators
to maintain a current openstack environment.

+1 from me

Chris Krelle



On Dec 13, 2017 8:17 AM, "Thierry Carrez"  wrote:

Hi everyone,

Over the past year, it has become pretty obvious to me that our
self-imposed rhythm no longer matches our natural pace. It feels like we
are always running elections, feature freeze is always just around the
corner, we lose too much time to events, and generally the impression
that there is less time to get things done. Milestones in the
development cycles are mostly useless now as they fly past us too fast.
A lot of other people reported that same feeling.

As our various components mature, we have less quick-paced feature
development going on. As more and more people adopt OpenStack, we are
more careful about not breaking them, which takes additional time. The
end result is that getting anything done in OpenStack takes more time
than it used to, but we have kept our cycle rhythm mostly the same.

Our development pace was also designed for fast development in a time
where most contributors were full time on OpenStack. But fewer and fewer
people have 100% of their time to dedicate to OpenStack upstream
development: a lot of us now have composite jobs or have to participate
in multiple communities. This is a good thing, and it will only
accelerate as more and more OpenStack development becomes fueled
directly by OpenStack operators and users.

In another thread, John Dickinson suggested that we move to one-year
development cycles, and I've been thinking a lot about it. I now think
it is actually the right way to reconcile our self-imposed rhythm with
the current pace of development, and I would like us to consider
switching to year-long development cycles for coordinated releases as
soon as possible.

What it means:

- We'd only do one *coordinated* release of the OpenStack components per
year, and maintain one stable branch per year
- We'd elect PTLs for one year instead of every 6 months
- We'd only have one set of community goals per year
- We'd have only one PTG with all teams each year

What it does _not_ mean:

- It doesn't mean we'd release components less early or less often. Any
project that is in feature development or wants to ship changes more
often is encouraged to use the cycle-with-intermediary release model and
release very early and very often. It just means that the minimum we'd
impose for mature components is one release per year instead of one
release every 6 months.

- It doesn't mean that we encourage slowing down and procrastination.
Each project would be able to set its own pace. We'd actually encourage
teams to set objectives for the various (now longer) milestones in the
cycle, and organize virtual sprints to get specific objectives done as a
group. Slowing down the time will likely let us do a better job at
organizing the work that is happening within a cycle.

- It doesn't mean that teams can only meet in-person once a year.
Summits would still provide a venue for team members to have an
in-person meeting. I also expect a revival of the team-organized
midcycles to replace the second PTG for teams that need or want to meet
more often.

- It doesn't mean less emphasis on common goals. While we'd set goals
only once per year, I hope that having one full year to complete those
will let us tackle more ambitious goals, or more of them in parallel.

- It doesn't simplify upgrades. The main issue with the pace of
upgrading is not the rhythm, it's the imposed timing. Being forced to
upgrade every year is only incrementally better than being forced to
upgrade every 6 months. The real solution there is better support for
skipping releases that don't matter to you, not longer development cycles.

- It doesn't give us LTS. The cost of maintaining branches is not really
due to the number of them we need to maintain in parallel, it is due to
the age of the oldest one. We might end up being able to support
branches for slightly longer as a result of having to maintain less of
them in parallel, but we will not support our stable branches for a
significantly longer time as a direct result of this change. The real
solution here is being discussed by the (still forming) LTS SIG and
involves having a group step up to continue to maintain some branches
past EOL.

Why one year ?

Why not switch to 9 months ? Beyond making the math a lot easier, this
has mostly to do with events organization. The Summits are already
locked for 2018/2019 with a pattern of happening in April/May and
October/November. As we want to keep the PTG event as a separate
work-focused productive event at the start of every cycle, and not have
it collide with one of those already-planned summits, going for a yearly
rhythm is the best solution.

When ?

If we switch, we could either pick February/March or August/September as
the start of cycle / yearly PTG time. From an events organization
perspective, it is a lot easier 

Re: [openstack-dev] [ironic] Proposing two new cores

[Chris K]

Big +2 for both here.

-Chris

On Thu, Jun 16, 2016 at 8:12 AM, Jim Rollenhagen 
wrote:

> Hi all,
>
> I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the
> ironic-core team.
>
> Jay has been in the community as long as I have, has been IPA and
> ironic-specs core for quite some time. His background is operations, and
> he's getting good with Python. He's given great reviews for quite a
> while now, and the number is steadily increasing. I think it's a
> no-brainer.
>
> Sam has been in the ironic community for quite some time as well, with
> close ties to the neutron community as well. His background seems to be
> in networking, he's got great python skills as well. His reviews are
> super useful. He doesn't have quite as many as some people, but they are
> always thoughtful, and he often catches things others don't. I do hope
> to see more of his reviews.
>
> Both Sam and Jay are to the point where I consider their +1 or -1 as
> highly as any other core, so I think it's past time to allow them to +2
> as well.
>
> Current cores, please reply with your vote.
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

[Chris K]

Big +1 from /me. Juila will be a great addition to the team.

-Chris

On Thu, Mar 24, 2016 at 12:08 PM, 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
>
> __
> 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] iPXE / UEFI support for stable liberty

[Chris K]

Thank you for the replies,
I have abandon the patches, upon re-review and testing of the case I
thought was working I agree that these patches are beyond the scope of what
a backport should be.

Chris

On Tue, Feb 23, 2016 at 6:22 AM, Heck, Joseph  wrote:

> Morning,
>
> Just a quick note, there is UEFI booting support within iPXE.  You have to
> invoke a specific build of the binary to get the output, but it's there:
>  make bin-x86_64-efi/snponly.efi
>
> Not entirely relevant to the core of the thread, but wanted to share that
> detail if it's been otherwise missed.
>
> - joe
> _
> From: Jim Rollenhagen 
> Sent: Monday, February 22, 2016 7:37 PM
> Subject: Re: [openstack-dev] [ironic] [stable] iPXE / UEFI support for
> stable liberty
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
>
>
>
> On Feb 22, 2016, at 15:15, Chris K < nobody...@gmail.com> wrote:
>
> Hi Ironicers,
>
> I wanted to draw attention to iPXE / UEFI support in our stable liberty
> branch.
>
>
> Which doesn't exist, right? Or does it work depending on some other
> factors?
>
> There are environments that require support for UEFI, while ironic does
> have this support in master, it is not capable of this in many
> configurations when using the stable liberty release and the docs around
> this feature were unclear.
>
>
> What's unclear about the docs? Can you point at a specific thing, or is it
> just the lack of a thing that specifically says UEFI+iPXE is not supported?
>
> Because support for this feature was unclear when the liberty branch was
> cut it has caused some confustion to users wishing or needing to consume
> the stable branch. I have purposed patches
> https://review.openstack.org/#/c/281564 and
> https://review.openstack.org/#/c/281536 with the goal of correcting this,
> given that master may not be acceptable for some businesses to consume. I
> welcome feedback on this.
>
>
> I believe the first patch adds the feature, and the second patch fixes a
> bug with the feature. Correct?
>
> As you know, stable policy is to not backport features. I don't see any
> reason this case should bypass this policy (which is why I asked so many
> questions above, it's odd to me that this is an open question at all).
>
> It seems like a better path would be to fix the docs to avoid the
> confusion in the first place, right? I'm not sure what the "backport" would
> look like, given that docs patch wouldn't make sense on master, but surely
> some more experienced stable maintainers could guide us. :)
>
> // 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 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] [stable] iPXE / UEFI support for stable liberty

[Chris K]

Hi Ironicers,

I wanted to draw attention to iPXE / UEFI support in our stable liberty
branch. There are environments that require support for UEFI, while ironic
does have this support in master, it is not capable of this in many
configurations when using the stable liberty release and the docs around
this feature were unclear.  Because support for this feature was unclear
when the liberty branch was cut it has caused some confustion to users
wishing or needing to consume the stable branch. I have purposed patches
https://review.openstack.org/#/c/281564 and
https://review.openstack.org/#/c/281536 with the goal of correcting this,
given that master may not be acceptable for some businesses to consume. I
welcome feedback on this.
__
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

[Chris K]

+1 for both so +2 :)

-Chris

On Fri, Oct 9, 2015 at 4:26 PM, Jay Faulkner  wrote:

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

[Chris K]

Nice to see the team expand. Thank you Sam for all your work. Well
deserved. :)

-Chris
NobodyCam

On Tue, Aug 25, 2015 at 11:35 AM, Sam Betts (sambetts) 
wrote:

> Thanks everyone, proud to be on the team!
>
> Sam
>
> On 25/08/2015 12:32, "Lucas Alvares Gomes"  wrote:
>
> >Congrats! Well deserved
> >
> >On Tue, Aug 25, 2015 at 12:24 PM, Yuiko Takada
> > wrote:
> >> Sam, congrats and welcome!
> >>
> >>
> >> Yuiko Takada
> >>
> >> 2015/08/25 19:53、Dmitry Tantsur  のメッセージ:
> >>
> >>> Hi all!
> >>>
> >>> Please join me in welcoming Sam to our team! He has been doing very
> >>>smart reviews recently, was contributing core features and expressed
> >>>clear interest in the ironic-inspector project.
> >>>
> >>> Thanks and welcome!
> >>>
> >>>
> >>>
> >>>__
> >>> 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 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] [wsme] [ironic] [ceilometer] [magnum] [kite] [tuskar] WSME unmaintained ?

[Chris K]

Hello,

No need to do that, I'm OK to add any competent people to wsme-core. :)
>
While I don't have a great deal of experience with the WSME code base
(other then being a user of it), As Ironic is currently using WSME I would
offer to help. As a core on Ironic I would continue to expect that to take
the bulk of my time, but even so I feel I would be able to contribute time
for reviews and other project maintenance. Please let me know if I can be
of any help with this.

Chris Krelle
-- NobodyCam in IRC
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] checking on odds that spec will be approved for K

[Chris K]

Hello Ceilometer,

I would like to check on the chances that spec
https://review.openstack.org/#/c/130359 will land in the K cycle. We in
Ironic have specs that are dependent on the above spec and are checking to
see if we need to bump them to L? Any information regarding this would be
helpful.

Thank you in advance
Chris Krelle
-NobodyCam
__
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] thoughts on the midcycle

[Chris K]

A SF meet up would be much easier for me to attend. I could make the
purposed dates of the 11th through the 13th. Do we know where this event
would be held yet?


-Chris

On Mon, Dec 29, 2014 at 2:45 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

> I'm sending the details of the midcycle in a separate email. Before you
> reply that you won't be able to make it, I'd like to share some thoughts /
> concerns.
>
> In the last few weeks, several people who I previously thought would
> attend told me that they can't. By my informal count, it looks like we will
> have at most 5 of our 10 core reviewers in attendance. I don't think we
> should cancel based on that, but it does mean that we need to set our
> expectations accordingly.
>
> Assuming that we will be lacking about half the core team, I think it will
> be more practical as a focused sprint, rather than a planning & design
> meeting. While that's a break from precedent, planning should be happening
> via the spec review process *anyway*. Also, we already have a larger back
> log of specs and work than we had this time last cycle, but with the same
> size review team. Rather than adding to our backlog, I would like us to use
> this gathering to burn through some specs and land some code.
>
> That being said, I'd also like to put forth this idea: if we had a second
> gathering (with the same focus on writing code) the following week (let's
> say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able
> to get the "other half" of the core team together and get more work done?
> Is this a good idea?
>
> OK. That's enough of my musing for now...
>
> Once again, if you will be attending the midcycle sprint in Grenoble the
> week of Feb 3rd, please sign up HERE
> 
> .
>
> Regards,
> Devananda
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Cleaning up spec review queue.

[Chris K]

Thank you all for the reply's to this thread. I have now set all of the
listed spec's to an abandoned state, Please note that any review can be
recovered quickly but clicking the "Restore Change" button. If one of the
listed spec's is restored please be sure to re-target to the Kilo cycle.

Thank you,
Chris Krelle
Nobodycam

On Wed, Nov 19, 2014 at 3:19 AM, Imre Farkas  wrote:

> On 11/19/2014 12:07 PM, Dmitry Tantsur wrote:
>
>> On 11/18/2014 06:13 PM, Chris K wrote:
>>
>>> Hi all,
>>>
>>> In an effort to keep the Ironic specs review queue as up to date as
>>> possible, I have identified several specs that were proposed in the Juno
>>> cycle and have not been updated to reflect the changes to the current
>>> Kilo cycle.
>>>
>>> I would like to set a deadline to either update them to reflect the Kilo
>>> cycle or abandon them if they are no longer relevant.
>>> If there are no objections I will abandon any specs on the list below
>>> that have not been updated to reflect the Kilo cycle after the end of
>>> the next Ironic meeting (Nov. 24th 2014).
>>>
>>> Below is the list of specs I have identified that would be affected:
>>> https://review.openstack.org/#/c/107344 - *Generic Hardware Discovery
>>> Bits*
>>>
>> Killed it with fire :D
>>
>>  https://review.openstack.org/#/c/102557 - *Driver for NetApp storage
>>> arrays*
>>> https://review.openstack.org/#/c/108324 - *DRAC hardware discovery*
>>>
>> Imre, are you going to work on it?
>>
>
> I think it's replaced by Lucas' proposal: https://review.openstack.org/#
> /c/125920
> I will discuss it with him and abandon one of them.
>
> Imre
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle

[Chris K]

Thank you for this Ruby,

I agree with what Lucas stated in his reply, Though I thought I would toss
my two cents in to the pool as well.

I also feel that we should (and have been) strive (ing) to maintain
compatibility. Though I feel this is more important on a release to release
basis, more so then on an inter cycle basis. I feel this way because with
in a cycle a new feature may be introduced that has an unforeseen impact on
the current code that needs to be addressed with in that cycle. As a
Operator I would refer to this a "leading edge" vs "bleeding edge". This is
also one of the reasons we cut stable releases, so that folks who what to
have stability in the code they run in production are not having to deal
the day to day upkeep of what landed trunk (master branch) last night that
broke my production environment. Trunk is almost by default not a stable
playground, If we add a new shinny and then find out that it has an
unforeseen impact, changing the way the new feature is implemented is not
such a bad thing, as long as it is still with in the cycle it was
introduced and an official release has not been cut, I am excluding RC
releases as they are Release "Candidates" and finding such impacts is there
"job".

As this is only my option, actual cash value is less then .02 cents.


Chris Krelle
NobodyCam

On Thu, Nov 20, 2014 at 8:28 AM, Lucas Alvares Gomes 
wrote:

> Hi Ruby,
>
> Thank you for putting this up.
>
> I'm one of the ones think we should try hard (even really hard) to
> maintain the compatibility on every commit. I understand that it may
> sound naive because I'm sure that sometimes we will break things, but
> that doesn't means we shouldn't try.
>
> There may be people running Ironic in a continuous deployment
> environment, those are the users of the project and therefor the most
> important part of Ironic. Doesn't matter how well written Ironic code
> may be if nobody is using it. If we break that user workflow and he's
> unhappy that's the ultimate failure.
>
> I also understand that in the project POV we want to have fast
> interactions and shiny new features as quick as possible and trying to
> be backward compatibility all the time - on every commit - might slow
> that down. But in the user POV I believe that he doesn't care much
> about all the new features, he would mostly care about the things that
> used to work to continue to work for him.
>
> Also the backwards approach between releases and not commits might
> work fine in the non-opensource world where the code is kept indoors
> until the software is release, but in the opensource world where the
> code is out to people to use it all the time it doesn't seem to work
> that well.
>
> That's my 2 cents.
>
> Lucas
>
> On Thu, Nov 20, 2014 at 3:38 PM, Ruby Loo  wrote:
> > Hi, we had an interesting discussion on IRC about whether or not we
> should
> > be maintaining backwards compatibility within a release cycle. In this
> > particular case, we introduced a new decorator in this kilo cycle, and
> were
> > discussing the renaming of it, and whether it needed to be backwards
> > compatible to not break any out-of-tree driver using master.
> >
> > Some of us (ok, me or I) think it doesn't make sense to make sure that
> > everything we do is backwards compatible. Others disagree and think we
> > should, or at least strive for 'must be' backwards compatible with the
> > caveat that there will be cases where this isn't
> feasible/possible/whatever.
> > (I hope I captured that correctly.)
> >
> > Although I can see the merit (well, sort of) of trying our best, trying
> > doesn't mean 'must', and if it is 'must', who decides what can be
> exempted
> > from this, and how will we communicate what is exempted, etc?
> >
> > Thoughts?
> >
> > --ruby
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] Cleaning up spec review queue.

[Chris K]

Hi all,

In an effort to keep the Ironic specs review queue as up to date as
possible, I have identified several specs that were proposed in the Juno
cycle and have not been updated to reflect the changes to the current Kilo
cycle.

I would like to set a deadline to either update them to reflect the Kilo
cycle or abandon them if they are no longer relevant.
If there are no objections I will abandon any specs on the list below that
have not been updated to reflect the Kilo cycle after the end of the next
Ironic meeting (Nov. 24th 2014).

Below is the list of specs I have identified that would be affected:
https://review.openstack.org/#/c/107344 - *Generic Hardware Discovery Bits*
https://review.openstack.org/#/c/102557 - *Driver for NetApp storage arrays*
https://review.openstack.org/#/c/108324 - *DRAC hardware discovery*
https://review.openstack.org/#/c/103065 - *Design spec for iLO driver for
firmware settings*
https://review.openstack.org/#/c/108646 - *Add HTTP GET support for
vendor_passthru API*
https://review.openstack.org/#/c/94923 - *Make the REST API fully
asynchronous*
https://review.openstack.org/#/c/103760 - *iLO Management Driver for
firmware update*
https://review.openstack.org/#/c/110217 - *Cisco UCS Driver*
https://review.openstack.org/#/c/96538 - *Add console log support*
https://review.openstack.org/#/c/100729 - *Add metric reporting spec.*
https://review.openstack.org/#/c/101122 - *Firmware setting design spec.*
https://review.openstack.org/#/c/96545 - *Reset service processor*

*This list may also be found on this ether pad:
https://etherpad.openstack.org/p/ironic-juno-specs-to-be-removed
*

If you believe one of the above specs should not be abandoned please update
the spec to reflect the current Kilo cycle, or let us know that a update is
forth coming.

Please feel free to reply to this email, I will also bring this topic up at
the next meeting to ensure we have as much visibility as possible before
abandoning the old specs.

Thank you,
Chris Krelle
IRC: NobodyCam
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Proposing new meeting times

[Chris K]

I would vote +1 for option #2, While I may not make many of the 0500
meetings, I could. So I see this as the best option.

Chris

On Tue, Nov 18, 2014 at 2:11 AM, Zhongyue Luo 
wrote:

> +1 for Option #2
>
> On Tue, Nov 18, 2014 at 5:56 PM, Lucas Alvares Gomes <
> lucasago...@gmail.com> wrote:
>
>> On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen
>>  wrote:
>> > Hi all,
>> >
>> > As discussed in Paris and at today's IRC meeting [1] we are going to be
>> > alternating the time of the weekly IRC meetings to accommodate our
>> > contributors in EMEA better. No time will be perfect for everyone, but
>> as it
>> > stands, we rarely (if ever) see our Indian, Chinese, and Japanese
>> > contributors -- and it's quite hard for any of the AU / NZ folks to
>> attend.
>> >
>> > I'm proposing two sets of times below. Please respond with a "-1" vote
>> to an
>> > option if that option would cause you to miss ALL meetings, or a "+1"
>> vote
>> > if you can magically attend ALL the meetings. If you can attend, without
>> > significant disruption, at least one of the time slots in a proposal,
>> please
>> > do not vote either for or against it. This way we can identify a
>> proposal
>> > which allows everyone to attend at a minimum 50% of the meetings, and
>> > preferentially weight towards one that allows more contributors to
>> attend
>> > two meetings.
>> >
>> > This link shows the local times in some major coutries / timezones
>> around
>> > the world (and you can customize it to add your own).
>> >
>> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125&p1=224&p2=179&p3=78&p4=367&p5=44&p6=33&p7=248&p8=5
>> >
>> > For reference, the current meeting time is 1900 UTC.
>> >
>> > Option #1: alternate between Monday 1900 UTC && Tuesday 0900 UTC.  I
>> like
>> > this because 1900 UTC spans all of US and western EU, while 0900
>> combines EU
>> > and EMEA. Folks in western EU are "in the middle" and can attend all
>> > meetings.
>> >
>> >
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=24&hour=19&min=0&sec=0&p1=224&p2=179&p3=78&p4=367&p5=44&p6=33&p7=248&p8=5
>> >
>> >
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=25&hour=9&min=0&sec=0&p1=224&p2=179&p3=78&p4=367&p5=44&p6=33&p7=248&p8=5
>>
>> +1
>>
>> >
>> >
>> > Option #2: alternate between Monday 1700 UTC && Tuesday 0500 UTC. I like
>> > this because it shifts the current slot two hours earlier, making it
>> easier
>> > for eastern EU to attend without excluding the western US, and while
>> 0500
>> > UTC is not so late that US west coast contributors can't attend (it's
>> 9PM
>> > for us), it is harder for western EU folks to attend. There's really no
>> one
>> > in the middle here, but there is at least a chance for US west coast and
>> > EMEA to overlap, which we don't have at any other time.
>> >
>> >
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=24&hour=17&min=0&sec=0&p1=224&p2=179&p3=78&p4=367&p5=44&p6=33&p7=248&p8=5
>> >
>> >
>> > I'll collate all the responses to this thread during the week, ahead of
>> next
>> > week's regularly-scheduled meeting.
>> >
>> > -Devananda
>> >
>> > [1]
>> >
>> http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> *Intel SSG/STO/BDT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
> China
> +862161166500
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] A mascot for Ironic

[Chris K]

How cute.

maybe we could call him bear-thoven.

Chris


On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes 
wrote:

> Hi Ironickers,
>
> I was thinking this weekend: All the cool projects does have a mascot
> so I thought that we could have one for Ironic too.
>
> The idea about what the mascot would be was easy because the RAX guys
> put "bear metal" their presentation[1] and that totally rocks! So I
> drew a bear. It also needed an instrument, at first I thought about a
> guitar, but drums is actually my favorite instrument so I drew a pair
> of drumsticks instead.
>
> The drawing thing wasn't that hard, the problem was to digitalize it.
> So I scanned the thing and went to youtube to watch some tutorials
> about gimp and inkspace to learn how to vectorize it. Magic, it
> worked!
>
> Attached in the email there's the original draw, the vectorized
> version without colors and the final version of it (with colors).
>
> Of course, I know some people does have better skills than I do, so I
> also attached the inkspace file of the final version in case people
> want to tweak it :)
>
> So, what you guys think about making this little drummer bear the
> mascot of the Ironic project?
>
> Ahh he also needs a name. So please send some suggestions and we can
> vote on the best name for him.
>
> [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
>
> Lucas
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Changing our weekly meeting format

[Chris K]

+1
I think the best use of our time is to discuss new features and functions
that may have a api or functional impact for ironic or projects that depend
on ironic.

Chris Krelle

On Thu, Nov 13, 2014 at 8:22 AM, Ghe Rivero  wrote:

> I agree that a lot of time is missed with the announcement and status
> reports, but mostly because irc is a slow bandwidth communication channel
> (like waiting several minutes for a 3 lines announcement to be written)
>
> I propose that any announcement and project status must be written in
> advanced to an etherpad, and during the irc meeting just have a slot for
> people to discuss anything that need further explanation, only mentioning
> the topic but not  the content.
>
> Ghe Rivero
> On Nov 13, 2014 5:08 PM, "Peeyush Gupta" 
> wrote:
>
>> +1
>>
>> I agree with Lucas. Sounds like a good idea. I guess if we could spare
>> more time for discussing new features and requirements rather than
>> asking for status, that would be helpful for everyone.
>>
>> On 11/13/2014 05:45 PM, Lucas Alvares Gomes wrote:
>> > This was discussed in the Contributor Meetup on Friday at the Summit
>> > but I think it's important to share on the mail list too so we can get
>> > more opnions/suggestions/comments about it.
>> >
>> > In the Ironic weekly meeting we dedicate a good time of the meeting to
>> > do some announcements, reporting bug status, CI status, oslo status,
>> > specific drivers status, etc... It's all good information, but I
>> > believe that the mail list would be a better place to report it and
>> > then we can free some time from our meeting to actually discuss
>> > things.
>> >
>> > Are you guys in favor of it?
>> >
>> > If so I'd like to propose a new format based on the discussions we had
>> > in Paris. For the people doing the status report on the meeting, they
>> > would start adding the status to an etherpad and then we would have a
>> > responsible person to get this information and send it to the mail
>> > list once a week.
>> >
>> > For the meeting itself we have a wiki page with an agenda[1] which
>> > everyone can edit to put the topic they want to discuss in the meeting
>> > there, I think that's fine and works. The only change about it would
>> > be that we may want freeze the agenda 2 days before the meeting so
>> > people can take a look at the topics that will be discussed and
>> > prepare for it; With that we can move forward quicker with the
>> > discussions because people will be familiar with the topics already.
>> >
>> > Let me know what you guys think.
>> >
>> > [1] https://wiki.openstack.org/wiki/Meetings/Ironic
>> >
>> > Lucas
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> --
>> Peeyush Gupta
>> gpeey...@linux.vnet.ibm.com
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Taking a break..

[Chris K]

Chris,

All the best to you on you new adventure.

Chris Krelle
NobodyCam

On Wed, Oct 22, 2014 at 10:37 AM, Chris Behrens 
wrote:

> Hey all,
>
> Just wanted to drop a quick note to say that I decided to leave Rackspace
> to pursue another opportunity. My last day was last Friday. I won’t have
> much time for OpenStack, but I’m going to continue to hang out in the
> channels. Having been involved in the project since day 1, I’m going to
> find it difficult to fully walk away. I really don’t know how much I’ll
> continue to stay involved. I am completely burned out on nova. However, I’d
> really like to see versioned objects broken out into oslo and Ironic synced
> with nova’s object advancements. So, if I work on anything, it’ll probably
> be related to that.
>
> Cells will be left in a lot of capable hands. I have shared some thoughts
> with people on how I think we can proceed to make it ‘the way’ in nova. I’m
> going to work on documenting some of this in an etherpad so the thoughts
> aren’t lost.
>
> Anyway, it’s been fun… the project has grown like crazy! Keep on
> trucking... And while I won’t be active much, don’t be afraid to ping me!
>
> - Chris
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] On an API proxy from baremetal to ironic

[Chris K]

I thought it might be helpful to show a sample of the output from the
proxied commands: Please find the example here:

http://paste.openstack.org/show/Em861wMwFvrFlsWkugfX



Chris Krelle
NobodyCam


On Wed, Sep 10, 2014 at 7:33 AM, Sean Dague  wrote:

> On 09/09/2014 11:22 PM, Russell Bryant wrote:
> > On 09/09/2014 05:24 PM, Michael Still wrote:
> >> Hi.
> >>
> >> One of the last things blocking Ironic from graduating is deciding
> >> whether or not we need a Nova API proxy for the old baremetal
> >> extension to new fangled Ironic API. The TC has asked that we discuss
> >> whether we think this functionality is actually necessary.
> >>
> >> It should be noted that we're _not_ talking about migration of
> >> deployed instances from baremetal to Ironic. That is already
> >> implemented. What we are talking about is if users post-migration
> >> should be able to expect their previous baremetal Nova API extension
> >> to continue to function, or if they should use the Ironic APIs from
> >> that point onwards.
> >>
> >> Nova had previously thought this was required, but it hasn't made it
> >> in time for Juno unless we do a FFE, and it has been suggested that
> >> perhaps its not needed at all because it is an admin extension.
> >>
> >> To be super specific, we're talking about the "baremetal nodes" admin
> >> extension here. This extension has the ability to:
> >>
> >>  - list nodes running baremetal
> >>  - show detail of one of those nodes
> >>  - create a new baremetal node
> >>  - delete a baremetal node
> >>
> >> Only the first two of those would be supported if we implemented a
> proxy.
> >>
> >> So, discuss.
> >
> > I'm in favor of proceeding with deprecation without requiring the API
> proxy.
> >
> > In the case of user facing APIs, the administrators in charge of
> > upgrading the cloud do not have full control over all of the apps using
> > the APIs.  In this particular case, I would expect that the cloud
> > administrators have *complete* control over the use of these APIs.
> >
> > Assuming we have one overlap release (Juno) to allow the migration to
> > occur and given proper documentation of the migration plan and release
> > notes stating the fact that the old APIs are going away, we should be
> fine.
> >
> > In summary, +1 to moving forward without the API proxy requirement.
>
> The thing is, we have the patch -
> https://review.openstack.org/#/c/120433/, so it's not like there is a
> zomg run around to get the patch.
>
> I think we should FFE this patch as it provides a smoother transition
> from baremetal to ironic. The patch is extremely low risk to the rest of
> Nova, as it's a surface proxy feature, so lets just land it and move
> forward.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

[Chris K]

I also am in favor of this. +1

Chris Krelle


On Wed, Aug 6, 2014 at 9:04 AM, Jay Faulkner  wrote:

> Similarly, I appreciated this idea when we discussed it at the mid-cycle
> and doing so here.
>
> +1
>
> -Jay Faulkner
>
> 
> From: Lucas Alvares Gomes 
> Sent: Wednesday, August 06, 2014 2:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Ironic] Proposal for slight change in our
> specprocess
>
> Already agreed with the idea at the midcycle, but just making it public: +1
>
> On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko
>  wrote:
> > Hi!
> >
> > I think this is a nice idea indeed. Do you plan to use this process
> starting
> > from Juno or as soon as possible?
>
> It will start in Kilo
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Nominating Jim Rollenhagen to ironic-core

[Chris K]

+1 from me.


On Fri, Jul 11, 2014 at 3:50 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

> Hi all!
>
> It's time to grow the team :)
>
> Jim (jroll) started working with Ironic at the last mid-cycle, when
> "teeth" became ironic-python-agent. In the time since then, he's jumped
> into Ironic to help improve the project as a whole. In the last few months,
> in both reviews and discussions on IRC, I have seen him consistently
> demonstrate a solid grasp of Ironic's architecture and its role within
> OpenStack, contribute meaningfully to design discussions, and help many
> other contributors. I think he will be a great addition to the core review
> team.
>
> Below are his review stats for Ironic, as calculated by the
> openstack-infra/reviewstats project with local modification to remove
> ironic-python-agent, so we can see his activity in the main project.
>
> Cheers,
> Devananda
>
>
> +--+---++
> | Reviewer | Reviews   -2  -1  +1  +2  +A+/- % |
> Disagreements* |
>
> +--+---++
>
> 30
> |  jimrollenhagen  |  290   8  21   0   072.4% |5
> ( 17.2%)  |
>
> 60
> |  jimrollenhagen  |  760  16  60   0   078.9% |   13
> ( 17.1%)  |
>
> 90
> |  jimrollenhagen  | 1060  27  79   0   074.5% |   25
> ( 23.6%)  |
>
> 180
> |  jimrollenhagen  | 1570  41 116   0   073.9% |   35
> ( 22.3%)  |
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Nominating David Shrewsbury to ironic-core

[Chris K]

another +1 from /me.


On Fri, Jul 11, 2014 at 3:50 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

> Hi all!
>
> While David (Shrews) only began working on Ironic in earnest four months
> ago, he has been working on some of the tougher problems with our Tempest
> coverage and the Nova<->Ironic interactions. He's also become quite active
> in reviews and discussions on IRC, and demonstrated a good understanding of
> the challenges facing Ironic today. I believe he'll also make a great
> addition to the core team.
>
> Below are his stats for the last 90 days.
>
> Cheers,
> Devananda
>
>
> +--+---++
> | Reviewer | Reviews   -2  -1  +1  +2  +A+/- % |
> Disagreements* |
>
> +--+---++
>
> 30
> | dshrews  |  470  11  36   0   076.6% |7
> ( 14.9%)  |
>
> 60
> | dshrews  |  910  14  77   0   084.6% |   15
> ( 16.5%)  |
>
> 90
> | dshrews  | 1210  21 100   0   082.6% |   16
> ( 13.2%)  |
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Tripleo, Ironic, the SSH power driver, paramiko and eventlet fun.

[Chris K]

Awesome news!

Chris


On Wed, Jun 25, 2014 at 3:23 AM,  wrote:

> On Tue, 24 Jun 2014, j...@ioctl.org wrote:
>
> > There's a bug on this:
> > https://bugs.launchpad.net/ironic/+bug/1321787?comments=all
>
>
> We've got a potential eventlet fix here:
>
>   https://github.com/jan-g/eventlet/tree/wip
>
> ... testing it now. Certainly seems hopeful in the face of a 'multiple
> threads running paramiko' test.
>
> Cheers,
> jan
>
> --
> "My army boots contain everything not in them." - Russell's pair o' Docs.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Is ironic support EXSI when boot a bare metal ?

[Chris K]

Hi Chao,

The ironic ssh driver does support vmware. See
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ssh.py#L69-L89.
Have you seen the Triple-O tools, mainly Disk Image Builder (
https://github.com/openstack/diskimage-builder). This is how I build images
I use for testing. I have not tested the vmware parts of ironic as I do not
have a vmware server to test with, others have tested it.

Hope this helps.

Chris Krelle
--NobodyCam


On Thu, Jun 5, 2014 at 5:54 AM, 严超  wrote:

> Sorry, it was ESXI.
>
> *Best Regards！*
>
>
> *Chao Yan --**My twitter：Andy Yan @yanchao727
> *
>
>
> *My Weibo：http://weibo.com/herewearenow
> --*
>
>
> 2014-06-05 19:39 GMT+08:00 严超 :
>
> Hi, All:
>> Is ironic support EXSI when boot a bare metal ? If we can, how to
>> make vmware EXSI ami bare metal image ?
>>
>> *Best Regards！*
>>
>>
>> *Chao Yan--**My twitter：Andy Yan @yanchao727
>> *
>>
>>
>> *My Weibo：http://weibo.com/herewearenow
>> --*
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Nominating Dmitry Tantsur to ironic-core

[Chris K]

Please count me in +1 column :)

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

Re: [openstack-dev] Results of the TC Election

[Chris K]

I would like to thank the parting TC members for their service and
congratulate the new TC members for the up and coming cycle!

Well Done, and Great Job ALL!

Chris



On Fri, Apr 25, 2014 at 8:30 AM, Anita Kuno  wrote:

> Please join me in congratulating the 7 newly elected members of the TC.
>
> * Thierry Carrez
> * Jay Pipes
> * Vishvananda Ishaya
> * Michael Still
> * Jim Blair
> * Mark McClain
> * Devananda van der Veen
>
> Full results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_d34934c9fd1f6282
>
> Thank you to all candidates who stood for election, having a good group
> of candidates helps engage the community in our democratic process,
>
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voice is heard.
>
> Thanks to my fellow election official, Tristan Cacqueray, I appreciate
> your help and perspective.
>
> Thank you for another great round.
>
> Here's to Juno,
> Anita.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] review hour?

[Chris K]

Hi Marios,

Just my two cents. I have found these "Review Jam's" to be quite useful.
Ironic has been able to accomplish quite a bit having this style of review,
and I believe been able to provide good concise reviews back to the Devs.

Chris Krelle


On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com wrote:

> Hi,
>
> I think both PTL candidates mentioned process improvements wrt
> contributions and reviews in their candidacy announcements. As a new
> Neutron dev I have seen that it is easy for reviews to go unnoticed,
> especially when they are stand-alone bug fixes that aren't part of a
> particular blueprint group (and so aren't discussed/highlighted at the
> various sub-team meetings). Of course this is also compounded by a
> seemingly heavy backlog of reviews. I realise that all core/non-core
> devs are doing as much as they can and though more cores will help, it
> takes a long time to develop people into this role.
>
> I was wondering if a 'review hour' would help. This is something Lucas
> Gomez told me about; the Ironic core team has a weekly hour slot in
> which they discuss x number of reviews and approve or -1 them. Besides
> getting reviews cleared quicker, it also opens the process up. It will
> allow new contributors to (more quickly) learn about the kinds of things
> core reviewers look for in a patch and also give real-time feedback
> (e.g. could just use #openstack-neutron for discussion during the hour).
> I feel that this could have an impact on the review backlog even if this
> only tackling the oldest 5 reviews for example.
>
> Do any of the core devs think this would be a good thing, and do you
> think you have the time for it?
>
> thanks, marios
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] March core team review

[Chris K]

+1 for all. Each has demonstrated a good understanding of the project and
its goals.

Chris
On Apr 8, 2014 9:31 AM, "Devananda van der Veen" 
wrote:
>
> As March has come to a close, and Juno is open for development, I would
like to look at our review stats and see if the core review team should be
adjusted to reflect current activity. Also, since I believe that our
development pace needs to accelerate, I would like to increase the size of
the team from its current size of six.
>
> As a quick outline of what "core" means within this team: in my view,
it's a combination of how active and effective someone's reviews are, and
how much they participate in relevant discussions. Ideally, cores should
aim for about two reviews per work day, or about 40 per month, but it's not
a hard limit, and I don't believe we should remove folks simply because
their review stats slip below this line if their input is still felt and
valued within the project.
>
> With ~160 reviews submitted in the last month, in an ideal situation, we
would be able to keep up with submissions if we had a review team size of 8
(since it takes a minimum of two cores to land a patch). Given that reviews
have been taking an average of 2.8 patch sets, we would actually fall
behind if reviewers didn't do more than 2/day - and for a large part of
Icehouse, we were pretty far behind... For this reason, reviews by non-core
members are extremely helpful because they often catch issues early and
allow core reviewers to focus on patches that have already received some
+1's.
>
> Here are the current 90-day stats, cut at the point where folks are
meeting the suggested quantity of reviews.
>
> http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
>
>
++---++
> |  Reviewer  | Reviews   -2  -1  +1  +2  +A+/- % |
Disagreements* |
>
++---++
> |devananda **| 358   22 101   7 228 13265.6% |   10 (
2.8%)  |
> |   lucasagomes **   | 3164  99   4 209  6167.4% |8 (
2.5%)  |
> |nobodycam **| 1990  24   0 175  8187.9% |   11 (
5.5%)  |
> |rloo| 1800  74 106   0   058.9% |8 (
4.4%)  |
> |   whaom| 1530  56  97   0   063.4% |   15 (
9.8%)  |
> |   yuriyz   | 1360  57  79   0   058.1% |   14 (
10.3%)  |
> |max_lobur **| 1311  44  38  48   465.6% |7 (
5.3%)  |
>
> So, I'd like to formally propose that Ruby (rloo), Haomeng (whaom), and
Yuriy (yuriyz) be added to the core team at this time. I believe they have
all been very helpful over the last few months.
>
> Regards,
> Devananda
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

[Chris K]

Hi David,

We are in feature freeze right now, waiting for the Juno cycle to open up,
so there are several reviews that are holding. If you are able please join
the #opensack-ironic IRC channel, there is almost always a core member in
channel who should be able to answer any questions you have about specific
reviews.

Chris Krelle


On Mon, Mar 31, 2014 at 8:47 AM, David Kranz  wrote:

> I was reviewing some ironic changes that are more than a week old and do
> not have any reviews from the ironic team. Having at least one review from
> the ironic team would be very helpful.
>
>  -David
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] ilo driver need to submit a code change in nova ironic driver

[Chris K]

Hi Barmawer,

Currently the Ironic Nova driver is blocked from merging. The Ironic team
is working on getting all the pieces in place for our C.I. testing. At this
point I would say your best path is to create your patch with 51328 as a
dependency. Please note that the nova driver will most likely be going
through several more revisions as we get closer. This will mean that your
dependent patch will need to rebased as new Nova driver patches are pushed
up. This is very common, I am just pointing it out so that you can keep an
eye out for the "[OUTDATED]" tag on the review. Also please tag your
dependent patch with "implements bp:deprecate-baremetal-driver" this will
ensure your patch is added to the Blue Print, and make it clear that is
part of the deprecate-baremetal-driver patch set.


Chris Krelle


On Mon, Feb 24, 2014 at 6:05 AM, Faizan Barmawer
wrote:

> Hi All,
>
> I am currently working on ilo driver for ironic project.
> As part of this implementation and to integrate with nova ironic driver (
> https://review.openstack.org/#/c/51328/) we need to make changes to
> "driver.py" and "ironic_driver_fields.py" files, to pass down ilo driver
> specific fields to the ironic node. Since nova ironic driver code review
> still in progress and not yet integrated into openstack, we have not
> included this piece of code in the ilo driver code review patch (
> https://review.openstack.org/#/c/73787/).
>
> We need your suggestion on delivering this part of ilo driver code change
> in nova ironic driver.
> - Should we wait for the completion of nova ironic driver and then raise a
> defect to submit these changes? or
> - should we raise a defect now and submit for review, giving the
> dependency on the nova ironic driver review? or
> - Can we use the existing blueprint for ilo driver to raise a separate
> review for this code change giving nova ironic driver as dependency?
>
> Please suggest a better way of delivering these changes.
>
> Thanks & Regards,
> Barmawer
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] first review jam session redux

[Chris K]

*I think this was great. We got a lot accomplished in very little time --
let's plan to do this again **next Thursday*, *8am* *PST*
Totally +1 from me

*Let's also have a shorter review session at the same time on
Monday morning, before the meeting.*
Would this be another review session or recap for the meeting?

and may I say:
Great Job Everyone!

Chris Krelle
-NobodyCam


On Thu, Feb 13, 2014 at 10:29 AM, Devananda van der Veen <
devananda@gmail.com> wrote:

> Just a quick follow-up to our first "review jam session". We got 5 patches
> landed in the server 3 in the client, and zuul is merging another 5 right
> now.
>
> We started an etherpad part-way through
>   https://etherpad.openstack.org/p/IronicReviewDay
> Let's continue to use that to track work that spins out of these sessions.
>
> I think this was great. We got a lot accomplished in very little time --
> let's plan to do this again next Thursday, 8am PST (16:00 GMT).
>
> Let's also have a shorter review session at the same time on Monday
> morning, before the meeting.
>
> Cheers!
> Deva
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] review days

[Chris K]

Roman:
*Since there are two core-subteams located in different time zones I
propose making two sessions:*
*- One in the morning in Europe. Let's say at 10 GMT*
*- One in the morning in the US at a convenient time.*

I like this but it might be confusing to the devs, at least initially. I
would vote to moving the initial meeting from 8 to say 8:30 on Thursdays.
 I say lets talk about split review days in the next meeting?

Chris



On Wed, Feb 12, 2014 at 2:35 PM, Roman Prykhodchenko <
rprikhodche...@mirantis.com> wrote:

> Since there are two core-subteams located in different time zones I
> propose making two sessions:
> - One in the morning in Europe. Let's say at 10 GMT
> - One in the morning in the US at a convenient time.
>
> This approach might be useful for the submitters located in different time
> zones.
>
>
> - Roman
>
> On Feb 13, 2014, at 00:18 , Maksym Lobur  wrote:
>
> Also, I think 3 hours might be too much, maybe to have 2 sessions of 2
> hours. It might be hard to concentrate on review for 3 hours in a line..
>
> Best regards,
> Max Lobur,
> Python Developer, Mirantis, Inc.
>
> Mobile: +38 (093) 665 14 28
> Skype: max_lobur
>
> 38, Lenina ave. Kharkov, Ukraine
> www.mirantis.com
> www.mirantis.ru
>
>
> On Wed, Feb 12, 2014 at 11:32 PM, Maksym Lobur wrote:
>
>> Hi All,
>>
>> I like the idea! I'm comfortable to reserve about 3 hours for this,
>> Thursdays 8am (4pm GMT +0) sounds good. I assume we'll pick and merge as
>> much patches as possible during that time, and if the last one doesn't fit
>> to the time - we're increasing the time until the patch merged (in
>> reasonable limit). Makes sense?
>>
>> Best regards,
>> Max Lobur,
>> Python Developer, Mirantis, Inc.
>>
>> Mobile: +38 (093) 665 14 28
>> Skype: max_lobur
>>
>> 38, Lenina ave. Kharkov, Ukraine
>> www.mirantis.com
>> www.mirantis.ru
>>
>>
>> On Wed, Feb 12, 2014 at 11:14 PM, Devananda van der Veen <
>> devananda@gmail.com> wrote:
>>
>>> Hi again!
>>>
>>> I promise this will be a much shorter email than my last one ... :)
>>>
>>> I'd like to propose that we find regular day/time to have a recurring
>>> code jam. Here's what it looks like in my head:
>>> - we get at least three core reviewers together
>>> - as many non-core folks as show up are welcome, too
>>> - we tune out all distractions for a few hours
>>> - we pick a patch and all review it
>>>
>>> If the author is present, we iterate with the author, and review each
>>> revision they submit while we're all together. If the author is not present
>>> and there are only minor issues, we fix them up in a follow-on patch and
>>> land both at once. If neither of those are possible, we -1 it and move on.
>>>
>>> I think we could make very quick progress in our review queue this way.
>>> In particular, I want us to plow through the bug fixes that have been in
>>> Fix Proposed status for a while ...
>>>
>>> What do ya'll think of this idea? Useful or a doomed to fail?
>>>
>>> What time would work for you? How about Thursdays at 8am PST?
>>>
>>>
>>> Cheers,
>>> Devananda
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][baremetal] Status of nova baremetal and ironic

[Chris K]

Hi Taurus,

You are correct Ironic is under rapid development right now, there are
several patches in flight right now critical to Ironic. There have been
successful tests using Ironic to boot both vm's and real hardware, but at
this time I would say we are just about out of alpha and entering bata
stages. Ironic's Goal is to graduate from incubation in the Icehouse cycle,
and start integration in the "J" cycle. We are working on a migration path
from Nova-bm to Ironic as part of this graduation. With out knowing what
environment you are using Nova-bm it is very difficult to say when you
should look at switching, but off the top of my head I would say: "Look at
evaluating after the Icehouse release."  I would include with that "Check
back often, things are changing quickly."


Chris Krelle
NobodyCam


On Fri, Feb 7, 2014 at 1:58 AM, Taurus Cheung  wrote:

> I am working on deploying images to bare-metal machines using nova
> bare-metal. So far working well.
>
>
>
> I know Ironic is under rapid development. Could I know the current status
> of Ironic and the suitable time to shift from nova baremetal to Ironic?
>
>
>
> Regards,
>
> Taurus
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] January review redux

[Chris K]

I have worked with both Max and Roman for sometime now,
Both are very active in the Ironic IRC channel and are a pleasure to work
with. They both have good grasp of the projects goals, and I look forward
to having them as Ironic Core members.

So with that I fully +1 both Max and Roman. (do two +1's equal one +2?)

Chris Krelle
NobodyCam




On Tue, Feb 4, 2014 at 11:42 AM, Devananda van der Veen <
devananda@gmail.com> wrote:

> The last month and a half had most of our team out for holiday leave at
> some point, and the review stats reflect that. I had hoped our review queue
> would come down once we all got back from the holidays, but that hasn't
> happened. In fact, our review queue has grown significantly  Perhaps
> it's a combination of the usual nearing-end-of-cycle-rush and our gate
> breaking twice in the last 10 days
>
> Here are the stats for the last month [1]
>
> Total reviews: 569 (19.0/day)
>  Total reviewers: 28 (avg 0.7 reviews/day)
> Total reviews by core team: 211 (7.0/day)
>  Core team size: 6 (avg 1.2 reviews/day)
> New patch sets in the last 30 days: 347 (11.6/day)
>  Changes involved in the last 30 days: 119 (4.0/day)
> New changes in the last 30 days: 93 (3.1/day)
>  Changes merged in the last 30 days: 56 (1.9/day)
> Changes abandoned in the last 30 days: 13 (0.4/day)
>  Changes left in state WIP in the last 30 days: 4 (0.1/day)
> Queue growth in the last 30 days: 20 (0.7/day)
>  Average number of patches per changeset: 2.9
>
>
> And here are the current / average stats [2]
>
>  Total Open Reviews: 48
>  Waiting on Submitter: 16
>  Waiting on Reviewer: 32
>  Stats since the latest revision:
>   Average wait time: 6 days, 21 hours, 8 minutes
>   1rd quartile wait time: 3 days, 15 hours, 59 minutes
>   Median wait time: 5 days, 13 hours, 4 minutes
>   3rd quartile wait time: 10 days, 6 hours, 2 minutes
>   Number waiting more than 7 days: 14
>
> I would very much like to add a few people to our core review team. We
> need to increase the pace of reviews to keep up with development,
> particularly as we approach our most aggressive milestone and prepare for
> our first release. I'd also like to improve our non-US-timezone coverage.
>
> So, I'd like to nominate the following two additions to the ironic-core
> team:
>
> Max Lobur
>
> https://review.openstack.org/#/q/reviewer:mlobur%2540mirantis.com+project:openstack/ironic,n,z
>
> Roman Prykhodchenko
>
> https://review.openstack.org/#/q/reviewer:rprikhodchenko%2540mirantis.com+project:openstack/ironic,n,z
>
> I believe that the review feedback that I've seen from both of them shows
> a good understanding of the project architecture and the direction that I'd
> like Ironic to go.
>
> Max has been consistently reviewing patches for the last few months. His
> input has been very valuable in spotting issues early on, and clearly show
> a good grasp of the project's architecture. He is frequently engaged with
> the existing team during discussions in IRC and in the weekly meetings.
>
> Roman was involved in Ironic early on, then spent a few months focusing on
> our devstack and tempest patches [3]. He continues to help with the
> ironic-related work in those projects, is engaged in discussions both in
> channel and during meetings, and has resumed doing reviews on a regular
> basis.
>
> With this, we would have one core in NZ, two in US, and three in EU time
> zones.
>
>
> Regards,
> Devananda
>
>
> [1] - http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt
> [2] - http://russellbryant.net/openstack-stats/ironic-openreviews.html
> [3] -
> https://review.openstack.org/#/q/owner:rprikhodchenko%2540mirantis.com,n,z
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [QA] some notes on ironic functional testing

[Chris K]

Hi Alexander,

Reading your post got me to thinking. What if we modified the ssh driver so
it used the libvirt api. Just off the top of my head some thing along the
lines of changing the ssh driver to issue python-libvirt commands would
work. As an example:



>  shh user@host "python -c \"import libvirt;conn =
> libvirt.openReadOnly(None);dom0 = conn.lookupByName('seed');print 'Seed: id
> %d running %s' % (dom0.ID(), dom0.OSType())\""
>


> Seed: id 2 running hvm


This seems like a straight forward improvement to the driver, and should
improve overall performance.


Chris Krelle
NobodyCam


On Wed, Jan 15, 2014 at 2:22 AM, Alexander Gordeev wrote:

> Hi, Devananda
>
>
> On Wed, Jan 15, 2014 at 8:19 AM, Devananda van der Veen <
> devananda@gmail.com> wrote:
>
>>
>> On Tue, Jan 14, 2014 at 6:28 AM, Alexander Gordeev > > wrote:
>>
>>>
>>>- Secondly, virsh has some performance issues if you deal with >30
>>>VMs (it is not our case for now but who knows).
>>>
>>> This is a reason why you want to use python libvirt api instead of virsh
>> CLI, correct? I don't see a problem, but I will defer to the tempest devs
>> on whether that's OK.
>>
>>
> Yes, that's correct. In short, using of python API binding makes possible
> to execute all operations inside just one opened libvirt connection. Virsh
> CLI opens new connection every time when you call it. Every new connection
> produces a fork of libvirt daemon. When you're going to spawn/create/modify
> few dozens of VMs in short period of time this performance issue becomes
> very noticeable.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Nominating Lucas Gomes to ironic core

[Chris K]

+1 Lucas has been a great asset to the ironic team.


On Thu, Oct 24, 2013 at 5:18 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

> Hi all,
>
> I'd like to nominate Lucas Gomes for ironic-core. He's been consistently
> doing reviews for several months and has led a lot of the effort on the API
> and client libraries.
>
> Thanks for the great work!
> -Deva
>
> http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] PTL nomination

[Chris K]

+1
Devananda is a great PLT. It is his vision that has and is driving Ironic's
rapid development.


Chris Krelle


On Tue, Sep 24, 2013 at 11:04 AM, Devananda van der Veen <
devananda@gmail.com> wrote:

> Hi!
>
> I would like to nominate myself for the OpenStack Bare Metal Provisioning
> (Ironic) PTL position.
>
> I have been working with OpenStack for over 18 months, and was a
> scalability and performance consultant at Percona for four years prior.
> Since '99, I have worked as a developer, team lead, database admin, and
> linux systems architect for a variety of companies.
>
> I am the current PTL of the Bare Metal Provisioning (Ironic) program,
> which began incubation during Havana. In collaboration with many fine folks
> from HP, NTT Docomo, USC/ISI, and VirtualTech, I worked extensively on the
> Nova Baremetal driver during the Grizzly cycle. I also helped start the
> TripleO program, which relies heavily on the baremetal driver to achieve
> its goals. During the Folsom cycle, I led the effort to improve Nova's DB
> API layer and added devstack support for the OpenVZ driver. Through that
> work, I became a member of nova-core for a time, though my attention has
> shifted away from Nova more recently.
>
> Once I had seen nova-baremetal and TripleO running in our test environment
> and began to assess our longer-term goals (eg, HA, scalability, integration
> with other OpenStack services), I felt very strongly that bare metal
> provisioning was a separate problem domain from Nova and would be best
> served with a distinct API service and a different HA framework than what
> is provided by Nova. I circulated this idea during the last summit, and
> then proposed it to the TC shortly thereafter.
>
> During this development cycle, I feel that Ironic has made significant
> progress. Starting from the initial "git bisect" to retain the history of
> the baremetal driver, I added an initial service and RPC framework,
> implemented some architectural pieces, and left a lot of #TODO's. Today,
> with commits from 10 companies during Havana (*) and integration already
> underway with devstack, tempest, and diskimage-builder, I believe we will
> have a functional release within the Icehouse time frame.
>
> I feel that a large part of my role as PTL has been - and continues to be
> - to gather ideas from a wide array of individuals and companies interested
> in bare metal provisioning, then translate those ideas into a direction for
> the program that fits within the OpenStack ecosystem. Additionally, I am
> often guiding compromise between the long-term goals, such as firmware
> management, and the short-term needs of getting the project to a
> fully-functional state. To that end, here is a brief summary of my goals
> for the project in the Icehouse cycle.
>
> * API service and client library (likely finished before the summit)
> * Nova driver (blocked, depends on ironic client library)
> * Finish RPC bindings for power and deploy management
> * Finish merging bm-deploy-helper with Ironic's PXE driver
> * PXE boot integration with Neutron
> * Integrate with TripleO / TOCI for automated testing
> * Migration script for existing deployments to move off the nova-baremetal
> driver
> * Fault tolerance of the ironic-conductor nodes
> * Translation support
> * Docs, docs, docs!
>
> Beyond this, there are many long-term goals which I would very much like
> to facilitate, such as:
>
> * hardware discovery
> * better integration with SDN capable hardware
> * pre-provisioning tools, eg. management of bios, firmware, and raid
> config, hardware burn-in, etc.
> * post-provisioning tools, eg. secure-erase
> * boot from network volume
> * secure boot (protect deployment against MITM attacks)
> * validation of signed firmware (protect tenant against prior tenant)
>
> Overall, I feel honored to be working with so many talented individuals
> across the OpenStack community, and know that there is much more to learn
> as a developer, and as a program lead.
>
> (*)
>
> http://www.stackalytics.com/?release=havana&metric=commits&project_type=All&module=ironic
>
> http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt
> http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt
>
> --
> Devananda
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TRIPLEO] Derekh for tripleo core

[Chris K]

+1 here


On Tue, Aug 27, 2013 at 2:25 PM, Robert Collins
wrote:

> http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
>
> - Derek is reviewing fairly regularly and has got a sense of the
> culture etc now, I think.
>
> So - calling for votes for Derek to become a TripleO core reviewer!
>
> I think we're nearly at the point where we can switch to the 'two
> +2's' model - what do you think?
>
> Also tsk! to those cores who aren't reviewing as regularly :)
>
> Cheers,
> Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] mid-cycle sprint?

[Chris K]

I'll cast my vote for the Aug dates as they are better for me.

chris


On Tue, Jul 16, 2013 at 8:42 AM, Byrum, Clint  wrote:

> So my original thinking was lets get together before H3 and push on things
> that need to get done for H3. If, however, people would rather we get
> together after H3, there is plenty to be done in that time frame, including
> documentation updates and closing critical bugs before the release.
>
> I am available and thus +1 for either Aug 19/20 or Sep 16/17.
> 
> From: Robert Collins [robe...@robertcollins.net]
> Sent: Monday, July 15, 2013 11:32 PM
> To: OpenStack Development Mailing List
> Cc: Joe Gordon; Taylor, Monty; dpri...@redhat.com; Cody Somerville;
> der...@redhat.com; Hernando Rivero, Juan Gregorio (HPCS); mr. nobody;
> Chris Blumentritt; Jesse Keating; Steve Baker; Byrum, Clint; Rainya Mosher;
> Johannes Erdfelt; lucasago...@gmail.com; Elizabeth Krumbach Joseph; Brian
> Lamar; Chris Jones; Devananda van der Veen
> Subject: Re: [TripleO] mid-cycle sprint?
>
> So consensus seems to be Seattle - cool, lets lock that in.
>
> As for dates, the basic tension is: either aug 19th, *before* H3, or
> after - e.g. 9th or 16th sept (I have a conference on the 6/7/8th here
> in NZ, so doing either the 2nd sept or the 9th will be tricky. I can
> do the 10th and miss the first day : I don't think I'm critical,
> though I would rather be there the whole time.
>
> Will give this 24h for feedback then am picking a date (so that we can
> book and stuff a month out rather than on silly expensive fares).
>
> -Rob
>
> On 14 July 2013 05:35, Devananda van der Veen 
> wrote:
> > Adding my vote for the first week of September.
> ...
>
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Cloud Services
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev