Re: [openstack-dev] [ironic][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes

[Shivanand Tendulker]

+1 to all proposed changes.

Thanks and Regards
Shivanand

On Thu, Aug 23, 2018 at 11:54 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] Proposing Mark Goddard to ironic-core

[Shivanand Tendulker]

+1 from me.



On Sun, May 20, 2018 at 8:15 PM, 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] Nominating Hironori Shiina for ironic-core

[Shivanand Tendulker]

+1

On Wed, Feb 7, 2018 at 11:53 AM, John Villalovos  wrote:

> +1
>
> On Mon, Feb 5, 2018 at 10:12 AM, Julia Kreger  > wrote:
>
>> I would like to nominate Hironori Shiina to ironic-core. He has been
>> working in the ironic community for some time, and has been helping
>> over the past several cycles with more complex features. He has
>> demonstrated an understanding of Ironic's code base, mechanics, and
>> overall community style. His review statistics are also extremely
>> solid. I personally have a great deal of trust in his reviews.
>>
>> I believe he would make a great addition to our team.
>>
>> Thanks,
>>
>> -Julia
>>
>> 
>> __
>> 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

[openstack-dev] [ironic] FFE request for node rescue feature

[Shivanand Tendulker]

Hi

The rescue feature [1] is an high priority for ironic in Queens. The spec
for the same was merged in Newton. This feature is necessary for users that
lose regular access to their machine (e.g. lost passwords).

Landing node rescue feature late in the cycle will lead to less time being
available for testing, with a risk that the feature being released with
defects. The code changes are fairly isolated from existing code to ensure
it does not cause any regression. The Ironic side rescue code patches are
all in review [2], and are now are getting positive reviews or minor
negative feedback.

dtantsur and TheJulia have kindly agreed to review the same during the FFE
window.

[1]
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/implement-rescue-mode.html
[2]
https://review.openstack.org/#/q/topic:bug/1526449+(status:open+AND+project:openstack/ironic)

Thanks and Regards,
Shiv (stendulker)
__
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

[Shivanand Tendulker]

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
>
> __
> 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] Proposing Shivanand Tendulker for ironic-core

[Shivanand Tendulker]

Thank you all for your support and trust.

Regards
Shiv

On Mon, Oct 9, 2017 at 10:18 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> Okay, we have the majority of cores (plus a few non-cores), and no
> objections.
> Welcome to the team! :)
>
> On 10/03/2017 10:07 PM, milanisko k wrote:
> > +1 :)
> >
> > --
> > milan
> >
> > út 3. 10. 2017 v 18:02 odesílatel Vladyslav Drok <vd...@mirantis.com
> > <mailto:vd...@mirantis.com>> napsal:
> >
> > +1 for Shiv
> >
> >
> > On 3 Oct 2017 11:20 a.m., "Sam Betts (sambetts)" <sambe...@cisco.com
> > <mailto:sambe...@cisco.com>> wrote:
> >
> > +1,
> >
> > __ __
> >
> > Sam
> >
> > __ __
> >
> > On 03/10/2017, 08:21, "tua...@vn.fujitsu.com
> > <mailto:tua...@vn.fujitsu.com>" <tua...@vn.fujitsu.com
> > <mailto:tua...@vn.fujitsu.com>> wrote:
> >
> > __ __
> >
> > +1 , Yes, I definitely agree with you.
> >
> > 
> >
> > Regards
> >
> > Tuan
> >
> > 
> >
> > *From:*Nisha Agarwal [mailto:agarwalnisha1...@gmail.com
> > <mailto:agarwalnisha1...@gmail.com>]
> > *Sent:* Tuesday, October 03, 2017 12:28 PM
> > *To:* OpenStack Development Mailing List (not for usage
> questions)
> > <openstack-dev@lists.openstack.org
> > <mailto:openstack-dev@lists.openstack.org>>
> > *Subject:* Re: [openstack-dev] [ironic] Proposing Shivanand
> Tendulker
> > for ironic-core
> >
> > 
> >
> > +1
> >
> > 
> >
> > Regards
> >
> > Nisha
> >
> > 
> >
> > On Mon, Oct 2, 2017 at 11:13 PM, Loo, Ruby <ruby@intel.com
> > <mailto:ruby@intel.com>> wrote:
> >
> > +1, Thx Dmitry for the proposal and Shiv for doing all the
> work :D
> >
> > 
> >
> > --ruby
> >
> > 
> >
> > *From: *Dmitry Tantsur <dtant...@redhat.com
> >     <mailto:dtant...@redhat.com>>
> > *Reply-To: *"OpenStack Development Mailing List (not for
> usage
> > questions)" <openstack-dev@lists.openstack.org
> > <mailto:openstack-dev@lists.openstack.org>>
> > *Date: *Monday, October 2, 2017 at 10:17 AM
> > *To: *"OpenStack Development Mailing List (not for usage
> questions)"
> > <openstack-dev@lists.openstack.org
> > <mailto:openstack-dev@lists.openstack.org>>
> > *Subject: *[openstack-dev] [ironic] Proposing Shivanand
> Tendulker
> > for ironic-core
> >
> > 
> >
> > Hi all!
> >
> > I would like to propose Shivanand (stendulker) to the core
> team.
> >
> > His stats have been consistently high [1]. He has given a
> lot of
> > insightful reviews recently, and his expertise in the iLO
> driver is
> > also very valuable for the team.
> >
> > As usual, please respond with your comments and
> objections.
> >
> > Thanks,
> >
> > Dmitry
> >
> >
> > [1] http://stackalytics.com/report/contribution/ironic-
> group/90
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > <http://openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> > 
> >
> > 
> >
> > -- 
> >
> > The Secret Of Success is learning how to use pain and pleasure,
> instead
> > of having pain and pleasure use you. If

