dims · May 29, 2015 14:15
diff --git a/gistfile1.txt b/gistfile1.txt
 IRC Chat on #openstack-nova on 2015/05/06

 06:38 alex_xu: sdague: dims one more case for change search option https://review.openstack.org/#/c/171523/ ... hope we can got agreement on this guideline https://review.openstack.org/177778
 06:39 dims: alex_xu: same deal as the other one - works for admin and does not work for others?
 06:41 alex_xu: dims: yes as I remember. the patch add on more option at https://review.openstack.org/#/c/171523/1/nova/api/openstack/compute/plugins/v3/servers.py
 06:44 sdague: dims: the *whole* point of microversions was that it gave us a reliable way to signal API changes
 06:44 sdague: instead of the old way which is randomly changing stuff... assuming "meh, no one really cares about this one" and creating a compatibility mess in the ecosystem
 06:45 sdague: and yes, that's going to give us a lot of microversions, and yes that's going to mean a bunch of compat code, but that's the cost of a versioned interface
 06:46 sdague: we do it in db migrations, library releases, rpc version bumps... I'm not sure why it's all of a sudden a huge deal that we're going to do it with the API
 06:50 dims: sdague: of course its the core(s) call not mine. the distinction i made in my head was that the default should work right for both classes of users hence a bug and not a feature
 06:50 sdague: dims: except... it was explicitly decided not to be part of the interface in the past
 06:50 sdague: so the problem is if you just "change as bug fix"
 06:51 sdague: then you get people saying "oh, this is the interface" and hard code the filter into their code
 06:51 sdague: then try to get their stuff to work on hpcloud and rax at the same time
 06:51 sdague: and it gives wildly different results
 06:52 dims: sdague: fair point, i wanted everyone to reap the benefits and not just some folks who know which specific microversion they need
 06:52 sdague: dims: but everyone doesn't reap the benefits
 06:52 sdague: there are deployed clouds without this code
 06:53 sdague: and there is *no* way for a user to know if this is going to work with the cloud they just signed up with
 06:54 sdague: which means the feature just became something they *can't* use in their code, because there is no ability to depend on it
 06:54 dims: sdague: if they wanted all servers, they would not be passing in ipv6 parameter...
 06:54 sdague: so now they have to write their own massive compat layer
 06:54 sdague: dims: that's not the case I'm talking about
 06:54 sdague: user reads the docs, I can filter by ipv6 param
 06:54 sdague: great
 06:54 dims: sorry that was the one frickler pointed to
 06:54 sdague: ok, hard code application to use that
 06:55 sdague: and I know that because ipv6 addresses are uniq, I can just grab the first server from the list
 06:55 sdague: now I run this against multiple clouds
 06:55 sdague: some that have this code
 06:55 sdague: and some that don't
 06:55 sdague: and with the ones that don't... you know what that code returns?
 06:56 sdague: *not* the server I was looking for
 06:56 sdague: so it's actually 100% wrong
 06:56 sdague: and now I realize I can never depend on this feature because I have 0 idea if it's ever going to work
 06:56 sdague: so I have to rewrite it as client side code instead
 06:57 dims: right, so they traverse the response and do a match
 06:57 dims: which will still work with this change
 06:57 sdague: but what you've just told me is we're going to tell people that "this filter is known to not work, you also have to client side filter"
 06:58 sdague: the whole point of the filter is to *only* return results that match
 06:58 sdague: it's like if 'ls *.doc' returns all documents
 06:58 sdague: oh, you actually want just .doc, 'ls *.doc | grep .doc'
 07:00 dims: sdague: when would we roll up microversions into default behavior?
 07:00 dims: do we ever?
 07:01 sdague: the spec allows for bringing up the minimum
 07:01 sdague: but the fact is, there are tons of applications out there
 07:01 sdague: and hopefully lots more in the future
 07:02 sdague: and the price of an application ecosystem is once you let an API into the wild, you can't change it
 07:04 sdague: which is why EC2 still supports requests in the original format for when the service went live 9 years ago
 07:04 dims: sdague: "you let an API into the wild, you can't change it, even when it is wrong" :(
 07:04 sdague: dims: people come to depend on that behavior
 07:04 dims: sdague: right
 07:04 sdague: now we have a mechanism for improving it for the future
 07:05 sdague: while not breaking people in the present
 07:05 sdague: which was the whole point
 07:05 sdague: then they get to migrate their code on their timeframe
 07:05 sdague: "oh... this end point is going to return differently, cool, I can adapt to that, and make my code be explicit about it"
 07:08 dims: sdague: ack. thanks for walking me through it. let me check if we currently let someone can enumerate microversions rather than just fail if that's not present.
 07:09 sdague: dims: I also think that we probably need more of this kind of "why" baked into the api-wg for stuff like this, because I think walking through the rationale is very helpful. Otherwise anyone that wants to write a multi openstack cloud app needs to write their own compat layer (aka shade)
	IRC Chat on #openstack-nova on 2015/05/06

	06:38 alex_xu: sdague: dims one more case for change search option https://review.openstack.org/#/c/171523/ ... hope we can got agreement on this guideline https://review.openstack.org/177778
	06:39 dims: alex_xu: same deal as the other one - works for admin and does not work for others?
	06:41 alex_xu: dims: yes as I remember. the patch add on more option at https://review.openstack.org/#/c/171523/1/nova/api/openstack/compute/plugins/v3/servers.py
	06:44 sdague: dims: the whole point of microversions was that it gave us a reliable way to signal API changes
	06:44 sdague: instead of the old way which is randomly changing stuff... assuming "meh, no one really cares about this one" and creating a compatibility mess in the ecosystem
	06:45 sdague: and yes, that's going to give us a lot of microversions, and yes that's going to mean a bunch of compat code, but that's the cost of a versioned interface
	06:46 sdague: we do it in db migrations, library releases, rpc version bumps... I'm not sure why it's all of a sudden a huge deal that we're going to do it with the API
	06:50 dims: sdague: of course its the core(s) call not mine. the distinction i made in my head was that the default should work right for both classes of users hence a bug and not a feature
	06:50 sdague: dims: except... it was explicitly decided not to be part of the interface in the past
	06:50 sdague: so the problem is if you just "change as bug fix"
	06:51 sdague: then you get people saying "oh, this is the interface" and hard code the filter into their code
	06:51 sdague: then try to get their stuff to work on hpcloud and rax at the same time
	06:51 sdague: and it gives wildly different results
	06:52 dims: sdague: fair point, i wanted everyone to reap the benefits and not just some folks who know which specific microversion they need
	06:52 sdague: dims: but everyone doesn't reap the benefits
	06:52 sdague: there are deployed clouds without this code
	06:53 sdague: and there is no way for a user to know if this is going to work with the cloud they just signed up with
	06:54 sdague: which means the feature just became something they can't use in their code, because there is no ability to depend on it
	06:54 dims: sdague: if they wanted all servers, they would not be passing in ipv6 parameter...
	06:54 sdague: so now they have to write their own massive compat layer
	06:54 sdague: dims: that's not the case I'm talking about
	06:54 sdague: user reads the docs, I can filter by ipv6 param
	06:54 sdague: great
	06:54 dims: sorry that was the one frickler pointed to
	06:54 sdague: ok, hard code application to use that
	06:55 sdague: and I know that because ipv6 addresses are uniq, I can just grab the first server from the list
	06:55 sdague: now I run this against multiple clouds
	06:55 sdague: some that have this code
	06:55 sdague: and some that don't
	06:55 sdague: and with the ones that don't... you know what that code returns?
	06:56 sdague: not the server I was looking for
	06:56 sdague: so it's actually 100% wrong
	06:56 sdague: and now I realize I can never depend on this feature because I have 0 idea if it's ever going to work
	06:56 sdague: so I have to rewrite it as client side code instead
	06:57 dims: right, so they traverse the response and do a match
	06:57 dims: which will still work with this change
	06:57 sdague: but what you've just told me is we're going to tell people that "this filter is known to not work, you also have to client side filter"
	06:58 sdague: the whole point of the filter is to only return results that match
	06:58 sdague: it's like if 'ls *.doc' returns all documents
	06:58 sdague: oh, you actually want just .doc, 'ls *.doc \| grep .doc'
	07:00 dims: sdague: when would we roll up microversions into default behavior?
	07:00 dims: do we ever?
	07:01 sdague: the spec allows for bringing up the minimum
	07:01 sdague: but the fact is, there are tons of applications out there
	07:01 sdague: and hopefully lots more in the future
	07:02 sdague: and the price of an application ecosystem is once you let an API into the wild, you can't change it
	07:04 sdague: which is why EC2 still supports requests in the original format for when the service went live 9 years ago
	07:04 dims: sdague: "you let an API into the wild, you can't change it, even when it is wrong" :(
	07:04 sdague: dims: people come to depend on that behavior
	07:04 dims: sdague: right
	07:04 sdague: now we have a mechanism for improving it for the future
	07:05 sdague: while not breaking people in the present
	07:05 sdague: which was the whole point
	07:05 sdague: then they get to migrate their code on their timeframe
	07:05 sdague: "oh... this end point is going to return differently, cool, I can adapt to that, and make my code be explicit about it"
	07:08 dims: sdague: ack. thanks for walking me through it. let me check if we currently let someone can enumerate microversions rather than just fail if that's not present.
	07:09 sdague: dims: I also think that we probably need more of this kind of "why" baked into the api-wg for stuff like this, because I think walking through the rationale is very helpful. Otherwise anyone that wants to write a multi openstack cloud app needs to write their own compat layer (aka shade)
No results found