| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-03 | |||
| 17:37:59 | cdent | elmiko: no, more general than that: get something published that is actionable | |
| 17:38:16 | elmiko | cdent: ok, cool. i thought we were in the weeds about that. | |
| 17:38:27 | cdent | ed pointed out a few more contradictions and issues in his comments shortly before my last one | |
| 17:38:29 | edleafe | I felt that the PTG was really a non-outcome, because we didn't have the two factions talking with each other | |
| 17:38:51 | elmiko | i agree with the sentiment that using these guidelines as the bar for a tag is problematic at best | |
| 17:39:23 | edleafe | elmiko: so how would the TC determine if a project has earned that tag? | |
| 17:39:49 | elmiko | edleafe: i guess it depends a little on the conversation here | |
| 17:39:51 | elmiko | like for example | |
| 17:40:11 | cdent | edleafe: I don't quite agree (about PTG). I think we established that there were some people who did not want to prioritize service wide interoperability and stability and that's okay, but that if you do, there are consequences | |
| 17:40:16 | elmiko | if the guidelines are about the mission and interop, then maybe we need a document that clearly defines what you need for the tag (ugh, more docs) | |
| 17:40:33 | elmiko | but, if the guidelines *are* about the tag, then we need to be more explicit i suppose | |
| 17:41:30 | elmiko | i have to admit, i feel we have gotten so far zoomed in as a result of one issue that i'm having trouble placing all this into the "bigger picture" as stated above | |
| 17:41:32 | edleafe | cdent: hence my blog post. The morning group was concerned with moving an API forward without breaking clients. They really showed no concern for interop at the level that Monty et al did in the afternoon | |
| 17:42:12 | cdent | edleafe: hence my suggestion of renaming this document to interoperability guidelines and being able to publish that as a step in a potentially multi-step process | |
| 17:42:34 | cdent | (elmiko, yes, it's hard to tell where to focus) | |
| 17:43:36 | elmiko | cdent: that seems like a sensible option to me | |
| 17:43:41 | edleafe | cdent: So this would be an "api-interoperability" guiddeline, and there would be another, similar "api-compatibility" guideline? Or just the former and forget about the latter? | |
| 17:44:29 | cdent | do the former, and if there is demand and/or time do the latter | |
| 17:45:26 | cdent | i'm not sure if there is demand for the latter, but there was clearly demand for the former because people we're wielding the older (incomplete) guideline as a weapon | |
| 17:45:59 | elmiko | ouch | |
| 17:46:13 | cdent | were | |
| 17:46:14 | edleafe | I think that the latter would be more widely useful OpenStack-wide in improving APIs | |
| 17:46:20 | cdent | because I know edleafe is watching out for such things | |
| 17:46:21 | elmiko | it's starting to sound like the tag should really be "api-interop" focused then? | |
| 17:46:27 | elmiko | edleafe: ++ | |
| 17:46:30 | edleafe | cdent: I let that one slide | |
| 17:47:12 | edleafe | Not many projects will implement microversions and be as strict about them as interop requires | |
| 17:47:24 | cdent | edleafe: how do you react to the assertion that forward stability/compatibility is impossible in the kind of environment that openstack projects exist in? | |
| 17:47:57 | cdent | or the other assertion, held by some, that if you're not concerning yourself with interop you shouldn't be openstack? | |
| 17:47:59 | edleafe | But I can see many projects improving their versioning (*cough* glance *cough*) to at least not break clients | |
| 17:48:15 | elmiko | lol | |
| 17:48:35 | cdent | how did microversions leak in here? | |
| 17:48:38 | edleafe | Impossible? No | |
| 17:48:45 | edleafe | Difficult? Sure | |
| 17:49:28 | edleafe | cdent: because we determined that no one knew of any versioning system that could meet the demands of interop besides microversions | |
| 17:49:30 | cdent | (is proxying assertions to cover bases, I've completely lost touch with my own position on this stuff) | |
| 17:49:47 | edleafe | And thus demanding interop means demanding microversions | |
| 17:49:56 | elmiko | cdent: i can totally empathize | |
| 17:50:31 | cdent | if glance improved their versioning, even if they didn't use microversions™ they would still be microversions if they were selectable in some fashion | |
| 17:51:09 | cdent | if you are doing some kind of versioning | |
| 17:51:24 | edleafe | They could adopt semver | |
| 17:51:35 | edleafe | (and stick to it!) | |
| 17:51:45 | sdague | edleafe: that's actually a pretty accurate replay of what happened, we invented this thing because all the existing strategies broke down when you were talking about multiple deployments that were upgrading at independent schedules | |
| 17:51:58 | cdent | and you can choose what version you want at request time (by uri, or header, content type) then you have the equivalent functionality of microversioning, and thus you have interop | |
| 17:52:00 | sdague | edleafe: I really don't think semver is meaningful for network based services | |
| 17:52:47 | cdent | brb | |
| 17:52:47 | sdague | because semver is what you use in libraries to know what you can safely upgrade to, and what you just vendor. But you can't vendor a network api. :) | |
| 17:53:52 | edleafe | sdague: the point was that there are other ways to sanely version your API other than microversions | |
| 17:54:13 | dtroyer | besides, semver is hard enough to get right that consumers can't always trust it anyway… which is why I've come to the conclusion that I don't care _what_ you use to signal a change, just make it have an order (because ranges) and discoverable | |
| 17:54:27 | edleafe | Some projects have a visceral reaction to even thinking of microversions | |
| 17:54:36 | edleafe | I don't understand that, but it's there | |
| 17:54:49 | dtroyer | because anti-Nova sentiment? | |
| 17:55:04 | edleafe | dtroyer: that's part of it | |
| 17:55:23 | edleafe | but also because it's perceived as this huge amount of overhead | |
| 17:55:43 | cdent | it's perceived as a way to keep tech debt in both client libraries and servers | |
| 17:55:57 | dtroyer | heh, the overhead is thinking about the consumers of your API rathern than just treating it as write-only | |
| 17:56:10 | cdent | for some that's a valid cost, for the sake of the user, for others not so much | |
| 17:56:25 | cdent | round-about-jinx | |
| 17:57:47 | edleafe | sdague summarized the users well in https://review.openstack.org/#/c/444892/2/guidelines/microversions-architecture.rst | |
| 17:58:09 | edleafe | It's hard to satisfy all those use cases | |
| 17:58:10 | sdague | yeh, I need to get back to that document | |
| 17:58:36 | sdague | edleafe: right, well, it is why we ended up with the microversion solution | |
| 17:58:45 | sdague | that was our set of constraints | |
| 17:58:50 | sdague | solve for X | |
| 17:59:03 | elmiko | edleafe: i think there is another angle to avoiding microversions. for teams that are stretched or have hard downstream asks, it can be a tough load of tech debt to take on. | |
| 17:59:22 | cdent | if the current document didn't have a) any mention of microversions, b) the alternatives section what would it mean or imply for people? Would it serve a useful purpose? | |
| 17:59:34 | edleafe | elmiko: can you explain what the tech debt is that is taken on? | |
| 18:00:13 | cdent | it's not even debt, it's work | |
| 18:00:33 | elmiko | edleafe: so, imo, initially someone has to implement the handling of the microversion into the wsgi framework. additionally that knowledge needs to be communicated in a manner that will live on if the implementor disappears. | |
| 18:00:54 | sdague | cdent: what I heard in the room, it was the debt that people were concerned about. They didn't want to maintain old behaviors. | |
| 18:01:03 | elmiko | after it's implemented, then there is the function of keeping the older pathways working while new bits are added | |
| 18:01:10 | sdague | right | |
| 18:01:10 | cdent | sdague: yeah, but that's not what elmiko is talking about here | |
| 18:01:16 | ZZelle | dtroyer, hi | |
| 18:01:20 | cdent | s/here/at first/ | |
| 18:01:28 | sdague | cdent: ok | |
| 18:01:50 | edleafe | elmiko: yeah, I get the initial workload to make the change, but really, any change requires work | |
| 18:01:55 | elmiko | as the old paths start to rot, i've experienced a brain-drain in the area of keeping them alive when bugs do creep in *or* if there needs to changes to the overall model of the application in question. | |
| 18:02:20 | elmiko | edleafe: agreed, i'm just airing my perceived drawbacks to a smaller team | |
| 18:02:34 | edleafe | So for a project that wants to maintain compatibility, they have to maintain the old behaviors in any event | |
| 18:02:34 | elmiko | my largest experience is with sahara | |
| 18:02:46 | sdague | elmiko: yeh, that's definitely a concern. But the real world implications of that are that a service is just going to stop working for existing clients. | |
| 18:03:12 | sdague | which, makes it a hard choice for people to choose to deploy and count on | |
| 18:03:19 | elmiko | sdague: agreed | |
| 18:03:43 | elmiko | bare in mind that i'm mainly talking about projects that may not be hot-beds of openstack activity. (for example sahara) | |
| 18:03:47 | edleafe | elmiko: re: bitrot - yeah, agreed. That's why I don't subscribe to the "once an API is released, you have to maintain it forever" school of thought | |
| 18:04:09 | edleafe | elmiko: see: https://blog.leafe.com/api-longevity/ | |
| 18:04:15 | sdague | edleafe: it mostly depends on who has control over the deployment | |
| 18:04:39 | sdague | so... if sahara wasn't a thing the cloud operator deployed, but a thing that I deployed in my tenant | |
| 18:04:48 | elmiko | if my, downstream, employer has hot demands on what goals they would like to see for a particular cycle, it can extremely difficult to get traction for spending signifcant time doing a microversion re-write | |
| 18:04:49 | sdague | then I've got control on the upgrade cycle | |
| 18:04:59 | sdague | which makes it like vendored libraries | |
| 18:05:07 | sdague | and, then I think some of these concerns go away | |
| 18:05:13 | elmiko | sdague: totally agree | |
| 18:05:21 | elmiko | in-tenant services is a fantastic idea | |
| 18:05:31 | sdague | but when the user has no control of the upgrade schedule | |
| 18:06:06 | sdague | ... I have a hard time understanding a different path then the one we've taken | |
| 18:06:21 | elmiko | i feel like this is an area where, due to no ones fault, there are "services" that are embedded into the control plane which would be better served as application riding on top of openshift | |
| 18:06:40 | elmiko | er, openstack | |
| 18:06:46 | elmiko | sorry.. too many open* | |