[openstack-dev] [Ironic] Regarding where to host Redfish vendor extensions code for Ironic

[Shivanand Tendulker]

Hi All

This is wrt discussion we had about where to host the Redfish vendor
vendor extensions. Should it be sub-module within sushy-tree or
separate vendor project(s).

The following were the opinions:-
In favor of Sushy  sub-module:-
1. People see "vendor specific" repo's as owned by the vendor and it
puts of contributors that aren't the vendor but happen to have that
vendors hardware leading to low-contribution rate
2. Lot of code duplication across vendor libs as extensions could be similar.
3. Code leverage would be easier.

In favor of separate vendor project(s):-
1. Each vendor has their own unique hardware or firmware features
enabled through extensions
2. Number of extensions could be large.
3. Ironic cores may find it tedious to review vendor extensions and
also add into their pile of work
4. It gives flexibility to individual vendor to own and maintain its
own extensions

Detailed discussion :
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-3/%23openstack-meeting-3.2017-05-22.log.html#t2017-05-22T17:25:13

Please let us know your opinion/comments on the same.

Thanks and Regards
stendulker

__
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] usage of ironic-lib

[Shivanand Tendulker]

I tend to agree with Lucas. I think ironic-lib was designed to have common
code to be used primarily into ironic and IPA. It was not intended to be
used in other projects. We tend to add methods in the ironic-lib with
Ironic and IPA in mind and never thought of it could be used by out of tree
drivers.

But it would be useful, it were to consumed by out of tree drivers.

Thanks,
Shiv

On Mon, May 16, 2016 at 8:26 PM, Sam Betts (sambetts) 
wrote:

> I personally disagree with saying that if we wanted it make it usable by
> projects other than ones in the Ironic umbrella it should go into oslo. I
> think that non-ironic projects directly related to Ironic such as out of
> tree drivers etc, should be able to utilise the code placed into
> ironic-lib.
>
> Neutron are doing a very similar thing for all their drivers/extensions
> they have broken out over the last 2 cycles,
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-li
> b.html.
>
> Making ironic-lib available to out of tree drivers etc also puts us into a
> good position to begin the work to stabilise things like the driver API.
> Neutron is making the rule that out of tree drivers shouldn¹t
> inherit/import anything from the neutron core code base, only neutron-lib,
> they are doing this to provide a stable interface that shouldn¹t be broken
> by changes to neutron core. I think we could do the same, with in-tree
> drivers dog-fooding the driver api we provide in ironic-lib.
>
> Sam
>
> On 16/05/2016 15:14, "Lucas Alvares Gomes"  wrote:
>
> >Hi,
> >
> >Thanks for starting this discussion Ruby.
> >
> >On Mon, May 16, 2016 at 2:57 PM, Loo, Ruby  wrote:
> >> Hi,
> >>
> >> A patch to ironic-lib made me wonder about what is our supported usage
> >>of
> >> ironic-lib. Or even the intent/scope of it. This patch changes a method,
> >> Œbootable¹ parameter is removed and Œboot_flag¹ parameter is added [1].
> >>
> >> If this library/method is used by some out-of-tree thing (or even some
> >> in-tree but outside of ironic), this will be a breaking change. If this
> >> library is meant to be internal to ironic program itself, and to e.g.
> >>only
> >> be used by ironic and IPA, then that is different. I was under the
> >> impression that it was a library and meant to be used by whatever, no
> >> restrictions on what that whatever was. It would be WAY easier if we
> >>limited
> >> this for usage by only a few specified projects.
> >>
> >> What do people think?
> >>
> >
> >I still believe that the ironic-lib project was designed to share code
> >between the Ironic projects _only_. Otherwise, if it the code was
> >supposed to be shared across multiple projects we should have put it
> >in oslo instead.
> >
> >The governance description is a bit vague [0], it does say: "A python
> >library of common ironic utilities.". Does it include out-of-tree
> >ironic-related code? I would like to think that it does not. The fact
> >that ( IIRC ) we never stated that this is a public library, there's
> >no documentation of any methods/modules there, no release notes, no
> >sample usages, etc... Makes it a bit unsuitable for 3rd party
> >consumption.
> >
> >That said, I'm not totally against make this library suitable for a
> >broader usage but this will require more thoughts on it and effort.
> >
> >[0]
> >
> https://github.com/openstack-infra/project-config/blob/920441f2fc02df89624
> >5b53e6f18b4ea6a0252a0/gerrit/projects.yaml#L2193
> >
> >Cheers,
> >Lucas
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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

[Shivanand Tendulker]

Congratulations Julia !!



On Fri, Mar 25, 2016 at 9:38 PM, Jim Rollenhagen 
wrote:

> On Fri, Mar 25, 2016 at 12:03:34PM -0400, Julia Kreger wrote:
> > On Thu, Mar 24, 2016 at 3:08 PM, Jim Rollenhagen  >
> > wrote:
> >
> > > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core.
> >
> >
> > I would like to thank the academy for... oh wait... wrong speech.
> >
> > It is not often one gets to see a flood of positive messages from a
> > community, from the family that makes up Ironic.  And yes, I blushed.
> >
> > Thank you everyone!
>
> I see 8 cores in; sounds like consensus. Thank YOU, Julia, for your
> awesome work. :)
>
> Updating access lists now!
>
> // jim
>
> >
> > -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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Shivanand Tendulker]

+1 for  separate interface.

--Shivanand

On Fri, Nov 28, 2014 at 7:20 PM, Lucas Alvares Gomes lucasago...@gmail.com
wrote:

 Hi,

 Thanks for putting it up Dmitry. I think the idea is fine too, I
 understand that people may want to use in-band discovery for drivers like
 iLO or DRAC and having those on a separated interface allow us to composite
 a driver to do it (which is ur use case 2. ).

 So, +1.

 Lucas

 On Wed, Nov 26, 2014 at 3:45 PM, Imre Farkas ifar...@redhat.com wrote:

 On 11/26/2014 02:20 PM, Dmitry Tantsur wrote:

 Hi all!

 As our state machine and discovery discussion proceeds, I'd like to ask
 your opinion on whether we need an IntrospectionInterface
 (DiscoveryInterface?). Current proposal [1] suggests adding a method for
 initiating a discovery to the ManagementInterface. IMO it's not 100%
 correct, because:
 1. It's not management. We're not changing anything.
 2. I'm aware that some folks want to use discoverd-based discovery [2]
 even for DRAC and ILO (e.g. for vendor-specific additions that can't be
 implemented OOB).

 Any ideas?

 Dmitry.

 [1] https://review.openstack.org/#/c/100951/
 [2] https://review.openstack.org/#/c/135605/


 Hi Dmitry,

 I see the value in using the composability of our driver interfaces, so I
 vote for having a separate IntrospectionInterface. Otherwise we wouldn't
 allow users to use eg. the DRAC driver with an in-band but more powerful hw
 discovery.

 Imre


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



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


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

