| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-05 | |||
| 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 | |
| 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) | |