Re: [openstack-dev] On an API proxy from baremetal to ironic
We manage a fairly large nova-baremetal installation at Yahoo. And while we've developed tools to hit the nova-bm API, we're planning to move to ironic without any support for the nova BM API. Definitely no interest in the proxy API from our end. Sometimes you just need to let a thing die. -James :)= On Wednesday, September 10, 2014 12:51 PM, Ben Nemec wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2014 02:26 PM, Dan Smith wrote: >> 1) Is this tested anywhere? There are no unit tests in the patch >> and it's not clear to me that there would be any Tempest coverage >> of this code path. Providing this and having it break a couple >> of months down the line seems worse than not providing it at all. >> This is obviously fixable though. > > AFAIK, baremetal doesn't have any tempest-level testing at all > anyway. However, I don't think our proxy code breaks, like, ever. I > expect that unit tests for this stuff is plenty sufficient. Right, but this would actually be running against Ironic, which does have Tempest testing. It might require some client changes to be able to hit a Baremetal API instead of Ironic though. > >> 2) If we think maintaining compatibility for existing users is >> that important, why aren't we proxying everything? Is it too >> difficult/impossible due to the differences between Baremetal >> and Ironic? And if they're that different, does it still make >> sense to allow one to look like the other? As it stands, this >> isn't going to let deployers use their existing tools without >> modification anyway. > > Ideally we'd proxy everything, based on our current API > guarantees. However, I think the compromise of just the show/index > stuff came about because it would be extremely easy to do, provide > some measure of continuity, and provide us a way to return > something nicer for the create/update operations than a 500. It > seemed like a completely fair and practical balance. Fair enough. I'm still not crazy about it, but since it already exists and you say these interfaces don't require much maintenance I guess that takes care of my major concerns. - -Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEKsAAAoJEDehGd0Fy7uqM3YIAKaqJPCwyS1l3NoKhj7qmGlT wqdPspI2LyVgnHY62iq73O6FSpmEp0JzEcuBxHi21gK3tIBrvRr+mOsNtGNoj7Of 84YmcFyWgBR75rRDSLLnVu7rs1LJ0jpGwVzWDi/vmzVoxWdNXwSx223mQTwi9gJ3 n+Rgf0HYOKUwGgDVDpyWFv1DUBo/Hgc3ZdG8pzwnEqONN0bmRlBQMZRJrl2+8Jvj zTYxDmunWp8FbTdKE80JcQ1YQYjmg4anCzaH0MEwax+j6lxu8MwEtM61ISJ7vV3L KqTSW2OrjtqKY/9oHSnKiBuD9RInyWhML6pq8jsniadPw+TOatJ4PZaCyTS9XvI= =cSmK -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2014 02:26 PM, Dan Smith wrote: >> 1) Is this tested anywhere? There are no unit tests in the patch >> and it's not clear to me that there would be any Tempest coverage >> of this code path. Providing this and having it break a couple >> of months down the line seems worse than not providing it at all. >> This is obviously fixable though. > > AFAIK, baremetal doesn't have any tempest-level testing at all > anyway. However, I don't think our proxy code breaks, like, ever. I > expect that unit tests for this stuff is plenty sufficient. Right, but this would actually be running against Ironic, which does have Tempest testing. It might require some client changes to be able to hit a Baremetal API instead of Ironic though. > >> 2) If we think maintaining compatibility for existing users is >> that important, why aren't we proxying everything? Is it too >> difficult/impossible due to the differences between Baremetal >> and Ironic? And if they're that different, does it still make >> sense to allow one to look like the other? As it stands, this >> isn't going to let deployers use their existing tools without >> modification anyway. > > Ideally we'd proxy everything, based on our current API > guarantees. However, I think the compromise of just the show/index > stuff came about because it would be extremely easy to do, provide > some measure of continuity, and provide us a way to return > something nicer for the create/update operations than a 500. It > seemed like a completely fair and practical balance. Fair enough. I'm still not crazy about it, but since it already exists and you say these interfaces don't require much maintenance I guess that takes care of my major concerns. - -Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEKsAAAoJEDehGd0Fy7uqM3YIAKaqJPCwyS1l3NoKhj7qmGlT wqdPspI2LyVgnHY62iq73O6FSpmEp0JzEcuBxHi21gK3tIBrvRr+mOsNtGNoj7Of 84YmcFyWgBR75rRDSLLnVu7rs1LJ0jpGwVzWDi/vmzVoxWdNXwSx223mQTwi9gJ3 n+Rgf0HYOKUwGgDVDpyWFv1DUBo/Hgc3ZdG8pzwnEqONN0bmRlBQMZRJrl2+8Jvj zTYxDmunWp8FbTdKE80JcQ1YQYjmg4anCzaH0MEwax+j6lxu8MwEtM61ISJ7vV3L KqTSW2OrjtqKY/9oHSnKiBuD9RInyWhML6pq8jsniadPw+TOatJ4PZaCyTS9XvI= =cSmK -END PGP SIGNATURE- ___ 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
On 09/10/2014 03:14 PM, Ben Nemec wrote: > On 09/10/2014 01:13 PM, Dan Smith wrote: >>> As far as I understand it, though, that's a patch for a >>> read-only mode. It seems bizzare, and possibly dangerous, to >>> proxy read commands, but not write commands. It gives the >>> impression that everything's fine until it's not fine (because >>> someone tried to use an existing script to do a create command). >>> IMHO, it would be better to just tell people up front "Update >>> your scripts to use Ironic, because they won't work at all" >>> instead of leading people (through empirical evidence) to believe >>> that their scripts will work, and then having them discover later >>> that something broke because they tried to create a node. > >> How is it dangerous? Most code making "write commands" would need >> to be pretty diligent about making sure that the thing being >> requested actually succeeded. Having the proxy allows us to return >> a reasonable code for those things (i.e. 403 Forbidden, perhaps) >> instead of just "500 Huh? What?". > >> I was pro-proxy from the beginning, not because I think proxies >> are awesome, but because that's what we do when we move things out >> of Nova's API to other services. Some feel this is a purely admin >> API and that gives us license to break our own rules here, but I >> don't really understand where, when and why we draw that line. The >> code is written, it's minor, and it gives a much more graceful >> response to the move. We know there are people running this, with >> clusters in the thousands. We don't know who they all are, what >> they're doing with it, and we don't know that all of them are happy >> or expecting to immediately rewrite all of their tools. I don't >> really see why this is a big deal. > > I wasn't aware that this was already written when I replied > originally, and that fact does reduce my opposition somewhat. I still > have issues though: > > 1) Is this tested anywhere? There are no unit tests in the patch and > it's not clear to me that there would be any Tempest coverage of this > code path. Providing this and having it break a couple of months down > the line seems worse than not providing it at all. This is obviously > fixable though. > > 2) If we think maintaining compatibility for existing users is that > important, why aren't we proxying everything? Is it too > difficult/impossible due to the differences between Baremetal and > Ironic? And if they're that different, does it still make sense to > allow one to look like the other? As it stands, this isn't going to > let deployers use their existing tools without modification anyway. Because the world isn't black and white. The ready only proxy probably covers a bunch of cases, and is easy. The write proxy is much more time, and unclear that it would be semantically equivalent enough to be useful to anyone. So this is an 80/20 rule piece of code. And as it's already done, lets do it. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ 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
> 1) Is this tested anywhere? There are no unit tests in the patch and > it's not clear to me that there would be any Tempest coverage of this > code path. Providing this and having it break a couple of months down > the line seems worse than not providing it at all. This is obviously > fixable though. AFAIK, baremetal doesn't have any tempest-level testing at all anyway. However, I don't think our proxy code breaks, like, ever. I expect that unit tests for this stuff is plenty sufficient. > 2) If we think maintaining compatibility for existing users is that > important, why aren't we proxying everything? Is it too > difficult/impossible due to the differences between Baremetal and > Ironic? And if they're that different, does it still make sense to > allow one to look like the other? As it stands, this isn't going to > let deployers use their existing tools without modification anyway. Ideally we'd proxy everything, based on our current API guarantees. However, I think the compromise of just the show/index stuff came about because it would be extremely easy to do, provide some measure of continuity, and provide us a way to return something nicer for the create/update operations than a 500. It seemed like a completely fair and practical balance. --Dan signature.asc Description: OpenPGP digital signature ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2014 01:13 PM, Dan Smith wrote: >> As far as I understand it, though, that's a patch for a >> read-only mode. It seems bizzare, and possibly dangerous, to >> proxy read commands, but not write commands. It gives the >> impression that everything's fine until it's not fine (because >> someone tried to use an existing script to do a create command). >> IMHO, it would be better to just tell people up front "Update >> your scripts to use Ironic, because they won't work at all" >> instead of leading people (through empirical evidence) to believe >> that their scripts will work, and then having them discover later >> that something broke because they tried to create a node. > > How is it dangerous? Most code making "write commands" would need > to be pretty diligent about making sure that the thing being > requested actually succeeded. Having the proxy allows us to return > a reasonable code for those things (i.e. 403 Forbidden, perhaps) > instead of just "500 Huh? What?". > > I was pro-proxy from the beginning, not because I think proxies > are awesome, but because that's what we do when we move things out > of Nova's API to other services. Some feel this is a purely admin > API and that gives us license to break our own rules here, but I > don't really understand where, when and why we draw that line. The > code is written, it's minor, and it gives a much more graceful > response to the move. We know there are people running this, with > clusters in the thousands. We don't know who they all are, what > they're doing with it, and we don't know that all of them are happy > or expecting to immediately rewrite all of their tools. I don't > really see why this is a big deal. I wasn't aware that this was already written when I replied originally, and that fact does reduce my opposition somewhat. I still have issues though: 1) Is this tested anywhere? There are no unit tests in the patch and it's not clear to me that there would be any Tempest coverage of this code path. Providing this and having it break a couple of months down the line seems worse than not providing it at all. This is obviously fixable though. 2) If we think maintaining compatibility for existing users is that important, why aren't we proxying everything? Is it too difficult/impossible due to the differences between Baremetal and Ironic? And if they're that different, does it still make sense to allow one to look like the other? As it stands, this isn't going to let deployers use their existing tools without modification anyway. - -Ben > > --Dan > > > > ___ OpenStack-dev > mailing list OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEKMKAAoJEDehGd0Fy7uqzNsH+gPv45+IKWJEVeQK4/bd5KAa SjUch6kmTaWkHxMCcIrm3E9bug0zU/64jhtlJuLWfDohqK4I3NRnaY7Ur5R6aEx7 QsXa74LS+cl2n8ydcVAGtmTYzRyLfF+Qvocu8pUZ3ZP+d4A73lkX09B3s07hwY02 e87blL9E6/T9/4ni+186RDrMEnD8TIY3oD4cnbAgib9tVNBMitqlGuFGqdp7gRDW q0GMzh2bmbQRTE2OpEtSbjsVm+qeVsbVACg+bsM/y62ZT3TTO5NyqbYZPJJfDDy4 ys4rbJT6fDZLz2L5G835jAHMwUc54vLdXAz/blo/TsI1LCiJTHvIaWLdgsMSqAY= =vcMK -END PGP SIGNATURE- ___ 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
> As far as I understand it, though, that's a patch for a read-only > mode. It seems bizzare, and possibly dangerous, to proxy read > commands, but not write commands. It gives the impression that > everything's fine until it's not fine (because someone tried to use > an existing script to do a create command). IMHO, it would be better > to just tell people up front "Update your scripts to use Ironic, > because they won't work at all" instead of leading people (through > empirical evidence) to believe that their scripts will work, and then > having them discover later that something broke because they tried to > create a node. How is it dangerous? Most code making "write commands" would need to be pretty diligent about making sure that the thing being requested actually succeeded. Having the proxy allows us to return a reasonable code for those things (i.e. 403 Forbidden, perhaps) instead of just "500 Huh? What?". I was pro-proxy from the beginning, not because I think proxies are awesome, but because that's what we do when we move things out of Nova's API to other services. Some feel this is a purely admin API and that gives us license to break our own rules here, but I don't really understand where, when and why we draw that line. The code is written, it's minor, and it gives a much more graceful response to the move. We know there are people running this, with clusters in the thousands. We don't know who they all are, what they're doing with it, and we don't know that all of them are happy or expecting to immediately rewrite all of their tools. I don't really see why this is a big deal. --Dan signature.asc Description: OpenPGP digital signature ___ 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
I don't get that logic at all. Proxying the read commands means that monitoring or report scripts will work fine. Actual state transition scripts, which can't really work correctly, as there are too many differences, won't. -Sean On 09/10/2014 12:57 PM, Solly Ross wrote: > As far as I understand it, though, that's a patch for a read-only mode. It > seems bizzare, and possibly dangerous, to proxy read commands, but not write > commands. It gives the impression that everything's fine until it's not fine > (because someone tried to use an existing script to do a create command). > IMHO, it would be better to just tell people up front "Update your scripts to > use Ironic, because they won't work at all" instead of leading people > (through empirical evidence) to believe that their scripts will work, and > then having them discover later that something broke because they tried to > create a node. > > Best Regards, > Solly Ross > > - Original Message - >> From: "Sean Dague" >> To: openstack-dev@lists.openstack.org >> Sent: Wednesday, September 10, 2014 10:33:05 AM >> Subject: Re: [openstack-dev] On an API proxy from baremetal to ironic >> >> 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 > -- Sean Dague http://dague.net ___ 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
As far as I understand it, though, that's a patch for a read-only mode. It seems bizzare, and possibly dangerous, to proxy read commands, but not write commands. It gives the impression that everything's fine until it's not fine (because someone tried to use an existing script to do a create command). IMHO, it would be better to just tell people up front "Update your scripts to use Ironic, because they won't work at all" instead of leading people (through empirical evidence) to believe that their scripts will work, and then having them discover later that something broke because they tried to create a node. Best Regards, Solly Ross - Original Message - > From: "Sean Dague" > To: openstack-dev@lists.openstack.org > Sent: Wednesday, September 10, 2014 10:33:05 AM > Subject: Re: [openstack-dev] On an API proxy from baremetal to ironic > > 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] On an API proxy from baremetal to ironic
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] On an API proxy from baremetal to ironic
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
Re: [openstack-dev] On an API proxy from baremetal to ironic
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. -- Russell Bryant ___ 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
On 09/09/2014 04: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. nova-baremetal is, and has been for a while, a dead end. That shouldn't be a surprise to anyone who cares about it at this point. By rights it should have been ripped out a while ago since it's never met the hypervisor requirements Nova enforces on everyone else. Spending additional effort on a partial compatibility layer for it seems like a complete waste of time to me. In addition, if we _do_ add a proxy then we're committing to supporting that going forward, and frankly I think we've got better things to spend our time on. Unless we're planning to add it and immediately deprecate it so we can remove it (and baremetal?) next cycle. Which seems like a silly thing to do. :-) I mean, even assuming we did this, what's the real benefit? If you switch to Ironic without updating your tools, you've just made your entire infrastructure read-only. Nobody's actually going to do that, are they? And if they are, do they care that much about being able to view their node list/details? What are they going to do with that information? Can they even trust that the information is correct? How are we going to test this proxy when we don't test baremetal to any meaningful degree today? So yeah, -1 from me to a proxy that's at best a half-measure anyway. Let's just put baremetal to rest already. -Ben > > Thanks, > Michael > ___ 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
On Wed, Sep 10, 2014 at 7:43 AM, Solly Ross wrote: > With my admittedly limited knowledge of the whole Ironic process, the > question seems to me to be: "If we don't implement a proxy, which people are > going to have a serious problem?" > > Do we have an data on which users/operators are making use of the baremetal > API in any extensive fashion? If nobody's using it, or the people using it > aren't using in an > extensive fashion, I think we don't need to make a proxy for it. > Strengthening this > argument is the fact that we would only be proxying the first two calls, so > it wouldn't > be a drop-in replacement anyway. You make a fair point, and this is something we've struggled for during the Ironic driver implementation. We _know_ that baremetal works (I know of at least one 1,000 node deployment), but we _don't_ know how widely its deployed and we don't have a good way to find out. So, I think we're left assuming that people do use it, and acting accordingly. Then again, is it ok to assume admins can tweak their code to use the ironic API? I suspect it is, because the number of admins is small... Michael -- Rackspace Australia ___ 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
With my admittedly limited knowledge of the whole Ironic process, the question seems to me to be: "If we don't implement a proxy, which people are going to have a serious problem?" Do we have an data on which users/operators are making use of the baremetal API in any extensive fashion? If nobody's using it, or the people using it aren't using in an extensive fashion, I think we don't need to make a proxy for it. Strengthening this argument is the fact that we would only be proxying the first two calls, so it wouldn't be a drop-in replacement anyway. Best Regards, Solly Ross - Original Message - > From: "Michael Still" > To: "OpenStack Development Mailing List" > Sent: Tuesday, September 9, 2014 5:24:11 PM > Subject: [openstack-dev] On an API proxy from baremetal to ironic > > 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. > > Thanks, > Michael > > -- > Rackspace Australia > > ___ > 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] On an API proxy from baremetal to ironic
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. Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
