[openstack-dev] [magnum] Any plan to resume nodegroup work?

[Wan-yen Hsu]

Hi,

  I saw magnum nodegroup specs  https://review.openstack.org/425422,
https://review.openstack.org/433680, and
https://review.openstack.org/425431 were last updated a year ago.  is there
any plan to resume this work or is it superseded by other specs or features?

  Thanks!

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

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Wan-yen Hsu]

In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".
 "capabilities" provides a lot of flexibility for scheduling.  It supports
qualitative as well as quantitative attributes.  It supports a variety of
operators such as ">=", "<", "=", etc.   For instance, with "capabilities",
one can create a flavor for "GPU_Count >=2".  Quantity matters for
workloads.  A workload may require at least 2GPUs or at least certain
amount of SSD capacity to meet the performance requirements.   Trait will
help but it only supports qualitative attributes.  Therefore, we still need
"capabilities".

Standard Resource Class represents quantitative things but it 's not
available for Ironic.   Ironic currently can only use one single
CUSTOM_Resource_class with exact match.  Prior to Pike, Ironic customers
can use  non-exact match filter to support the use case of "at least this
amount of quantitative things on a bare metal node" but it's not supported
by Ironic Custom_resource_class.  Therefore it is a regression and will
cause issues for those who are depending on it.

On 19 October 2017 at 15:38, Jay Pipes  wrote:

> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>
>> Hi Matt,
>>
>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>> for capabilities(qualitative only) for ironic. It doesnt cover the
>> quantitative capabilities as 'traits' are meant only for qualitative
>> capabilities. Quantitative capabilities are covered by resource classes in
>> Nova. We have few (one or two) quantitative capabilities already supported
>> in ironic.
>>
>
> Hi Nisha,
>
> This may be a case of mixed terminology. We do not refer to anything
> quantitative as a "capability". Rather, we use the term "resource class"
> (or sometimes just "resource") to represent quantitative things that may be
> consumed by the instance.
>
> Traits, on the other hand, are qualitative. They represent a binary on/off
> capability that the compute host (or baremetal node in the case of Ironic)
> exposes.
>
> There's no limit on the number of traits that may be associated with a
> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
> the node.resource_class attribute is set, the Nova Ironic virt driver will
> create a single inventory record for the node containing a quantity of 1
> and a resource class equal to whatever is in the node.resource_class
> attribute. This resource class is auto-created by Nova as a custom resource
> class.
>

Just to follow up on this one...

I hope my traits spec will replace the need for the non-exact filters.

Consider two flavors Gold and Gold_Plus. Lets say Gold_plus gives you a
slightly newer CPU, or something.

Consider this setup:

* both GOLD and GOLD_PLUS ironic nodes have Resource Class: CUSTOM_GOLD
* but you can have some have trait: GOLD_REGULAR and some with GOLD_PLUS

Now you can have the flavors:

* GOLD flavor requests resources:CUSTOM_GOLD=1
* GOLD_PLUS flavor also has resources:CUSTOM_GOLD=1 but also
trait:GOLD_PLUS:requires

Now eventually we could modify the GOLD flavor to say:

* resources:CUSTOM_GOLD=1 and trait:GOLD_REGULAR:prefer

@Nisha I think that should largely allow you to construct the same behavior
you have today, or am I totally missing what you are wanting to do?

On Thu, Oct 19, 2017 at 8:37 AM, John Garbutt  wrote:

