Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-03
14:38:38 reedip hey hi , small issue with unicode in the functional test of https://review.openstack.org/356263
14:40:41 reedip sindhu : the unset command fails to find the dict in the list of dicts in https://review.openstack.org/#/c/356263/23/openstackclient/network/v2/port.py L#987
14:41:28 reedip cant think straight as of now, if you have some time to day, would be great if you can tell me how to ignore the unicodes
14:41:46 reedip unicode mismatch is the only issue, the items are in the correct value
14:42:01 sindhu reedip: cool, will look into it today :)
14:42:17 reedip gr8 thanks :)
14:58:12 ankur-gupta-f4 reedip: good evening
15:05:36 reedip ankur-gupta-f4 : hello
15:23:21 openstackgerrit Reedip proposed openstack/python-openstackclient master: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263
15:23:43 reedip sindhu : also need to get this merged so that the floating IP merges https://review.openstack.org/447938
15:25:05 sindhu reedip: yes, the change in SDK won't help us now like u mentioned
15:25:29 reedip yeah , so thats why want this to be merged so that the floating ip change merges soon
15:27:09 sindhu yeah, I agree :)
15:44:35 openstackgerrit Stephen Finucane proposed openstack/cliff master: WIP: Add 'cliff' Sphinx directive https://review.openstack.org/450322
16:02:26 openstackgerrit Ed Leafe proposed openstack/api-wg master: Recommend the correct HTTP method for tags https://review.openstack.org/451536
16:17:35 openstackgerrit Merged openstack/cliff master: .gitignore: Ignore eggs https://review.openstack.org/449740
16:23:30 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-command' Sphinx directive https://review.openstack.org/450322
16:31:57 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Add help commands withouth auth in functional https://review.openstack.org/452407
16:46:52 openstackgerrit Merged openstack/os-client-config master: Docs: add a note about rackspace API keys https://review.openstack.org/451563
16:47:19 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce L7Rule for Octavia (load balancing) https://review.openstack.org/452832
16:53:00 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce L7Rule for Octavia (load balancing) https://review.openstack.org/452832
17:02:07 openstackgerrit Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce neutron flavor associate, disassociate to OSC https://review.openstack.org/403907
17:06:11 openstackgerrit Ankur proposed openstack/python-openstacksdk master: Introduce Base for Octavia (load balancing) https://review.openstack.org/428414
17:06:28 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-command' Sphinx directive https://review.openstack.org/450322
17:12:02 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: WIP! Start using 'cliff.sphinxext' https://review.openstack.org/452861
17:25:18 cdent edleafe, elmiko : I'm cogitating on how to provide a final revision on https://review.openstack.org/#/c/421846/ (compatibility guidelines). I think I may do what I say in my last comment about "one tactic". Any thoughts?
17:25:35 openstackgerrit Ankur proposed openstack/python-openstackclient master: Network L3 Router Commands for OSC https://review.openstack.org/385729
17:29:13 edleafe cdent: I thought the motivation for this *was* the TC tag
17:29:56 cdent the motivation was that they wanted to use the guidelines and they seemed bad
17:30:09 cdent but now that they are revised we should revise them so they are not about tags, but about the bigger thing, the mission
17:30:23 cdent thus my statement: interoperability right there in the mission
17:31:38 cdent if we guide to the mission, the relevancy for tags (or new tags) falls out of that, but the tags will be mission oriented, not "make some tags to deal with whatever situation is lying around"
17:34:01 edleafe I get that, but it seems like looking at it as a single concern will make it essentially useless for the vast majority of OpenStack developers
17:34:38 edleafe Really, I joke and call it the "Monty case", but I don't know anyone else who has such stringent requirements
17:35:29 cdent that's kind of the point: are we trying to describe interop or not? I felt that the outcome from a) the ptg, b) the discussion on the document and c) look at TheMission is that we are. If we are, then the implications are _severe_
17:35:56 cdent and thus the document needs to be pretty explicit about just how difficult things are, and the things to look out for
17:37:02 elmiko i'm having a difficult time following the action item here, are we still trying to figure how to mention alternatives without blessing them?>
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

Earlier   Later