Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-01
09:53:21 openstackgerrit Reedip proposed openstack/python-openstackclient master: Structure FindFloatingIP() to work without ip_cache https://review.openstack.org/447938
16:15:19 openstackgerrit Cedric Brandily proposed openstack/python-openstackclient master: Enable to specify which fixed-ip to add to a vm. https://review.openstack.org/452235
21:07:29 openstackgerrit Merged openstack/python-openstackclient master: doc: Remove local fork of apidoc https://review.openstack.org/447589
21:08:44 openstackgerrit Merged openstack/python-openstackclient master: doc: Correct Sphinx warnings https://review.openstack.org/447590
21:18:16 openstackgerrit Merged openstack/python-openstackclient master: Use Sphinx 1.5 warning-is-error https://review.openstack.org/446629
#openstack-sdks - 2017-04-02
14:33:59 reedip ankur-gupta-f4 :if u r around, https://review.openstack.org/#/c/447938/ :D
14:40:14 openstackgerrit Reedip proposed openstack/python-openstackclient master: Introduce quota unset command https://review.openstack.org/376311
16:24:48 openstackgerrit Monty Taylor proposed openstack/os-client-config master: Add ability to pass in user_agent https://review.openstack.org/452550
#openstack-sdks - 2017-04-03
02:04:24 reedip o/
02:06:49 ankur-gupta-f4 reedip: dont file bug. Only if there was existing. But its just a refactor so its fine
02:07:19 reedip ankur-gupta-f4 : were u just waiting for me with that response already typed ???? :D
02:07:31 reedip I am not filing a bug :) , dont worry :P
02:08:53 ankur-gupta-f4 No just rmred u commented on patch
02:08:58 ankur-gupta-f4 N saw u wave
02:09:13 reedip :D
02:21:53 openstackgerrit Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585
03:10:51 openstackgerrit Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585
05:06:30 openstackgerrit Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585
06:26:58 openstackgerrit Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585
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

Earlier   Later