> On 19 October 2017 at 15:38, Jay Pipes  wrote:
>
>> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>>
>>> Hi Matt,
>>>
>>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>>> for capabilities(qualitative only) for ironic. It doesnt cover the
>>> quantitative capabilities as 'traits' are meant only for qualitative
>>> capabilities. Quantitative capabilities are covered by resource classes in
>>> Nova. We have few (one or two) quantitative capabilities already supported
>>> in ironic.
>>>
>>
>> Hi Nisha,
>>
>> This may be a case of mixed terminology. We do not refer to anything
>> quantitative as a "capability". Rather, we use the term "resource class"
>> (or sometimes just "resource") to represent quantitative things that may be
>> consumed by the instance.
>>
>> Traits, on the other hand, are qualitative. They represent a binary
>> on/off capability that the compute host (or baremetal node in the case of
>> Ironic) exposes.
>>
>> There's no limit on the number of traits that may be associated with a
>> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
>> the node.resource_class attribute is set, the Nova Ironic virt driver will
>> create a single inventory record for the node containing a quantity of 1
>> and a resource class equal to whatever is in the node.resource_class
>> attribute. This resource class is auto-created by Nova as a custom resource
>> class.
>>
>
> Just to 

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Wan-yen Hsu]

>>* Nisha is raising the question about whether or not we're making
*>>* incorrect assumptions about how people are using nova/ironic and they
*>>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as
*>>* far as I have ever heard is not recommended/supported upstream as it can
*>>* lead to resource tracking issues in Nova that eventually lead to
*>>* scheduling failures later because of the scheduler thinking a node is
*>>* available for more than one instance when it's really not.
*
>This came up in the Nova PTG room yesterday and I wanted to reply on the
>thread with what I understood about it, for those who weren't in the
>session. In general, it's recommended to use the exact filters (1 flavor
>per Ironic node hardware config) as there's no concept of partially
>claiming a baremetal node.

>But, with the old non-exact filters, you _could_ get away with creating
>fewer flavors than you have hardware configs and get "fuzzy matching" on
>Ironic nodes, to get nodes whose configs are "close enough" but not
>exact. This might be helpful in situations where you have some oddball
>configs you don't want to have separate flavors for.
>I was thinking, if it's possible to assign more than one resource class
>to an Ironic node, maybe you could get similar behavior to the old
>non-exact filters. So if you have an oddball config, you could tag it as
>multiple resource classes that it's "close enough" to for a match. But
>I'm not sure whether it's possible for an Ironic node to be tagged with
>more than one resource class.


>* Nisha is raising the question about whether or not we're making
*>* incorrect assumptions about how people are using nova/ironic and they
*>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as
*>* far as I have ever heard is not recommended/supported upstream as it can
*>* lead to resource tracking issues in Nova that eventually lead to
*>* scheduling failures later because of the scheduler thinking a node is
*>* available for more than one instance when it's really not.
*
 The concern I have with one single custom resource class for an
Ironic node is that it takes away some of the options that were
available before, such as scheduling based on resource quantity and
non-exact match filters (RamFilter, DiskFilter, and CoreFilter).  Nova
scheduling becomes too restrictive for Ironic.

  I know some users are using these options before Pike with no
issues.   Therefore, it's a mystery to me whether the non-exact filter
for Ironic really has issues.  Even if it has problems, it seems to me
there are ways to address the problem. For instance, Ironic virt
driver can report a node is not available if it's in active state (if
it hasn't done so), or report all resources are consumed when a node
is claimed.   Alternatively, Nova scheduler can report all resources
are consumed for an Ironic node if Nova is willing to make such
change.  Thanks!



On Thu, Sep 7, 2017 at 12:48 PM, Nisha Agarwal 
wrote:

> Hi Ironic Operators,
>
> From Pike, ironic nodes get scheduled based on just the resource class
> from nova. Do you guys see any concerns over this "rigid resource class
> only ironic scheduling"?
>
> To be more specific, at your datacentre/production environment what all
> filters are configured in nova.conf (configuration file for nova) for
> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>
> Thanks and Regards
> Nisha
>
>
> __
> 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]HP proliant create logical drive not according to the target_raid_config

[Wan-yen Hsu]

Hi Wangjun,

   Can you provide more info?

What driver did you use?
What's your target_raid_config?
What do the logical drives look like after the configuration?
Any log, server and storage hardware and firmware version info you can
share?

You are welcome to contact ilo_driv...@groups.ext.hpe.com  for
assistance.

