Earlier  
Posted Nick Remark
#openstack-sdks - 2017-04-05
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
07:57:31 reedip that would add everything in the same variable , try that
08:00:47 rabel i will have a look at that. thank you!
08:07:21 valeryt is it possible to list the user project as in https://developer.openstack.org/api-ref/identity/v3/?expanded=list-projects-for-user-detail with the openstacksdk ?
08:08:03 valeryt I tried conn.identity.projects(user_id=user.id) but it doesn't work...
10:27:13 openstackgerrit Stephen Finucane proposed openstack/cliff master: Add 'cliff-commands' Sphinx directive https://review.openstack.org/453383
10:38:13 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
10:40:11 rabel reedip: do you want to have a look at my newest patch proposal? i know it's a bit of a workaround, but this is probably the best solution for now.
10:40:32 reedip rabel : Maybe a bit later, but will do :)
10:40:34 reedip thanks
10:41:04 rabel ok, thank you. :)
11:18:36 frickler how can I create a non-ha router with OSC? seems there is only the "--ha" option, but that is the default anyway
11:19:24 frickler neutron cli can do "--ha False"
11:55:17 briancurtin valeryt: projects probably doesn’t currently take query parameters, but it could be added
11:58:16 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Add --network and --port to server create https://review.openstack.org/444924
12:01:35 rabel_b1 frickler: ha should not be default on router creation
12:02:06 rabel_b1 just tried it here. "openstack router create my_router" creates a router without ha
12:03:59 frickler rabel_b1: which version are you using? I'm at 3.9.0 and for me that gets me a router with ha enabled. at least when I'm running as admin
12:04:15 rabel_b1 3.9.1
12:04:46 briancurtin valeryt: also it looks like what you’re trying wouldn’t be supported by the REST API anyway. user_id isn’t a query param it takes
12:04:50 rabel_b1 ah no, it's master from git
12:04:50 rabel_b1 wait
12:05:59 rabel_b1 frickler: the same with 3.9.0
12:07:12 rabel_b1 got to go now, sorry
12:10:15 frickler rabel_b1: but you did test with a cloud that has l3_ha=true in neutron?
12:23:50 openstackgerrit Merged openstack/python-openstacksdk master: Introduce Base for Octavia (load balancing) https://review.openstack.org/428414
12:24:17 valeryt briancurtin: ok, but the keystone v3 user api have the REST /v3/users/{user_id}/projects for it
12:24:34 valeryt briancurtin: as described here: https://developer.openstack.org/api-ref/identity/v3/?expanded=list-projects-for-user-detail#list-projects-for-user
12:24:42 briancurtin ah
12:25:20 briancurtin valeryt: can you enter this on https://bugs.launchpad.net/python-openstacksdk and we’ll take a look at adding it?
12:25:23 valeryt briancurtin: is it implemented, or it was just forget?
12:25:56 valeryt briancurtin: ok will do
12:26:15 briancurtin valeryt: it’s 100% not implemented how you tried to do it, but it could be supported. we don’t have a ton of keystone v3 coverage right now
12:27:39 Guest85496 reedip, hi
12:31:51 valeryt briancurtin: https://bugs.launchpad.net/python-openstacksdk/+bug/1680063
12:31:51 openstack Launchpad bug 1680063 in OpenStack SDK "List projects for user" [Undecided,New]
12:33:37 frickler rabel_b1: https://bugs.launchpad.net/python-openstackclient/+bug/1664255 has a similar issue, seems it can be extended to cover mine
12:33:37 openstack Launchpad bug 1664255 in python-openstackclient "Admin can't override default "distributed" flags" [Undecided,In progress] - Assigned to venkata anil (anil-venkata)
12:44:37 briancurtin valeryt: cool, i commented on there about some options. i think what you were originally trying to do should be how it works. i’m busy right now myself but if no one else gets to it i’ll try to fix it relatively soon
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

Earlier   Later