Re: [openstack-dev] [ironic] versioning of IPA, it is time or is it?

2016-06-09 Thread Loo, Ruby 
Thank you Sam and Dmitry for your thoughts. It will (most likely) be one of the 
topics of discussion at the mid-cycle [1]. The actual schedule hasn't been 
decided yet so stay tuned. Be there for a vigorating, heated, and fun time :)

--ruby

[1] https://etherpad.openstack.org/p/ironic-newton-midcycle

From: "Sam Betts (sambetts)" <sambe...@cisco.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, June 3, 2016 at 7:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] versioning of IPA, it is time or is it?

I personally think that we need IPA versioning, but not so that we can pin a 
version. We need versioning so that we can do more intelligent graceful 
degradation in Ironic without just watching for errors and guessing if a 
feature isn’t available. If we add a new feature in Ironic that requires a 
feature in IPA, then we should add code in Ironic that checks the version of 
IPA (either via an API or reported at lookup) and turns on/off that feature 
based on the version of IPA we’re talking to. Doing this would allow for both 
backwards and forward IPA version compatibility:

Old Ironic with newer IPA: Should just work
New Ironic with old IPA: Ironic should intelligently turn off unsupported 
features, with Warnings in the logs telling the operator if a feature is 
skipped.

Sam

From: Dmitry Tantsur <divius.ins...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 2 June 2016 22:03
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] versioning of IPA, it is time or is it?


2 июня 2016 г. 10:19 PM пользователь "Loo, Ruby" <ruby@intel.com> написал:
>
> Hi,
>
> I recently reviewed a patch [1] that is trying to address an issue with 
> ironic (master) talking to a ramdisk that has a mitaka IPA lurking around.
>
> It made me think that IPA may no longer be a teenager (yay, boo). IPA now has 
> a stable branch. I think it is time it grows up and acts responsibly. Ironic 
> needs to know which era of IPA it is talking to. Or conversely, does ironic 
> want to specify which microversion of IPA it wants to use? (Sorry, Dmitry, I 
> realize you are cringing.)
With versioning in place we'll have to fix one IPA version in ironic. Meaning, 
as soon as we introduce a new feature, we have to explicitly break 
compatibility with old ramdisk by requesting a version it does not support. 
Even if the feature itself is optional. Or we have to wait some long time 
before using new IPA features in ironic. I hate both options.
Well, or we can use some different versioning procedure :)
>
> Has anyone thought more than I have about this (i.e., more than 2ish minutes)?
>
> If the solution (whatever it is) is going to take a long time to implement, 
> is there anything we can do in the short term (ie, in this cycle)?
>
> --ruby
>
> [1] https://review.openstack.org/#/c/319183/
>
>
>
> __
> 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] versioning of IPA, it is time or is it?

2016-06-03 Thread Sam Betts (sambetts) 
I personally think that we need IPA versioning, but not so that we can pin a 
version. We need versioning so that we can do more intelligent graceful 
degradation in Ironic without just watching for errors and guessing if a 
feature isn’t available. If we add a new feature in Ironic that requires a 
feature in IPA, then we should add code in Ironic that checks the version of 
IPA (either via an API or reported at lookup) and turns on/off that feature 
based on the version of IPA we’re talking to. Doing this would allow for both 
backwards and forward IPA version compatibility:

Old Ironic with newer IPA: Should just work
New Ironic with old IPA: Ironic should intelligently turn off unsupported 
features, with Warnings in the logs telling the operator if a feature is 
skipped.

Sam

From: Dmitry Tantsur <divius.ins...@gmail.com<mailto:divius.ins...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 2 June 2016 22:03
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] versioning of IPA, it is time or is it?


2 июня 2016 г. 10:19 PM пользователь "Loo, Ruby" 
<ruby@intel.com<mailto:ruby@intel.com>> написал:
>
> Hi,
>
> I recently reviewed a patch [1] that is trying to address an issue with 
> ironic (master) talking to a ramdisk that has a mitaka IPA lurking around.
>
> It made me think that IPA may no longer be a teenager (yay, boo). IPA now has 
> a stable branch. I think it is time it grows up and acts responsibly. Ironic 
> needs to know which era of IPA it is talking to. Or conversely, does ironic 
> want to specify which microversion of IPA it wants to use? (Sorry, Dmitry, I 
> realize you are cringing.)

With versioning in place we'll have to fix one IPA version in ironic. Meaning, 
as soon as we introduce a new feature, we have to explicitly break 
compatibility with old ramdisk by requesting a version it does not support. 
Even if the feature itself is optional. Or we have to wait some long time 
before using new IPA features in ironic. I hate both options.

Well, or we can use some different versioning procedure :)

>
> Has anyone thought more than I have about this (i.e., more than 2ish minutes)?
>
> If the solution (whatever it is) is going to take a long time to implement, 
> is there anything we can do in the short term (ie, in this cycle)?
>
> --ruby
>
> [1] https://review.openstack.org/#/c/319183/
>
>
>
> __
> 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
__
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] versioning of IPA, it is time or is it?

2016-06-02 Thread Dmitry Tantsur 
2 июня 2016 г. 10:19 PM пользователь "Loo, Ruby" 
написал:
>
> Hi,
>
> I recently reviewed a patch [1] that is trying to address an issue with
ironic (master) talking to a ramdisk that has a mitaka IPA lurking around.
>
> It made me think that IPA may no longer be a teenager (yay, boo). IPA now
has a stable branch. I think it is time it grows up and acts responsibly.
Ironic needs to know which era of IPA it is talking to. Or conversely, does
ironic want to specify which microversion of IPA it wants to use? (Sorry,
Dmitry, I realize you are cringing.)

With versioning in place we'll have to fix one IPA version in ironic.
Meaning, as soon as we introduce a new feature, we have to explicitly break
compatibility with old ramdisk by requesting a version it does not support.
Even if the feature itself is optional. Or we have to wait some long time
before using new IPA features in ironic. I hate both options.

Well, or we can use some different versioning procedure :)

>
> Has anyone thought more than I have about this (i.e., more than 2ish
minutes)?
>
> If the solution (whatever it is) is going to take a long time to
implement, is there anything we can do in the short term (ie, in this
cycle)?
>
> --ruby
>
> [1] https://review.openstack.org/#/c/319183/
>
>
>
> __
> 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] versioning of IPA, it is time or is it?

2016-06-02 Thread Loo, Ruby 
Hi,

I recently reviewed a patch [1] that is trying to address an issue with ironic 
(master) talking to a ramdisk that has a mitaka IPA lurking around.

It made me think that IPA may no longer be a teenager (yay, boo). IPA now has a 
stable branch. I think it is time it grows up and acts responsibly. Ironic 
needs to know which era of IPA it is talking to. Or conversely, does ironic 
want to specify which microversion of IPA it wants to use? (Sorry, Dmitry, I 
realize you are cringing.)

Has anyone thought more than I have about this (i.e., more than 2ish minutes)?

If the solution (whatever it is) is going to take a long time to implement, is 
there anything we can do in the short term (ie, in this cycle)?

--ruby 

[1] https://review.openstack.org/#/c/319183/



__
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