Thanks!

Regards,
wanyen





On Wed, Jul 19, 2017 at 4:55 AM, 王俊  wrote:

> Hi,
>
>  May I ask a question about RAID?I set target_raid_config before I
> set the node state to ‘provide’, but when I make the node to available, the
> server’s logical drive does not like my configures.I don’t know why.who can
> give some help?
>
> 保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
>
> __
> 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] Ironic design summit schedule

[Wan-yen Hsu]

Hi Jim,

  I have asked techtalk coordinator to switch my techtalk session time so
there is no need to change group management session schedule.  You can keep
it  at 2:50pm Wed.. Thanks!


wanyen
__
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] Ironic design summit schedule

[Wan-yen Hsu]

Hi Jim,

   My techtalk is supposed to finish by 2:45pm.  However, techtalk schedule
is not as well monitored  as formal sessions so it could get delayed.
That's why I was exploring whether the group management session can be
switched to Thursday.  Thanks!

Wanyen

>>* Hi Jim, *> >* Is it possible to switch Group management session to
Thursday? I *
*>*>* have a techtalk at 2:30pm on Wednesday and it makes it very tight for
me *>* >>and Shiv to attend the group management at 2:50 pm. Since Shiv and
myself *>>* are the proposer for the group management session, we want to
be able to *>* attend this discussion. Thanks! *

>Your talk is 2:00-2:40, correct? The reason I scheduled it at 2:50 is
>because of this talk. The only other place I could put it is Thursday at
>11:00, however some operators expressed more interest in the driver API
>session, and they have Wednesday sessions going on.

>I'd prefer if you could just walk quickly (run?) between these two - if
>you think that is impossible I may be able to switch them. Let me know. :)

// 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-dev] [Ironic] Driver documentation in Ironic

[Wan-yen Hsu]

As mentioned in the weekly IRC, 3rd-party vendor drivers are ranked lower
priority and therefore their code tend to merge at the late cycle of a
release.   Therefore,  it leads little time for driver author to submit
document and for upstream to review and approve the document.  So, as the
result, the 3r-party driver document could miss the release.  I don't think
the suggestion of code+document  submission and review will help
either.  IMO it will slow down review process as reviewers will need to
review documents for every feature comparing to one single document review
after all features are landed.  Hence I am concerned that it will slow down
the review process and make landing vendor's driver code even harder unless
upstream is willing to raise priority for vendor driver specs and code.
 Also,  some features are inter-related and can introduce document
inter-dependency if feature and documentation are bundled.   Moreover,
currently it is very difficult (if possible) to modify document after it
got merged into a stable tree.   Like defect in code, defects in document
exist.  For instance, some important configuration steps or pre-requisites
may be missing in the document.  Sometimes new firmware version has impact
on vendor's drivers and it will require changes in driver's pre-requisites
or configuration in order to work with the new firmware versions.  These
will require document changes in the stable branch.  Therefore, there is a
need for vendor driver author to make changes in stable branch to fix
document defects, document known firmware issues and resolutions, and
update information about supported firmware versions and hardware.   IMO,
Ramesh's option 2  & 3 will provide this kind of flexibility.  Option1 will
help driver document to land in time tor a release but won't enable changes
to the stable branch unless upstream allow driver authors to
self-approve document changes in the stable branch.It would be my
preference, if PTL and upstream can work with infra to allow driver authors
to self-approve changes to the stable branch.   I am sincerely asking  for
help.  Any upstream effort to allow driver's document change in stable
branch and help driver document to land in new release in time will be very
much appreciated.
Thanks!