Re: [openstack-dev] [Ironic] Juno priorities and spec review timeline

[Shivanand Tendulker]

Hello Devananda

Design spec for the remote firmware setting feature is under review (
https://review.openstack.org/#/c/101122 ). Have received comments on the
APIs and we are converging on the set of required APIs.

Have posted the new patch addressing the comments on the same.

Please check, if we can re-prioritize this for Juno release.

Thanks and Regards
Shiv


On Tue, Jul 1, 2014 at 4:15 PM, Shivanand Tendulker stendul...@gmail.com
wrote:

 Hello Devananda

 Design spec for the remote firmware setting feature is under review (
 https://review.openstack.org/#/c/101122 ). Have received comments on the
 APIs and we are converging on the set of required APIs.

 Have posted the new patch addressing the comments on the same.

 Please check, if we can re-prioritize this for Juno release.

 Thanks and Regards
 Shiv



 On Tue, Jul 1, 2014 at 4:05 PM, Ramakrishnan G 
 rameshg87.openst...@gmail.com wrote:



 -- Forwarded message --
 From: Devananda van der Veen devananda@gmail.com
 Date: Tue, Jul 1, 2014 at 3:42 AM
 Subject: [openstack-dev] [Ironic] Juno priorities and spec review timeline
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
 


 Hi all!

 We're roughly at the midway point between summit and release, and I
 feel that's a good time to take a look at our progress compared to the
 goals we set out at the design summit. To that end, I re-opened my
 summit notes about what features we had prioritized in Atlanta, and
 engaged many the core reviewers in a discussion last friday to
 estimate what we'll have time to review and land in the remainder of
 this cycle. Based on that, I've created this spreadsheet to represent
 those expectations and our current progress towards what we think we
 can achieve this cycle:


 https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo

 Aside from several cleanup- and test-related tasks, these goals
 correlate to spec reviews that have already been proposed. I've
 crossed off ones which we discussed at the summit, but for which no
 proposal has yet been submitted. The spec-review team and I will be
 referring to this to help us prioritize specs reviews. While I am not
 yet formally blocking proposals which do not fit within this list of
 priorities, the review team is working with a large back-log and
 probably won't have time to review anything else this cycle. If you're
 concerned that you won't be able to land your favorite feature in
 Juno, the best thing you can do is to participate in reviewing other
 people's code, join the core team, and help us accelerate the
 development process of K.

 Borrowing a little from Nova's timeline, I have proposed the following
 timeline for Ironic. Note that dates listed are Thursdays, and numbers
 in parentheses are weeks until feature freeze.

 You may also note that I'll be offline for two weeks immediately prior
 to the Juno-3 milestone, which is another reason why I'd like the core
 review team to have a solid plan (read: approved specs) in place by
 Aug 14.



 July 3 (-9): spec review day on Wednesday (July 2)
  focus on landing specs for our priorities:

 https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo

 Jul 24 (-6): Juno-2 milestone tagged
  new spec proposal freeze

 Jul 31 (-5): midcycle meetup (July 27-30)
  https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint

 Aug 14 (-3): last spec review day on Wednesday (Aug 13)

 Aug 21 (-2): PTL offline all week

 Aug 28 (-1): PTL offline all week

 Sep  4 ( 0): Juno-3 milestone tagged
  Feature freeze
  K opens for spec proposals
  Unmerged J spec proposals must rebase on K
  Merged J specs with no code proposed are deleted and may
 be re-proposed for K
  Merged J specs with code proposed need to be reviewed for
 feature-freeze-exception

 Sep 25 (+3): RC 1 build expected
  K spec reviews start

 Oct 16 (+6): Release!

 Oct 30 (+8): K summit spec proposal freeze
  K summit sessions should have corresponding spec proposal

 Nov  6 (+9): K design summit


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