Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-04
15:12:12 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Listener for Octavia (load balancing) https://review.openstack.org/451574
15:39:30 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Listener for Octavia (load balancing) https://review.openstack.org/451574
15:43:45 openstackgerrit Shashank Kumar Shankar proposed openstack/python-openstackclient master: Correct flavor associate/disassociate commands in Mapping Guide https://review.openstack.org/453232
15:45:50 openstackgerrit Shashank Kumar Shankar proposed openstack/python-openstackclient master: Correct flavor associate/disassociate commands in Mapping Guide https://review.openstack.org/453232
16:12:12 openstackgerrit Sindhu Devale proposed openstack/python-openstacksdk master: Introduce HealthMonitor for Octavia (load balancing) https://review.openstack.org/453243
16:15:44 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Enable to specify which fixed-ip to add to a vm. https://review.openstack.org/452235
16:27:25 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: Structure FindFloatingIP() to work without ip_cache https://review.openstack.org/447938
17:25:22 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
18:00:53 sindhu dtroyer: stevemar : https://review.openstack.org/#/c/447938/ is ready :)
18:19:00 openstackgerrit Merged openstack/python-openstackclient master: Correct flavor associate/disassociate commands in Mapping Guide https://review.openstack.org/453232
19:12:12 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Pool for Octavia (load balancing) https://review.openstack.org/449264
20:10:27 openstackgerrit ayoung proposed openstack/python-openstackclient master: Implied Roles https://review.openstack.org/290253
20:16:11 openstackgerrit Shashank Kumar Shankar proposed openstack/python-openstacksdk master: Introduce Pool for Octavia (load balancing) https://review.openstack.org/449264
20:31:15 openstackgerrit Merged openstack/python-openstackclient master: Structure FindFloatingIP() to work without ip_cache https://review.openstack.org/447938
20:32:46 sindhu dtroyer: stevemar : https://review.openstack.org/#/c/383025/ is ready as well :)
20:40:19 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488
20:54:52 openstackgerrit ayoung proposed openstack/python-openstackclient master: Implied Roles https://review.openstack.org/290253
21:16:56 dtroyer sindhu: in 383025, what is the SDK dependency mentioned?
21:18:55 sindhu dtroyer: Rui introduced this change in sdk https://review.openstack.org/#/c/449879/2
21:19:10 sindhu dtroyer: which is needed by 383025
21:19:29 dtroyer has it been released yet?
21:19:42 sindhu dtroyer: but, that won't be available till it is released
21:19:49 sindhu dtroyer: nope
21:20:28 sindhu dtroyer: so, reedip's patch which got merged now helps
21:20:47 sindhu dtroyer: it removes the use of ip_cache
21:21:08 sindhu dtroyer: once sdk is released, this work around has to be fixed
21:22:00 dtroyer can you make those dependencies clear in the commit message?
21:22:14 dtroyer I can't tell right now what needs to happen in what oder
21:22:30 dtroyer I'll have a couple of other comments in a few minutes to post
21:22:46 sindhu dtroyer: sure, i'll add it :)
21:31:17 dtroyer sindhu: ok, comments in
21:32:03 sindhu dtroyer: great, thank you :)
22:35:39 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: [WIP] Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488
23:54:26 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: WIP! Start using 'cliff.sphinxext' https://review.openstack.org/452861
23:55:04 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: WIP! Start using 'cliff.sphinxext' https://review.openstack.org/452861
#openstack-sdks - 2017-04-05
00:02:08 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-commands' Sphinx directive https://review.openstack.org/453383
00:02:08 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-command' Sphinx directive https://review.openstack.org/450322
01:13:59 reedip o/
01:49:50 openstackgerrit yangweiwei proposed openstack/python-openstackclient master: Update endpoint-delete and endpoint-show method exception. https://review.openstack.org/453429
02:32:33 openstackgerrit yangweiwei proposed openstack/python-openstackclient master: Update endpoint-delete and endpoint-show method exception. https://review.openstack.org/453429
02:55:12 openstackgerrit Merged openstack/python-openstackclient master: Enable to specify which fixed-ip to add to a vm. https://review.openstack.org/452235
07:03:41 rabel good morning
07:14:04 rabel someone can help me with a question about argparse?
07:15:25 rabel in https://review.openstack.org/#/c/444924/4/openstackclient/compute/v2/server.py@612 cedric proposes that --nic, --network and --port should all add their values to the same variable. but is this even possible? or doable in a clean way?
07:23:49 openstackgerrit Reedip proposed openstack/python-openstackclient master: Introduce quota unset command https://review.openstack.org/376311
07:37:04 reedip rabel : hi
07:37:35 rabel hi reedop
07:37:40 rabel *reedip. sry ;)
07:37:52 reedip lol , no worries .. o and I are very near
07:38:22 reedip rabel : why are we using different options here? Cant we use MutliKeyValue Action ?
07:38:38 reedip I mean network, port and nic, all can be optional
07:38:44 reedip in the MultiKeyValue Action
07:38:54 reedip and it allows the user to specify them as a dict
07:39:04 reedip and remove the trouble which you guys are facing, right ?
07:39:43 rabel i'm not sure if i understand. we can use MultiKeyValueAction for --network, --port and --nic and then have them all in one?
07:39:46 reedip we can have --network net=Network_ID,port=Port_Id,nic=Nic_ID
07:39:53 reedip yes
07:40:44 reedip so that ways, we get a dictionary , with {"net":Network_ID, "port":Port_ID, "nic":Nic_ID} and handle the internals ourselves as we see fit
07:41:05 reedip though merging things in the same variable is POSSIBLE
07:41:14 rabel but that's actually what we don't want.
07:41:21 reedip but I agree that there are cleaner options
07:41:39 reedip rabel : okay
07:41:48 rabel what you propose is basically the current solution with --nic net-id=,port=,...
07:41:59 rabel the patch tries to simplify that
07:42:26 rabel it is possible, but not in a clean way?
07:43:02 reedip then the second option is to keep it in different metavar and then handle it yourself
07:43:18 reedip I mean keep nic, port and network in separate metavars
07:43:28 reedip but then is that what u need?
07:44:16 reedip I see I reviewed this patch earlier and gave the same response to you about MultiKeyValueAction :D
07:44:36 rabel yes :D
07:45:34 rabel to keep them in different metavars would not fix the issue, that --nic bla1 --network bla2 --nic bla3 would end up in the order bla1 bla3 bla2.
07:45:42 rabel but i have no idea how to deal with that issue
07:46:06 reedip rabel : okay, let me know what you really want :)
07:46:24 reedip you want direct mapping of the network to the nic, right?
07:47:02 reedip I mean as per the above command, you want bla1 to be associated with bla2, and bla3 is not associated with any network, right ?
07:47:16 rabel no, it's just about the order.
07:47:46 rabel so at the moment the nics provided with --nic are first, then come the --network nics and then the --port nics
07:47:58 reedip okay
07:48:03 rabel but i want them all in the order that they are provided
07:48:32 rabel so if you first specifiy a --network net1 and then a --nic net-id=net2, then i want the net1 nic to be first and net2 nic to be second
07:48:44 reedip any reason for wanting them in that same order ? ( I am trying to find the root requirement, and if it can be met some other way )
07:49:11 rabel i think the end user will expect them to be in that order. that's the only reason
07:49:27 reedip not necessarily ...
07:49:57 reedip but is there any other reason with respect to the functionality you need?
07:50:02 rabel no
07:50:56 reedip so except the exact order with which the user enters the options, you dont have any other requirement, right ?
07:51:06 reedip then appending in the same variable is the best solution
07:51:26 reedip otherwise everything would be parsed with the argument you are sending
07:52:26 rabel do you know how to append them to the same variable?
07:52:52 reedip the method which you have done :D metavar =X and action = append for all variables
07:52:59 reedip --network, --nic and --port
07:53:43 rabel :D than i misunderstood you
07:54:32 rabel wait. this confuses me. the metavar= statement is only for the help message, right?
07:55:19 reedip nope
07:55:34 reedip the metavar actually tells argparse where the value would end up
07:55:44 rabel the variables are parsed_args.network, parsed_args.port and parsed_args.nic
07:56:09 reedip wait a minute
07:56:13 rabel and i thought the variable names are derived from the option name --network, --port, --nic
07:57:07 reedip yeah u r right.. it was destination what I was talking about
07:57:14 reedip so yeah, you can use dest as well

Earlier   Later