On Thu, Oct 15, 2015 at 09:23:18PM +0530, Ramakrishnan G wrote:
>* Hi All, *> >* This mail is related to driver-specific documentation in
Ironic. *> >* First a bit of context. I work on iLO drivers in Ironic. Our
team would *>* like to document both Ironic driver related stuff (which is
related to *>* Ironic) and hardware related stuff like tested platforms,
firmware *>* information, firmware issues, etc (which is not related to
Ironic) in the *>* documentation. Today we keep it at two places - ironic
related one in *>* ironic tree and (ironic + non-ironic) related one in
wiki. It's hard for *>* both people who work on documentation and people
who read this *>* documentation to update/refer information in two places.
Hence we decided *>* to raise the review [0] to move the content completely
to wiki. It got *>* mixed response. While some people are okay with it, but
some others *>* (including our ptl :)) feel it's worth putting it in-tree
and try to *>* address the problems. *> >* So what all are the problems ? *>*
1) Ability to update the driver documentation not-related to Ironic easily *
>* without waiting. *>* 2) To save some core reviewers time who might not
be familiar with the *>* hardware. *> >* To solve the actual problem of
updating the documentation easily while *>* keeping it in-tree, I checked
with infra folks if a subset of a repository *>* can be +2ed/+Aed by
another group. They confirmed it's not possible *>* (unless there was a
communication gap in that conversation, folks can *>* correct me if I am
wrong). *> >* The following are the options that I can think of to address
this: *> >* 1) Easy approvals for patches solely related to driver
documentation. Once *>* the driver team feels the documentation is ready,
it can be +Aed by a core *>* team member skipping the normal process of
review. Of course, fixing any *>* comments that come by, but not waiting
for the normal rule of 2x+2s. *> >* 2) A separate repository for driver
documentation controller by driver *>* developers (a bad idea ??) *> >* 3)
Allow to push driver documentation to wiki for those who wish to. *> >*
Thoughts ??? *
We talked about this in our IRC meeting as well, and there isn't really
a good answer for "allow driver authors to merge their own docs ASAP".

I'd like to see some examples of docs patches that: 1) took too long to
merge, and 2) what problems that caused.

// 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-dev] [ironic] Ironic design summit schedule

[Wan-yen Hsu]

Hi Jim,

Is it possible to switch Group management session  to Thursday?   I
have a techtalk at 2:30pm on Wednesday and it makes it very tight for me
and Shiv to attend the group management at 2:50 pm.  Since Shiv and myself
are the proposer for the group management session, we want to be able to
attend this discussion.  Thanks!

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

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

[Wan-yen Hsu]

 I fully agreed with Ramesh.  There is a need for driver owners to be able
to quickly update their driver’s document.  Particularly, vendor's drivers
have strong dependencies on their platform’s firmware.  For instance, a new
release of firmware may have impact on vendor’s driver and may require a
specific firmware settings or some workaround in driver configuration.
Therefore driver owners need to be able to update their driver documents to
reflect support of firmware versions or hardware platforms, document
firmware issues that have impacts to the drivers, …etc.   Also, as more and
more features added to the drivers and some features are related, sometimes
it requires restructuring of the document to make it easier for readers to
follow and understand.  I would very much like to get tech writers to help
my driver’s document but with current document review process and release
schedule, it’s just very hard to do.  As the result, document quality
suffers.  I really wish that we can give driver owner’s more control of
their documents and be able to update their driver documents when needed.



 Among all 3 options listed below, I prefer 2 or 3. Please consider these
options.



 Thanks!



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



>1) Easy approvals for patches solely related to driver documentation. Once

>the driver team feels the documentation is ready, it can be +Aed by a core

>team member skipping the normal process of review. Of course, fixing any

>comments that come by, but not waiting for the normal rule of 2x+2s.



>2) A separate repository for driver documentation controller by driver

>developers (a bad idea ??)



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



>Thoughts ???



>[0] https://review.openstack.org/#/c/225602/
__
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] [Horizon] [UX] Wireframes for

[Wan-yen Hsu]

Hi,  Jarda


We are already prepared for multiple drivers. If you look at the Driver

field, there is a dropdown menu from which you can choose a driver and

based on the selection the additional information (like IP, user, passw)

will be changed.



 So, if iLO + Virtual Media is chosen in the dropdown menu, Horizon node
