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
