Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-05
12:46:31 valeryt briancurtin: thanks
12:59:13 openstackgerrit Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585
13:13:05 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: WIP! Start using 'cliff.sphinxext' https://review.openstack.org/452861
13:42:48 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
14:06:40 openstackgerrit Brian Curtin proposed openstack/python-openstacksdk master: Add get_stack_* methods to documentation https://review.openstack.org/453646
14:25:25 openstackgerrit Brian Curtin proposed openstack/python-openstacksdk master: Clean up some errant doc warnings/errors https://review.openstack.org/453661
14:30:15 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add "qos-policy" option to "port create" & "port set" https://review.openstack.org/419236
14:44:25 reedip ZZelle_ yes hello
14:48:00 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
14:49:13 reedip rabel_b1 : hi
14:49:56 rabel_b1 reedip: hi. arg, i just made it worse... :D
14:50:55 reedip rabel_b1 : I saw ZZelle_ 's comments. I agree, lets discuss this in detail here or on the bug . dtroyer 's input would alsio be great here :)
14:51:08 reedip s/bug/patch/
14:51:32 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
14:52:06 openstackgerrit Merged openstack/python-openstacksdk master: Add get_stack_* methods to documentation https://review.openstack.org/453646
14:53:50 rabel_b1 i would prefer not to discuss that in the change. here is fine, launchpad also. but on the change there is already enough, if it's only about the implementation. so i would like to keep the "what to implement?" question separate
14:55:13 rabel_b1 also in the launchpad bug we already started talking about that.
14:55:38 ZZelle_ rabel_b1, reedip, it's a mess to jump between launchpad and review.o.o ... let's discuss in one place
14:55:49 reedip agreed ZZelle_
14:56:17 reedip but where ?? :)
14:56:48 ZZelle_ reedip, review.o.o :)
14:57:03 ZZelle_ reedip, the code won't go in launchpad :)
14:57:08 reedip rabel_b1 : is that ok with u ??
14:57:15 reedip ZZelle_ hehe.. yeah
14:58:19 rabel_b1 ZZelle_, reedip: ok, review then.
14:58:31 openstackgerrit Monty Taylor proposed openstack/os-client-config master: Add ability to pass in user_agent https://review.openstack.org/452550
14:58:48 rabel_b1 but maybe we can also talk about it here first
14:59:39 rabel_b1 since we three are here right now and we can post the outcome as comment on the review?
15:00:33 ankur-gupta-f4 Which patchset are you discussing
15:00:53 reedip ankur-gupta-f4 : I was waiting for you to chime in :)
15:01:03 reedip https://review.openstack.org/444924
15:01:38 ankur-gupta-f4 Oh yea. Fun
15:01:51 reedip :D
15:03:12 reedip I will be Back ... ( in a jiffy )
15:03:16 ZZelle_ rabel_b1, reedip, dtroyer, the main point to agree is the format
15:03:48 ZZelle_ rabel_b1, reedip, dtroyer, imo, there is no reason to have 3 options --nic, --network, --port which supports complex values
15:04:34 ZZelle_ rabel_b1, reedip, let's use --network --port for simplex cases: --network $network or --port $port
15:05:15 ZZelle_ rabel_b1, reedip, if you need a finer interface description then use --nic $key=$value,...
15:07:48 rabel_b1 ZZelle_, reedip, ankur-gupta-f4, dtroyer: sounds reasonable to me. i think i first had in mind that --nic could be deprecated in the future in favour of --network and --port. but since those are not going to implement the --nic auto and --nic none functionality either, we will probably stay with having three parameters.
15:08:19 reedip ZZelle_ ok, so you mean with --network and --port we do not need to specify nic
15:08:21 rabel_b1 so, since --nic will not be deprecated, i think you are right, ZZelle_.
15:08:30 ZZelle_ rabel_b1, what means --nic none or --nic auto?
15:08:54 reedip if that is so ZZelle_ , rabel_b1 , we need to be pretty thorough in the Help Message
15:09:16 rabel_b1 ZZelle_: afaiu --nic none means having a nic without a port connected to it and --nic auto means looking for a network that fits it needs. but i'm not sure here.
15:09:29 ZZelle_ reedip, yes, --network $network enables to specify a nic on a specific network, --port port a nic using a specific port and --nic is for other cases
15:09:40 ZZelle_ rabel_b1, ok
15:10:38 ankur-gupta-f4 If --nic will be deprecated then --network and --port need to fulfill all the options that --nic supports
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.

Earlier   Later