| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-03 | |||
| 06:31:07 | openstackgerrit | Reedip proposed openstack/python-openstackclient master: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263 | |
| 06:48:46 | reedip | RuiChen : I updated the Floating IP Patch, awaiting your review :) | |
| 09:13:00 | openstackgerrit | Samriddhi proposed openstack/keystoneauth master: Updated inconsistent value of scope parameter https://review.openstack.org/452652 | |
| 10:03:54 | ZZelle_ | ok | |
| 10:31:45 | reedip | RuiChen : there? | |
| 10:57:14 | openstackgerrit | Reedip proposed openstack/python-openstackclient master: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263 | |
| 11:06:06 | openstackgerrit | Cedric Brandily proposed openstack/osc-lib master: Avoid to authenticate twice https://review.openstack.org/452711 | |
| 11:26:48 | openstackgerrit | Jens Rosenboom proposed openstack/python-openstackclient master: Fix block-device-mapping when volume_size is empty https://review.openstack.org/451432 | |
| 12:29:19 | reedip | ankur-gupta-f4 : woke up ? | |
| 12:29:55 | reedip | sindhu : there ? | |
| 12:53:19 | openstackgerrit | Dirk Mueller proposed openstack/cliff master: .gitignore: Ignore eggs https://review.openstack.org/449740 | |
| 13:02:42 | openstackgerrit | Reedip proposed openstack/python-openstackclient master: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263 | |
| 14:37:57 | sindhu | reedip: hey wass up | |
| 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 | 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:52:47 | cdent | brb | |
| 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 | |