managmement panel will display iLO Password and iLO user  instead of
IPMI user and IPMI Password?  This is great!





 Also, myself and a few folks are working on Ironic UEFI support and

 we hope to land this feature in Juno (Spec is still in review state but

 the feature is on the Ironic Juno Prioritized list). In order to add

 UEFI boot feature, a Supported Boot Modes field in the hardware info

 is needed.  The possible values are BIOS Only, UEFI Only, and

 BIOS+UEFI.   We will need to work with you to add this field onto

 hardware info.



There is no problem to accommodate this change in the UI once the

back-end supports it. So if there is a desire to expose the feature in

the UI, when there is already working back-end solution, feel free to

send a patch which adds that to the HW info - it's an easy addition and

the UI is prepared for such types of expansions.



 ok.  Thanks!







wanyen



Hi Wan,



thanks for great notes. My response is inline:



On 2014/15/07 23:19, Wan-yen Hsu wrote:

 The Register Nodes panel uses IPMI user and IPMI Password.

 However, not all Ironic drivers use IPMI, for instance, some Ironic

 drivers will use iLO or other BMC interfaces instead of IPMI.  I would

 like to suggest changing IPMI to BMC or IPMI/BMC to acomodate

 more Ironic drivers.  The Driver field will reflect what power

 management interface (e.g., IPMI + PXE, or iLO + Virtual Media) is used

 so it can be used to correlate the user and password fields.



We are already prepared for multiple drivers. If you look at the Driver

field, there is a dropdown menu from which you can choose a driver and

based on the selection the additional information (like IP, user, passw)

will be changed.



 Also, myself and a few folks are working on Ironic UEFI support and

 we hope to land this feature in Juno (Spec is still in review state but

 the feature is on the Ironic Juno Prioritized list). In order to add

 UEFI boot feature, a Supported Boot Modes field in the hardware info

 is needed.  The possible values are BIOS Only, UEFI Only, and

 BIOS+UEFI.   We will need to work with you to add this field onto

 hardware info.



There is no problem to accommodate this change in the UI once the

back-end supports it. So if there is a desire to expose the feature in

the UI, when there is already working back-end solution, feel free to

send a patch which adds that to the HW info - it's an easy addition and

the UI is prepared for such types of expansions.





 Thanks!



 wanyen



Cheers

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

Re: [openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node Management - Juno

[Wan-yen Hsu]

Hi Jaromir,


 Excerpts from Jaromir Coufal's message of 2014-07-09 07:51:56 +:

 Hey folks,



 after few rounds of reviews and feedbacks, I am sending wireframes,

 which are ready for implementation in Juno:




http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf





 Let me know in case of any questions.





   This looks great!  I have a couple comments-



The Register Nodes panel uses IPMI user and IPMI Password.  However,
not all Ironic drivers use IPMI, for instance, some Ironic drivers will use
iLO or other BMC interfaces instead of IPMI.  I would like to suggest
changing IPMI to BMC or IPMI/BMC to acomodate more Ironic drivers.
The Driver field will reflect what power management interface (e.g., IPMI
+ PXE, or iLO + Virtual Media) is used so it can be used to correlate the
user and password fields.



   Also, myself and a few folks are working on Ironic UEFI support and we
hope to land this feature in Juno (Spec is still in review state but the
feature is on the Ironic Juno Prioritized list).   In order to add UEFI
boot feature, a Supported Boot Modes field in the hardware info is
needed.  The possible values are BIOS Only, UEFI Only, and
BIOS+UEFI.   We will need to work with you to add this field onto
hardware info.



Thanks!



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

[Wan-yen Hsu]

Hi Devananda,

  I noticed that firmware update is not on the priority list.  I thought
there was strong interest in this capability.  The design spec of
out-of-band firmware update has been submitted
https://review.openstack.org/#/c/100842/.  We will address the review
comments and uplaod a new version soon.  Is it possible to add this item to
the Juno list?  Thanks!

Regards,
iron1

 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