| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-01 | |||
| 10:03:42 | reedip_ | amotoki: I needed the link, I got it from history | |
| 10:04:00 | amotoki | reedip_: the link is pasteed in the OSC PTG page | |
| 10:04:04 | reedip_ | amotoki: I am fine with both "floating ip set port" and "floating ip set" | |
| 10:04:33 | amotoki | reedip_: honestly my current vote is 'set port' :) | |
| 10:04:33 | reedip_ | amotoki: Currently , there is no SET option in NeutronClient for Floating IP | |
| 10:04:45 | amotoki | reedip_: yeah, there is no. | |
| 10:05:00 | reedip_ | amotoki: so what we can do is , change the name of the class to SetFloatingIPPort | |
| 10:05:03 | amotoki | reedip_: we have description field now. | |
| 10:05:17 | amotoki | reedip_: it is okay to me if create command supports it later. | |
| 10:05:18 | reedip_ | amotoki: so that if there is ever a requirement in the future, we can consider it later | |
| 10:05:33 | amotoki | reedip_: okay | |
| 10:06:05 | amotoki | reedip_: it is just for curiosity. thanks for your time | |
| 10:06:27 | reedip_ | :) | |
| 10:29:47 | openstackgerrit | Reedip proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025 | |
| 11:04:28 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add "qos-policy" option to "port create" & "port set" https://review.openstack.org/419236 | |
| 11:11:29 | openstackgerrit | Merged openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/439362 | |
| 13:17:22 | sambetts | Hi openstackclient team, I'm hitting an issue on stable/mitaka, my CI has been failing since https://github.com/openstack/requirements/commit/808355f7ddd29f834531bfa6ead7ad01fbe37fb6 merged | |
| 13:19:31 | sambetts | when I have 2.3.1 installed I get this error during devstack: [localhost] out: 2017-02-28 22:24:49.692 | DEFAULT_USER_AGENT = "openstacksdk/%s" % openstack.__version__ | |
| 13:19:34 | sambetts | [localhost] out: 2017-02-28 22:24:49.692 | AttributeError: 'module' object has no attribute '__version__' | |
| 13:19:50 | sambetts | reverting to 2.3.0 fixes this issue | |
| 13:49:15 | openstackgerrit | Qiming Teng proposed openstack/python-openstacksdk master: Add wait_for_xxx methods to cluster proxy https://review.openstack.org/439490 | |
| 14:56:12 | openstackgerrit | Qiming Teng proposed openstack/python-openstacksdk master: Change version of hacking in test-requirements https://review.openstack.org/439636 | |
| 14:58:11 | openstackgerrit | Qiming Teng proposed openstack/python-openstacksdk master: Add wait_for_xxx methods to cluster proxy https://review.openstack.org/439490 | |
| 15:05:11 | openstackgerrit | Pavlo Shchelokovskyy proposed openstack/openstackclient master: Explicitly depend on python-openstackclient https://review.openstack.org/439641 | |
| 15:38:54 | openstackgerrit | Merged openstack/python-openstacksdk master: Change version of hacking in test-requirements https://review.openstack.org/439636 | |
| 15:45:21 | elmiko | etoews, edleafe, looks like i've got a conflict with tomorrow's meeting. just a heads up | |
| 15:52:40 | edleafe | elmiko: ack | |
| 16:18:32 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstackclient master: OSC Network Flavor Profile https://review.openstack.org/396783 | |
| 16:30:24 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce neutron flavor associate, disassociate to OSC https://review.openstack.org/403907 | |
| 16:33:42 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce neutron flavor associate, disassociate to OSC https://review.openstack.org/403907 | |
| 16:46:00 | reedip | o/ | |
| 16:51:52 | ediardo | o/ | |
| 16:56:10 | ankur-gupta-f1 | ediardo: whats up! | |
| 17:12:43 | dtroyer | sshank, ankur-gupta-f1: so on https://review.openstack.org/#/c/387611/ it seems like the final thing to sort out is —agent-type | |
| 17:13:12 | sshank | dtroyer, yes. | |
| 17:13:54 | dtroyer | I asked for it to be there because I was worried and thinking ahead to if making the assumption that "network agent add network" can _always_ assume the DHCP agent in the future | |
| 17:14:16 | dtroyer | rather, I wanted it to protect against that assumption changing | |
| 17:14:53 | sshank | dtroyer, yeah right now it seems like only dhcp can be added to network. | |
| 17:14:58 | dtroyer | if that is a safe assumption, let's just remove —agent-type. But we will forever have that assumption of the default type if there ever is a nother one possible in this command | |
| 17:15:20 | dtroyer | can we live with thqat? | |
| 17:15:22 | dtroyer | that? | |
| 17:15:37 | sshank | ankur-gupta-f1, ^^? | |
| 17:16:08 | sshank | dtroyer, he is not at his desk. Lemme ping him | |
| 17:16:45 | dtroyer | I'll leaving a comment in the review to doc this… | |
| 17:16:47 | ankur-gupta-f1 | yea i am fine with removing --agent-type | |
| 17:17:07 | dtroyer | and living with the assumption forever? :) | |
| 17:17:55 | ankur-gupta-f1 | ah theres the catch | |
| 17:18:20 | dtroyer | that's why I have been deliberate on this… | |
| 17:18:21 | ankur-gupta-f1 | I still stick by my original idea of putting the --<agent-binary> flag. | |
| 17:18:42 | dtroyer | what is that again? | |
| 17:19:29 | ankur-gupta-f1 | so in case an agent is created down the road where it can add an agent there must be some way of indicating which of the two types of agents. | |
| 17:19:30 | dtroyer | also, there is the slightly larger pattern for all "network agent add/remove XXXX" commands. If others may need to declare an agent type | |
| 17:19:42 | dtroyer | right, that is what —agent-type is for | |
| 17:19:50 | dtroyer | but unneeded at the moment | |
| 17:20:26 | ankur-gupta-f1 | What I am proposing is instead of --agent-type <agent-name>, just have a single flag --<agent-name> | |
| 17:20:53 | ankur-gupta-f1 | network agent add network --dhcp <agent-id> <network> | |
| 17:21:16 | dtroyer | ok, yeah, that is actaully closer to what we do in a lot of other places. | |
| 17:21:31 | ankur-gupta-f1 | parser then will only have to check which flag is set and then call the appropriate object function | |
| 17:21:52 | dtroyer | sometimes we pick the enumerated options over explicit options when there are either a lot of them, or the list is semi-fluid | |
| 17:22:21 | dtroyer | in the general "network agent add/remove XXX" command case, is this still a safe approach? | |
| 17:22:44 | reedip | hi ankur-gupta-f1 | |
| 17:22:52 | reedip | cant we add lbaas as an agent ? | |
| 17:23:03 | ankur-gupta-f1 | yes. many-to-many relationship I think should be the guideline whether to use add/remove and set | |
| 17:23:58 | dtroyer | specifically though WRT —dhcp style options rather than a single generic --agent-type | |
| 17:25:21 | ankur-gupta-f1 | yes | |
| 17:25:29 | reedip | I agree with "network agent add/remove ABC" optio | |
| 17:25:44 | ankur-gupta-f1 | reedip: currently the only lbaasv2 command for the lbaas-agent checks lbaas-agent vs other loadbalancing resources | |
| 17:26:15 | reedip | ankur-gupta-f1 : what I meant was except dhcp , we have other options as wel | |
| 17:27:03 | ankur-gupta-f1 | reedip: explain? | |
| 17:27:18 | ankur-gupta-f1 | there will be a flag for --l3 as well | |
| 17:27:56 | dtroyer | so to restate for clarity: for any "network agent" commands that may need to handle multiple agent types, we will use agent-type-specific options (such as —dhcp and —l3) to identify the agent type rather than a single —agent-type <type> option; also where only a single type can be assumed we will use that assumption as the default. | |
| 17:28:17 | ankur-gupta-f1 | correct | |
| 17:28:22 | dtroyer | \o/ | |
| 17:28:35 | ankur-gupta-f1 | adding to both those reviews for reference | |
| 17:28:49 | sshank | so its 'openstack network agent add network --dhcp <agent-id> <network>' correct? | |
| 17:29:05 | ankur-gupta-f1 | yes | |
| 17:29:18 | dtroyer | —dhscp is not required in that command as it is the only agent type to need "add network" is my understanding | |
| 17:29:49 | dtroyer | if we want to allow —dhcp that is fine with me, and is essentially what the current —agent-type option is doing | |
| 17:29:51 | reedip | dtroyer: yes, thats correct | |
| 17:29:58 | sshank | So its 'openstack network agent add network <agent-id> <network>' since dhcp is default? | |
| 17:30:05 | dtroyer | yes | |
| 17:30:12 | sshank | Ok | |
| 17:30:16 | reedip | but cant we have any oher network agent in the future ? | |
| 17:30:29 | dtroyer | we can, but DHCP will be the default forever | |
| 17:30:30 | ankur-gupta-f1 | wait no we just went backwards | |
| 17:30:48 | dtroyer | ?? | |
| 17:31:25 | reedip | dtroyer : so you want --dhcp to be the default optional ? | |
| 17:32:18 | reedip | I am not sure about that .... User should know which agent he is working upon. I would suggest an agent type to be specified. It may not be a flag , but an agent name ( like dhcp / l3 ) which can be checked | |
| 17:33:17 | dtroyer | so then the need is to make the rule for how to specify network agent type for all network agent commands | |
| 17:33:57 | sshank | I personally think 'openstack network agent add network --dhcp <agent-id> <network>' would be better. It is explicit and causes no confusion. | |
| 17:34:15 | reedip | sshank : --dhcp => dhcp | |
| 17:34:37 | reedip | does that seem better or equally intriguing to u? | |
| 17:34:39 | dtroyer | no, if it is there it is an option | |
| 17:34:43 | dtroyer | —dhcp | |
| 17:34:59 | reedip | dtroyer ; thats my question, does it have to be an option? | |
| 17:35:07 | dtroyer | otherwise w echange the resource name from "network agent" to "dhcp agent" or omething like that, then deal with the explosion of commands | |
| 17:36:08 | reedip | dtroyer : oh ok, got it. The agent-id will be used with the Optional flag | |
| 17:36:19 | reedip | and that would make our complete agent | |
| 17:37:01 | dtroyer | no, the option is stand-aline | |
| 17:37:15 | dtroyer | agent id is a positional argument | |