| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-01 | |||
| 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 | |
| 17:38:16 | ankur-gupta-f1 | http://paste.openstack.org/show/600983/ | |
| 17:38:21 | reedip | dtroyer ; U didnt get what I meant ( I was not clear :) ) . I understand that agent-id is the positional argument. Just that from the neutron's POV the agent-id and the agent-type would define the complete agent info | |
| 17:38:54 | dtroyer | ok, fair enough, I've only been thinking about the command structure, not implementation. | |
| 17:39:04 | dtroyer | that said, agent-id isn't uniqueue enough to identify it? | |
| 17:39:30 | reedip | dtroyer: agent id is unique enough ( being the UUID value ) | |
| 17:40:00 | dtroyer | good. I've been surorised about that sort of thing before, OpenStack is always finding new and unique ways to surprise me :) | |
| 17:40:10 | dtroyer | *surprised | |
| 17:40:31 | reedip | we have to fetch its type and verify if the passed option ( like --dhcp ) matches with the agent passed ( or else leave the handling to neutron server and wait for them[ in this case, maybe Us] to pop up :P ) | |
| 17:41:11 | dtroyer | without knowing much else, such as the specifics of the error that is returned, I would let Neutron validate the agent id | |
| 17:41:32 | reedip | ankur-gupta-f1 : so your proposal is to have "network agent add router" and "neutron agent add network " as 2 different CLIs ? | |
| 17:41:43 | dtroyer | unless that is something we can easily validate because we already have the information without another trip to the server | |
| 17:41:46 | reedip | dtroyer : yeah, neutron can do that | |
| 17:42:04 | ankur-gupta-f4 | reedip: yes | |
| 17:42:17 | reedip | dtoryer; No , we need to fetch the agent type from its ID from the server, so its better to let Neutron handle it, if possible | |
| 17:43:04 | reedip | ankur-gupta-f4 ( I am confused which ID is on ) : but using "network agent add --XXX" makes handling simpler , isnt it? | |
| 17:44:59 | ankur-gupta-f4 | reedip: how would you implement that. | |
| 17:45:37 | dtroyer | reedip: recall the structure of add/remove commands, with 2 resources | |
| 17:45:57 | reedip | dtroyer: yeah that thought crossed my mind | |
| 17:47:14 | reedip | ankur-gupta-f4 : do we need to keep separate resources for router and network ? | |
| 17:47:35 | reedip | my implementation may be wrong | |
| 17:48:05 | ankur-gupta-f4 | Yea. There should be 2 args when adding | |
| 17:49:34 | ankur-gupta-f4 | No need to overcomplicate | |
| 17:50:24 | dtroyer | network agent add XXX [[—<agent-type-option>] <agent-id> <XXX-name-or-id> | |
| 17:51:15 | sshank | dtroyer: +1 | |
| 17:52:10 | ankur-gupta-f4 | Yes. +1 | |
| 17:54:55 | reedip | yeah, kinda what I would like.. handling things in one go +1 dtroyer | |
| 17:57:48 | ankur-gupta-f4 | 30 min later we finalize the solution we came up with at the beginning 😞 | |
| 17:58:02 | ankur-gupta-f4 | Thanks for the feedback everyone | |
| 17:58:12 | ankur-gupta-f4 | sshank: we got work to do | |
| 17:58:46 | sshank | Thanks all. Finally a conclusion. :D \o/ | |
| 18:02:08 | ankur-gupta-f4 | sshank: u say that now | |
| 18:02:12 | reedip | ankur-gupta-f4 : HA HA HAAA | |
| 18:02:22 | reedip | :P | |
| 18:03:16 | ankur-gupta-f4 | sshank: expect heavy doses of -1s... mostly from me | |
| 18:03:20 | openstackgerrit | Merged openstack/python-openstackclient master: Auto allocated topology for OSC https://review.openstack.org/391331 | |
| 18:04:24 | reedip | ankur-gupta-f4 : can you review the floating ip set/unset | |
| 18:04:48 | ankur-gupta-f4 | Yea | |
| 18:04:52 | reedip | sindhu might just hit me with a broom otherwise :P | |
| 18:08:18 | sindhu | reedip: lol .... naaa i won't :D | |
| 18:11:03 | ankur-gupta-f4 | reedip: i gave a quick glance. Let me get back from lunch and take better look | |
| 18:11:42 | reedip | gn then .... have been sleep deprived since yesterday ! Catch you tomorrow | |
| 18:12:01 | ankur-gupta-f4 | Goodnight man | |
| 18:12:15 | ankur-gupta-f4 | Thx for helping out with the FIP stuff | |
| 18:14:37 | reedip | Now dont say such sweet things, I might just wake up in 2 hours ! | |
| 18:14:39 | reedip | :P | |
| 19:10:48 | openstackgerrit | Merged openstack/python-openstackclient master: Add Cinder v3 client support for volumes https://review.openstack.org/412614 | |
| 19:36:38 | openstackgerrit | Gage Hugo proposed openstack/keystoneauth master: Remove pbr warnerrors in favor of sphinx check https://review.openstack.org/439797 | |
| 19:37:33 | openstackgerrit | Gage Hugo proposed openstack/keystoneauth master: Remove pbr warnerrors in favor of sphinx check https://review.openstack.org/439797 | |
| 20:09:20 | JayF | /win 32 | |
| 20:09:23 | JayF | whoops :/ | |
| 20:50:35 | openstackgerrit | Gage Hugo proposed openstack/keystoneauth master: Remove pbr warnerrors in favor of sphinx check https://review.openstack.org/439797 | |
| 20:52:42 | openstackgerrit | Merged openstack/python-openstacksdk master: Add wait_for_xxx methods to cluster proxy https://review.openstack.org/439490 | |
| 20:57:02 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk master: Update devstack config to point to a valid image https://review.openstack.org/439847 | |
| 21:05:02 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce Neutron DHCP agent commands to OSC https://review.openstack.org/387611 | |
| 21:09:10 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce neutron flavor associate, disassociate to OSC https://review.openstack.org/403907 | |
| 21:20:29 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstackclient master: Jsonify meter and meter rule functional tests https://review.openstack.org/439854 | |
| 21:41:40 | openstackgerrit | Merged openstack/osc-lib master: Updated from global requirements https://review.openstack.org/439332 | |
| #openstack-sdks - 2017-03-02 | |||
| 01:20:42 | openstackgerrit | Merged openstack/python-openstacksdk master: Update devstack config to point to a valid image https://review.openstack.org/439847 | |
| 02:18:53 | openstackgerrit | Rodrigo Duarte proposed openstack/python-openstackclient master: Use *_as_ids instead *_as_list https://review.openstack.org/435972 | |
| 02:26:11 | openstackgerrit | Rodrigo Duarte proposed openstack/python-openstackclient master: Use *_as_ids instead *_as_list https://review.openstack.org/435972 | |
| 03:09:21 | openstackgerrit | Ankur proposed openstack/python-openstackclient master: Nit: Trivial doc formatting fix for network flavor https://review.openstack.org/439965 | |
| 04:24:44 | reedip_1 | ankur-gupta-f1 : 0/ | |
| 05:06:53 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/440102 | |
| 05:06:56 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstacksdk master: Updated from global requirements https://review.openstack.org/440103 | |