| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-01 | |||
| 09:25:53 | reedip_ | checking the External Network issue ( I have updated my branch to master for SDK and OSC ) | |
| 09:27:46 | amotoki | reedip_: what versions (SDK/OSC) do you use? | |
| 09:28:00 | reedip_ | amotoki: 0.9.13, 3.8.1 | |
| 09:28:05 | reedip_ | thats as per pip freeze | |
| 09:29:13 | reedip_ | I am redeploying the devstack . And will retry the CLIs just to be doubly sure | |
| 09:37:51 | openstackgerrit | Qiming Teng proposed openstack/python-openstacksdk master: Add wait_for_xxx methods to cluster proxy https://review.openstack.org/439490 | |
| 09:48:31 | amotoki | reedip_: I checked the latest patch set locally and confirmed it works. | |
| 09:48:41 | amotoki | reedip_: one question remaining on the class name. | |
| 09:49:17 | amotoki | reedip_: currently SetFloatingIP is used for the class name. I wonder what class name is used when we have 'floating ip set' command in the future. | |
| 09:50:48 | reedip_ | amotoki : I am not sure about your query. Isnt the current Class name "SetFloatingIP" used for floating ip set CLI ? | |
| 09:52:09 | amotoki | reedip_: assume we have both 'openstack floating ip set port' and 'openstack floating ip set' in future | |
| 09:52:31 | reedip_ | amotoki : ok . Now its clear | |
| 09:52:35 | amotoki | reedip_: we currently use 'SetFloatingIP' for the former. what class name should be used for the latter. | |
| 09:53:01 | reedip_ | amotoki : how about keeping the same class name but using --port for setting the Port IP | |
| 09:54:21 | amotoki | reedip_: that is one option. | |
| 09:54:41 | amotoki | reedip_: I do not know the background why we chose 'floating ip set port' rather than 'floating ip set' | |
| 09:55:29 | reedip_ | amotoki : we had floating ip port associate/disassociate | |
| 09:55:50 | reedip_ | amotoki : but the actions ( associate /disassociate ) were not conforming with the Rules defined in OSC | |
| 09:56:00 | reedip_ | thats why it was proposed to move them to set / unset | |
| 09:56:16 | reedip_ | amotoki: but now this makes more sense to have port as optional | |
| 09:56:35 | reedip_ | amotoki: to keep floating ip set available for other operations | |
| 09:56:58 | reedip_ | amotoki : Can you send the neutronclient to OSC google sheet ???? Please :) | |
| 09:58:56 | reedip_ | amotoki: got it never mind :) | |
| 10:02:31 | amotoki | reedip_: if we choose 'floating ip set port' as command name, users can easily know what we are doing and --port is a required parameter. | |
| 10:02:47 | amotoki | reedip_: this is the merit of the current proposed command name. This is my understanding. | |
| 10:03:24 | amotoki | reedip_: do you need the link of my google spreadsheet? | |
| 10:03:30 | reedip_ | amotoki : yes, but if we remove port, and keep the --port option,( i.e. floating ip set --port) still they will know that the port is being set with the floating ip | |
| 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 | reedip_ | amotoki: Currently , there is no SET option in NeutronClient for Floating IP | |
| 10:04:33 | amotoki | reedip_: honestly my current vote is 'set port' :) | |
| 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/ | |