Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-05
15:10:42 ankur-gupta-f4 Imho
15:11:05 rabel_b1 ankur-gupta-f4: yes, but it very probably won't
15:11:17 reedip rabel_b1 : IIUC currently --nic should have default none if nothing is specified, you might need to handle that with --network and --port as well ( i.e. if no option is specified, treat --nic as none in the body )
15:11:31 reedip auto option should be with --nic only , not with --network/--port
15:11:55 reedip ankur-gupta-f4 ; it would be difficult to replacte the auto behavior with --network/--port
15:12:58 ankur-gupta-f4 It shouldn't be that complicated if both nic and network options are handled in similar ways
15:13:07 rabel_b1 yes, dtroyer said something similar: none and auto should only be available for --nic, not for --network/--port
15:14:11 reedip ankur-gupta-f4 : it shouldnt be, but ideally it need not be required if we have --nic :) anyways, I think rabel_b1 has reached a satisfying conclusion , thanks to ZZelle_ :)
15:15:44 ankur-gupta-f4 Okay
15:16:18 ankur-gupta-f4 Will review it later. Still seems like it is would be confusing for end user.
15:16:27 ankur-gupta-f4 Lets see how it turnsout
15:17:11 rabel_b1 ankur-gupta-f4, reedip, ZZelle_: so, everyone seems to be fine with that solution. i will implement that in a new patch set.
15:17:39 rabel_b1 reedip: i am not quite sure yet how to do the help message the best way.
15:18:51 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
15:19:22 reedip rabel_b1 : hmm ... for help message, you can simply mention like what we have mentioned here
15:19:27 rabel_b1 ZZelle_: i use network= instead of net-id= in that place to distinguish between --nic and --network later for the error message. see line 610+
15:20:26 rabel_b1 ZZelle_: maybe it is better to change the error message to something more generic?
15:20:26 ZZelle_ rabel_b1, i will wait for the next PS as it's not really meaningful to review the current one more
15:21:20 rabel_b1 ok, i will first create a new patch set now, then we can discuss on that. :)
15:21:24 sindhu dtroyer: hi, https://review.openstack.org/#/c/383025/ is ready. Have added a detail commit message
15:24:05 dtroyer I don't mind having multiple ways to do things when they fit particular use cases, I think —port and —network do as long as they are simple options. in PS9 they are nearly aliases to —nic which I do not think adds much here.
15:28:05 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
15:28:58 reedip dtroyer : missing your opinion on this : ^^ ( I am going to bug you a bit for this , hope you dont mind :) )
15:31:11 dtroyer reedip: you mean 383025?
15:31:20 reedip dtroyer : YES :)
15:31:33 dtroyer what specifically?
15:31:46 reedip well, its ready ..
15:32:14 dtroyer not quite: https://review.openstack.org/#/c/383025/74/doc/source/command-objects/floating-ip.rst@156
15:32:40 reedip ohh ...
15:32:56 reedip 3rd April , will look into it.. thanks
15:33:16 dtroyer also, what I was looking for with regard to the SDK is when that dependent review gets released.
15:33:32 dtroyer ie, it's merged, what is the next release expected to be?
15:33:42 dtroyer but that's just a bit of leg owrk to track down
15:34:53 reedip dtroyer: thats what sindhu has mentioned in the commit message and in the file
15:35:28 ankur-gupta-f4 reedip make note in commit saying 0.9.15 SDK release needed
15:35:40 dtroyer it only points to a (now merged) review. it is more helpful to say "is expected to be relased in 0.9.xx", but that's just a bit of research to figure out if that has happened
15:35:43 openstackgerrit Brian Curtin proposed openstack/python-openstacksdk master: Enable warnings_as_errors in doc enforcer https://review.openstack.org/453676
15:36:01 dtroyer you don't always know, that's fine
15:36:08 reedip dtroyer : ankur-gupta-f4 : ok...
15:37:04 reedip dtroyer: I think I and sindhu agree that that type of work could be tracked down by us... but yes mentioning a ToDO with the approporate SDK release is imp
15:37:43 briancurtin if you guys need an SDK release, we’re probably close to one. should probably wait on a couple of these load_balancer ones since they’re close to being done and they’re all related
15:38:31 sindhu reedip: for some reason I thought u addressed https://review.openstack.org/#/c/383025/74/doc/source/command-objects/floating-ip.rst@156, are u doing it or shall I do it
15:39:00 reedip sindhu : be my guest if you want to .. I was searching for the patch that merged on 3rd april :)
15:39:06 dtroyer thanks briancurtin. I think there are a couple of things in OSC that go with new/fixed SDK bits. We're cutting a release today or tomorrow for OSC and osc-lib so we're not really blocked on the SDK
15:40:14 sindhu reedip: oh ok
15:40:25 dtroyer sindhu, reedip: actually, it isn't just released, but that version of the SDK needs to be in the minimum in global requirements (requirements.txt) before we can assume it will be present
15:40:57 reedip dtroyer : yeah, thats what is bliocking us and is our requirement ( the SDK needs to be in ou requirements )
15:41:52 sindhu dtroyer: Oh ok ... but we don't have to be blocked by that now right?
15:41:58 ankur-gupta-f4 briancurtin: for the load balancer ones we are concerned over the functional tests not being run. And we haven't yet been able to verify whether the calls/functionally are working correctly yet. I don't know if you want to wait upon those to release. Else, we can push those all though and deal with fixing them later
15:42:44 briancurtin ankur-gupta-f4: yeah, actually it does look like the functional tests might take a bit so we could be waiting a while. i’ll take a look in about an hour and see if we have anything else necessary to get a release out
15:44:08 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: [WIP] Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488
15:44:30 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488
15:44:31 ankur-gupta-f4 that seems best. I would prefer to hold off on merging the LBs till I/we can verify its working as expected locally before merging.
15:44:54 dtroyer sindhu: if an OSC review requires an SDK review to be present to work, yes, you must either handle both cases (with and without the SDK review present) or you must wait until the SDK release that includes that dependent review is in global-requirements.
15:45:10 reedip ankur-gupta-f4 : feel free to let me know if something needs to be done for octaviaclient
15:45:32 ankur-gupta-f4 yea review the initial. Figure out how to deal with that function that just "pass"es
15:45:59 reedip link ?
15:46:31 sindhu dtroyer: Okay, cool. got it ... thanks :)
15:46:36 ankur-gupta-f4 sindhu: reedip: once the SDK 9.15 is released you will need to follow up with a patchset like https://review.openstack.org/#/c/451482/1/global-requirements.txt to bump the global req. then we can merge it
15:46:50 ankur-gupta-f4 reedip:
15:46:51 ankur-gupta-f4 https://review.openstack.org/#/c/446223/
15:47:08 reedip ankur-gupta-f4 : Openstack Proposal bot would do that itself, isnt it ?
15:47:10 ankur-gupta-f4 dtroyer: could use your quick input on how its being implemented as well before i get too down the rabbit hole
15:47:21 reedip ankur-gupta-f4 ( for Link ) : thanks :)(
15:47:37 ankur-gupta-f4 reedip: i don't think so, since I've had to do it a couple times already
15:48:05 reedip dtroyer : ^^ shouldnt the proposal bot pick it up ?
15:48:52 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-command' Sphinx directive https://review.openstack.org/450322
15:48:52 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-commands' Sphinx directive https://review.openstack.org/453383
15:49:03 ankur-gupta-f4 once merged to global-req, then proposal bot bumps it for all the individual projects as well... i believe
15:49:42 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
15:50:25 rabel_b1 new proposal for you ::)
15:50:51 reedip ankur-gupta-f4 : yeah it should, and you dont need to do it yourself, in the Ideal scenario
15:50:55 reedip rabel_b1 : thanks :)
15:53:13 rabel_b1 reedip: it has some weeknesses that should be fixed when migrating to MultiKey...andSoOn. but i think for now it should be fine.
15:54:29 reedip rabel_b1 : ok , will put it in the review tab :)
15:55:23 sindhu ankur-gupta-f4: but we don't need SDK now for 383025 to work right?
15:56:53 reedip we dont ... I agree
15:57:10 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Add "qos-policy" option to "port create" & "port set" https://review.openstack.org/419236
15:57:51 openstackgerrit Reedip proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
15:59:29 dtroyer reedip, ankur-gupta-f1: the proposal bot creates reviews for projects based on what gets merged into the requirements repo. We have to propose the reviews to requirements.
15:59:44 dtroyer ankur-gupta-f1: what did you want input on?
16:00:53 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce L7Policy for Octavia (load balancing) https://review.openstack.org/451980
16:01:29 ankur-gupta-f4 dtroyer: https://review.openstack.org/#/c/446223/
16:01:38 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce L7Rule for Octavia (load balancing) https://review.openstack.org/452832
16:01:42 ankur-gupta-f4 to see if its in the fashion that looks okay/works for you.
16:02:23 ankur-gupta-f4 https://review.openstack.org/#/c/447068/ is piece in OSC to initialize it.
16:02:50 ankur-gupta-f4 Bout to head out to airport so will be on/off for the next couple hours but will log back in on the plane.
16:02:56 mordred cdent: the example iin https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery says it was taken from nova, but it does not match what nova emits
16:03:19 cdent a) /me shakes tiny fist
16:03:24 cdent b) predates me
16:03:35 mordred k. I mena- I like what's in the spec better
16:03:36 cdent c) give me a few minutes and I'll look into it more closely and fix it
16:03:47 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
16:03:50 mordred but I'm wondering if we should align the spec to nova or try to get nova to add an additional key to theirs?
16:03:55 cdent it is quite likely that what's in the spec is desirable
16:04:03 mordred cdent: (the tl;dr is nova uses "version" to mean max_version)
16:04:27 cdent oh yeah, that's an intentional change
16:04:30 mordred ok. cool
16:04:32 cdent the surrounding tesxt is wrong
16:04:42 mordred I'll make the project-navigator stuff align to the api-wg thing

Earlier   Later