19:12:15 <dtroyer> #startmeeting openstackclient
19:12:16 <openstack> Meeting started Thu Nov 10 19:12:15 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:12:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:12:20 <openstack> The meeting name has been set to 'openstackclient'
19:12:28 <dtroyer> Logs are Good(TM)
19:12:33 <dtroyer> ankur-gupta-f: ok, what's up?
19:12:37 <ankur-gupta-f> https://review.openstack.org/#/c/385729/
19:12:53 <ankur-gupta-f> lets get this command resolved since DHCP to Network would be done the same way
19:13:04 <ankur-gupta-f> agents list --routers <agent-id> is confusing
19:13:18 <ankur-gupta-f> was considering agents show <agent-id> --routers
19:13:49 <dtroyer> first off, what resource do you want to appear in the list output?
19:14:46 <ankur-gupta-f> agents list --routers would return a list of routers. But the command requires the agent (name or ID)
19:14:52 <dtroyer> no
19:15:04 <dtroyer> 'routers list ' is how you get a list of routers
19:15:14 <dtroyer> if you want to filter that list, add options
19:15:20 <dtroyer> such as —agent <agent-id>
19:16:24 <ankur-gupta-f> okay. But the endpoint is still v2/agents/<id>  .
19:16:41 <dtroyer> we do not car about that at the CLI
19:16:45 <ankur-gupta-f> So we don't care about the background logic, just what is easiest to understand for an end user
19:16:51 <dtroyer> exactly
19:17:17 <ankur-gupta-f> makes perfect  sense. Okay will pass that info to Shashank who is running the dchp agent/network commands
19:17:25 <dtroyer> cool
19:17:28 <ankur-gupta-f> now also Meter Label Rule
19:17:34 <ankur-gupta-f> you want to get rid of Label
19:17:41 <ankur-gupta-f> just call it Meter and Meter Rule
19:17:49 <dtroyer> I don't know enough about those to know if that is reasonable
19:18:01 <ankur-gupta-f> armax: are you still around to provide input?
19:18:19 <dtroyer> but it didn't make sense to me to be adding rules to a lable (just at a conceptual level)
19:19:00 <ankur-gupta-f> It sounds reasonable to me. But should grab the input of someone more experience in the network domain
19:19:15 <dtroyer> so basically, is 'network meter' a different thing than 'network meter label'?
19:20:17 <ankur-gupta-f> Dont think it would be an issue
19:20:31 <dtroyer> ok
19:21:01 <ankur-gupta-f> final one. and this one is a weird one... Auto Allocated Topology
19:21:11 <ankur-gupta-f> https://review.openstack.org/#/c/391331/
19:21:57 <ankur-gupta-f> you are right. saying "openstack network auto allocated topology show" sounds clumsy
19:22:04 <dtroyer> that's an awkward name
19:22:17 <ankur-gupta-f> the spec also refers to it as "Get me a network"
19:22:21 <ankur-gupta-f> but thats not good either
19:22:27 <dtroyer> is 'network topology' something else in Neutron?
19:22:36 <ankur-gupta-f> yes
19:23:02 <dtroyer> ok.   I'd like to hear what the developers had in mind for the users to think about with this.
19:23:17 <dtroyer> it looks like a resource with CRUD operations, is there more?
19:24:34 <dtroyer> walking through the workflow that a user is expected to follow can be helpful in sorting out things like this
19:25:30 <dtroyer> also, 'network topology' is not already used in OSC, will it be in the future (apart from the auto-allocated case)?
19:25:38 <ankur-gupta-f> it is in progress
19:26:00 <ankur-gupta-f> https://review.openstack.org/#/c/358456/
19:26:01 <dtroyer> then 'auto-allocated' sounds like a special case of that
19:26:04 <sc68cal> is network topology related to routed networks in neutron?
19:27:29 <ankur-gupta-f> "**network topology** displays the virtual network topology.
19:27:29 <ankur-gupta-f> It collects data from existing REST APIs. This data includes the
19:27:29 <ankur-gupta-f> count of routers, dhcp agents and instances which connect to every
19:27:29 <ankur-gupta-f> network. It also gets more details about devices which connect to
19:27:29 <ankur-gupta-f> the specified network."
19:27:49 <dtroyer> so that isn't an actual resource
19:29:08 <ankur-gupta-f> yea im confused about the purpose of it
19:29:23 <sc68cal> does OSC have a history of new commands that don't map directly to resources an API provides?
19:30:02 <dtroyer> sc68cal: we do have some, and something like this is not out of like (see the upcoming project purge command)
19:30:19 <sc68cal> ok, works for me then
19:30:24 <dtroyer> but in this case it isn't particularly clear to me what this is doing
19:30:40 <ankur-gupta-f> I also see that Armando has commented he doesn't see the use of the network topology command.
19:31:03 <sc68cal> dtroyer: agree, at the very least it needs more clarity as to what it is doing
19:31:12 <dtroyer> I would rather not take up the 'network topology' resource name for something that isn't a resource if it means we make the auto-allocated one longer/worse
19:31:26 <sc68cal> network-visualize ?
19:31:38 <sc68cal> err network visualize
19:31:49 <dtroyer> I think armax's point is to get the base work done first, then come back to compound commands
19:31:57 <dtroyer> sc68cal: yes, more along those lines
19:32:13 <dtroyer> maybe with options to get more specific
19:32:56 <sc68cal> sounds good to me
19:33:04 <dtroyer> this is where losing Rich is going to slow things down, he was our Neutron knowledge base
19:33:34 <sc68cal> i can pinch hit for him I guess
19:33:55 <dtroyer> serious?  that would be awesome
19:34:24 <sc68cal> i'll add the repo to gertty and start lurking
19:34:45 <ankur-gupta-f> +1
19:35:28 <ankur-gupta-f> what is the final verdict on how to handle auto allocated topology, just shorten to network topology
19:36:03 <dtroyer> ankur-gupta-f: that's my preference, if that makes sense
19:36:26 <dtroyer> if there is more than one kind of topology, use options to specify type
19:36:39 <ankur-gupta-f> makes sense. I will provide a bit extra information in the help texts so users aren't confused
19:36:57 <dtroyer> anything else?
19:37:07 <ankur-gupta-f> Tag extension
19:37:48 <ankur-gupta-f> has already been implemented in neutronclient fully, but needs to be added as a plugin for osc into neutronclient. It seems repeated/redundant
19:38:05 <ankur-gupta-f> http://docs.openstack.org/developer/neutron/devref/tag.html
19:39:13 <dtroyer> I do have one question on network options: https://review.openstack.org/#/c/392457/
19:39:55 <dtroyer> —allowed-address-pair appears to have at most two components, and the mac address seems to be optional per the API spec
19:40:23 <dtroyer> can anyone verify that is true?
19:40:48 * sc68cal takes a look
19:41:17 <dtroyer> if so, I'd like to shorten the name and make the mac, and the labels optional: '—allowed address 1.2.3.4' and '—allowed-address ip-address=1.2.3.4' would be both accepted
19:41:30 <dtroyer> in addition tot he current form
19:42:20 <sc68cal> yeah it looks like ip_address is required, and mac is optional
19:43:08 <sc68cal> and ip address can be an IP or a subnet/cidr
19:43:15 <dtroyer> I thought about suggesting dnsmasq-style options, so an IP and a MAC would be usable without the labels:  1.2.3.4,aa:bb:cc:dd:ee:ff
19:43:41 <dtroyer> not sure how that sits with folks, can come later
19:43:57 <dtroyer> sc68cal: do you know how strict Neutron is on MAC formats?
19:44:15 <dtroyer> specifically, using ':' or '-' separators, or no spearators at all?
19:44:29 <sc68cal> I'll double check but I believe ":"
19:45:06 <ankur-gupta-f> dtroyer: sc68cal: gotta head out. But thanks for the input
19:45:23 <dtroyer> ok.  I'll add a re-formatter to the wishlist, enough other things have different formats that it might be nice to be able to handle the output directly
19:45:31 <dtroyer> ankur-gupta-f: thank you
19:46:14 <sc68cal> dtroyer: looks like we call netaddr 's mac validator directly
19:46:40 * sc68cal sighs
19:46:41 <sc68cal> https://netaddr.readthedocs.io/en/latest/api.html#mac-formatting-dialects
19:46:47 <sc68cal> "The following dialects are used to specify the formatting of MAC addresses."
19:46:51 <sc68cal> aaaaaand it's blank
19:47:06 <dtroyer> nice :)
19:47:23 <sc68cal> https://netaddr.readthedocs.io/en/latest/tutorial_02.html#formatting
19:47:29 <sc68cal> so looks like it takes quite a few
19:47:45 * sc68cal forks netaddr to fix docs
19:48:00 <dtroyer> good deal, I'll not worry about it in OSC then, thanks
19:48:13 <dtroyer> we should doc that somewhere in OSC though…
19:48:16 * dtroyer makes that note
19:49:08 <dtroyer> ok, anything else?
19:49:10 <dtroyer> anyone else?
19:49:17 <dtroyer> Buehler?
19:50:04 <dtroyer> ok, I'll be quick and end now…
19:50:12 <dtroyer> sc68cal: thanks for jumping in to our little fire
19:50:21 <sc68cal> no prob
19:50:25 <sshank> Need some reviews on my patches.
19:51:09 <sshank> can you please review my client patch: https://review.openstack.org/#/c/387611/
19:51:15 <dtroyer> sshank: specifics?  I've only gotten back to the queue in the last day or so since BCN…there are a few :)
19:51:28 <sshank> and SDK: https://review.openstack.org/#/c/387602/
19:51:35 <sshank> Thanks! :)
19:52:17 <dtroyer> I can look at the OSC one soon enough, but it can' be merged until the SDK change is released
19:52:37 <sshank> dtroyer, Ok.
19:52:45 <sshank> dtroyer, Thanks.
19:53:47 <dtroyer> sshank: since you are here, let's talk about the resource names a bit
19:54:05 <sshank> dtroyer, yes. Sure.
19:54:22 <dtroyer> 'network hosting dhcp-agents'
19:54:24 <dtroyer> what is that?
19:55:17 <sshank> dtroyer, I was thinking it will be equivalent to neutron client 'net-list-on-dhcp-agent'
19:55:43 <dtroyer> forget about neutronclient equivalents
19:55:52 <dtroyer> what is the 'thing' you are trying to list?
19:57:03 <sshank> dtroyer, To list DHCP agents hosted on a network.
19:57:59 <dtroyer> so 'dhcp agent list —netowrk <network-id>' maybe?
19:59:18 <sshank> dtroyer, Ok. I'll make the change.
19:59:23 <dtroyer> start with the resource that you want to list, then add the filters as options
19:59:38 <dtroyer> same with the network agent dhcp hosted-networks
19:59:59 <dtroyer> that seems like new filter options to network agent list
20:00:14 <dtroyer> and we're out of time
20:00:34 <dtroyer> sshank: if you want to keep talking about this, we're in #openstack-sdks
20:00:40 <dtroyer> Thanks everyone
20:00:45 <dtroyer> #endmeeting