19:02:12 <dtroyer> #startmeeting openstackclient
19:02:13 <openstack> Meeting started Thu Mar 30 19:02:12 2017 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:16 <openstack> The meeting name has been set to 'openstackclient'
19:02:23 <dtroyer> Howdy all!
19:02:32 <ankur-gupta-f4> heyo
19:02:37 <rabel> hi :)
19:03:33 <dtroyer> OK, let's get started…
19:04:02 <dtroyer> #topic reviews
19:04:18 <dtroyer> I've got two things here, do you guys have any?
19:04:27 <ankur-gupta-f4> Just L3 Router commands
19:04:31 <rabel> i think i have one
19:04:42 <ankur-gupta-f4> https://review.openstack.org/#/c/385729/
19:05:24 * dtroyer refreshed what he said last week
19:05:51 <ankur-gupta-f4> :|
19:06:04 <rabel> ?
19:06:19 <dtroyer> my comemnts on the review
19:06:38 <dtroyer> ankur-gupta-f1: those list commands look a lot more like I'd expect at first glance, thanks
19:06:55 <ankur-gupta-f4> yea it was a naming thing where i kept same function names from first iteration
19:07:52 <dtroyer> I'll look in detail later, anything else to say on that one?
19:08:16 <ankur-gupta-f4> nope.
19:08:20 <rabel> no
19:08:39 <dtroyer> rabel: what do you have?
19:08:43 <rabel> https://review.openstack.org/#/c/444924/
19:09:35 <rabel> dtroyer you had some comments and i uploaded a new patch set last week.
19:10:03 <ankur-gupta-f4> I like the idea but would have to look closer about the implementation. will put on my todo list
19:10:10 <rabel> also there is a hint from reedip, that it's better to use MultiKeyValueAction for this, but i think it's better to switch to this class together with --nic.
19:10:39 <dtroyer> ok, I wasn't sure of the context on that comment...
19:11:39 <dtroyer> my biggest concern was handling nova-net properly
19:12:54 <rabel> dtroyer: i did not look at that closely, because i just reuse the nics variable, that is also used by --nic
19:13:07 <dtroyer> and it looks like there are still unconditional calls into network API
19:13:31 <dtroyer> I didn't think about that, is —nics neutron only?
19:13:55 <rabel> i don't know
19:14:24 <rabel> which unconditional calls do you refer to?
19:14:40 <rabel> is this the self.app.client_manager.network stuff?
19:14:49 <dtroyer> ok, I see it now
19:15:00 <dtroyer> line 633 is what I missed
19:15:08 <dtroyer> where it decides nova-net or neutron
19:15:08 <dtroyer> good
19:15:15 <rabel> ah ok
19:15:31 <dtroyer> the next thing is to handle the microversions properly, but you don't have to hold this up for that
19:16:09 <rabel> could you explain that briefly?
19:16:52 <dtroyer> the 'none' and 'auto' support rely on a Nova microversion
19:17:14 <dtroyer> there is no support yet to properly detect and do the right thing for those
19:17:47 <dtroyer> that's actually what I'm working on now, setting up the novaclient.Client we build properly
19:18:04 <rabel> i see
19:18:32 <dtroyer> I've been heads-down on that and the auth problem Monday and let things pile up a bit, apologies
19:19:17 <dtroyer> nice segue… https://review.openstack.org/451618 is the POC
19:20:01 <dtroyer> The idea is to borrow some things from novaclient, generalize it as necessary for cinder and ironic and stuff the really common bits into keystoneauth
19:20:31 <dtroyer> this is just step 1, but it'll make our nova client object behave properly now
19:21:03 <dtroyer> one question I have though, when the OS_COMPUTE_API_VERSION is set to '2', what should we do?
19:21:35 <dtroyer> we tried a while back to make that mean 2.latest (in nova terms) but that doesn't actually work and is a change from previous behaviour
19:21:51 <dtroyer> right now we're getting effectively 2.1 all of the time
19:22:15 <dtroyer> unless OS_COMPUTE_API_VERSION is specifically set by the user or in clouds.yaml
19:22:47 <dtroyer> so the question is, do we want that change to work or should we preserve the current behaviour?
19:23:37 <rabel> so one option is always 2.1 and one option is always 2.latest?
19:24:41 <dtroyer> yes.  first is current, second is what nova cli does and what we tried to do.  but its a potentially breaking change
19:25:00 <dtroyer> oddly enough, the Nova docs say "don't use latest" in a client :)
19:25:17 <rabel> :D
19:26:35 <dtroyer> anyway, I opened https://bugs.launchpad.net/python-openstackclient/+bug/1677372 for this if you have opinions
19:26:35 <openstack> Launchpad bug 1677372 in python-openstackclient "Compute API version defaults to '2.1' not '2.latest'" [Undecided,New]
19:26:51 <ankur-gupta-f4> ideally we would want to take the latest
19:26:59 <ankur-gupta-f4> unless specified 2.1
19:27:51 <dtroyer> I think so too
19:28:30 <ankur-gupta-f4> we should warn that there may be breakages in the near future and to report any bugs found
19:30:26 <dtroyer> I want to do a 4.0 this summer, this may wait for then too.  I'm piling up a wishlist of potentially-breaking stuff for that
19:30:50 <dtroyer> which also means things on that list need to have good testing now to we can see what actually does change
19:31:24 <ankur-gupta-f4> etherpad?
19:31:37 <rabel> "wishlist of potentially-breaking stuff" sounds funny. ;) but i like the idea to wait with this kind of change for 4.0
19:32:08 <dtroyer> given the talk around API stability lately it all sounds funny
19:32:19 <dtroyer> no etherpad yet, on the list :)
19:32:26 <dtroyer> The other things I wanted to bring up here is the fix for the functional-tips jobs: https://review.openstack.org/#/c/450453/
19:32:52 <dtroyer> its cousin is in osc-lib: https://review.openstack.org/#/c/450452/
19:33:15 <dtroyer> I think we need both for the fix so I'm ready to just merge them, would like a sanity check on the OSC one
19:33:47 <dtroyer> RuiChen mentioned that those may not be complete this morning for some combination of master and release osc, osc-lib and os-client-config
19:34:17 <dtroyer> but we need this to release a new os-client-config no matter what…
19:36:14 <dtroyer> anything else?
19:36:30 <ankur-gupta-f4> i got nothing. Just struggling with octaviaclient right now
19:36:51 <dtroyer> #topic open discussion
19:36:51 <rabel> i have nothing more
19:37:38 <dtroyer> Something else I saw this week was that novaclient will be removing security group and floating IP bits from the lib in their upcoming 8.0 release, breaking us rather badly
19:37:58 <ankur-gupta-f4> oh
19:38:06 <ankur-gupta-f4> what was the reason behind that decision
19:38:09 <dtroyer> I've started re-implementing those in the style of openstackclient.api.*
19:38:23 <dtroyer> they have been deprecated and no longer used.
19:38:45 <dtroyer> except clients have a much longer cycle time, we still have nova-net in supported releases, and many in operation
19:39:02 <dtroyer> so we're going to support that one way or another
19:39:09 <dtroyer> and the SDK isn't ready for that yet
19:40:12 <dtroyer> I'll push up a POC for the security group CRUD commands soon then maybe we can get folk working in parallel...
19:40:47 <ankur-gupta-f4> +1
19:40:55 <dtroyer> worst case we'll ask to cap novaclient < 8.0 in upper-constraints
19:42:04 <ankur-gupta-f4> g2g. Thanks Dean.
19:42:24 <dtroyer> anything else?
19:42:27 <rabel> yes
19:43:00 <rabel> i would like to implement "router show" to not only show gateway info, but also information on interfaces. see https://bugs.launchpad.net/python-openstackclient/+bug/1675489
19:43:00 <openstack> Launchpad bug 1675489 in python-openstackclient "router show should include interfaces" [Undecided,New]
19:43:07 <rabel> what do you  think about that?
19:44:38 <dtroyer> there is an issue with output formats to list s single resource and one or more sub-resources like that.  it's ugly to represent in prettytable and really hard in CSV.  JSON works well, but we don't do it right
19:45:20 <dtroyer> I think we have used an option on a show command to get more details, but which one escapes me just now
19:45:40 <dtroyer> and of course, some already do that where the list is returned in the primary resource object.
19:45:43 <dtroyer> is that the case here?
19:46:22 <rabel> i don't understand
19:46:27 <dtroyer> if that is really embedding an 'interface list —router' command in router show I'd want to think harder about it
19:46:47 <dtroyer> does the router object returned by the server contain the list of interfaces?
19:47:04 <rabel> ah. i don't know.
19:47:20 <amotoki> no at now. it just contains external gateway information
19:47:27 <dtroyer> if it does, add it to the show output and we'll deal with the formatting like all of the others
19:47:41 <dtroyer> ok, so that's really a second command to filter an ointerface list by router
19:47:54 <rabel> but what would be the first command?
19:48:06 <rabel> there is no "interface list"
19:48:32 <rabel> or would it be the same as "port list --router"?
19:48:33 <dtroyer> so right now we have no way to see what the connected interfaces are on a router?
19:48:33 <amotoki> openstack port list --router <router>
19:48:42 <dtroyer> yeah, that's it
19:49:07 <dtroyer> so I really wouldn't want to add that to router show
19:49:12 <rabel> ok
19:49:31 <rabel> but still...
19:49:49 <rabel> if you are looking for interfaces, "port list" does not come very intuitively
19:50:02 <rabel> because of the two different terms
19:50:27 <dtroyer> should we call router interfaces router ports instead?
19:50:35 <dtroyer> or netowrk ports?
19:51:00 <amotoki> yeah... previously 'neutron router-port-list' can be used for this purpose, so users can find the command by "neutron help | grep router", but now....
19:51:17 <amotoki> I am not sure what is userfriendly...
19:51:52 <dtroyer> I think it would be to use the right words around the router to help them find where to go next
19:52:23 <dtroyer> at the least we may want to sneak in the right words into the help
19:52:29 <rabel> yes, it's difficult. because inteface in this case is not only port, but "port on router that is not gateway"
19:53:38 <dtroyer> in my (outdated?) network terminology, that seems like an empty set
19:54:01 <dtroyer> router == gateway, the only port that isn't that on a router is the console and span ports :)
19:54:28 <dtroyer> obvioudly that isn't still true here
19:54:36 <dtroyer> obviously
19:54:48 <rabel> well, yes. maybe "port on router that is not connected to an external gateway"? ;)
19:55:06 <dtroyer> where external is defined by default route?
19:55:35 <rabel> i think so
19:55:38 <amotoki> a router connects to multiple networks, so the router has many ports.
19:55:57 <amotoki> "gateway port" means a port connected to default gateway
19:56:14 <dtroyer> so the default route defines that.
19:56:28 <amotoki> other ports are connected to tenant networks
19:57:13 <dtroyer> are the ideas about STP and routing protocols present here too?  do we build multiple default route networks?
19:57:31 <dtroyer> I don't know how much of this is supported by Neutron
19:58:19 <dtroyer> like, does anyone use OSPF or RIP in neutron networks?
19:58:19 <amotoki> IIRC it is not supported by current neutron
19:58:39 <dtroyer> so it's really just leaf routers
19:58:55 <amotoki> some stuff around BGP is implemented but it is a bit different context.
19:58:55 <dtroyer> err, I guess 'edge' is the current term
19:59:01 <amotoki> yeah
19:59:18 <amotoki> we use 'leaf switch' and 'edge router' usually
20:00:01 <dtroyer> BGP is fun, and I was never quite sure why it was used for an IGP
20:00:28 * dtroyer is having quagga flashbacks now
20:00:40 <amotoki> :)
20:01:10 <dtroyer> all that said, can we solve the issue between the right filters on port list and figuring out how to get from 'router interface' to 'port'?
20:01:40 <dtroyer> and we're out of time…
20:01:45 <dtroyer> thanks everyone!
20:01:53 <rabel> :D
20:01:53 <dtroyer> continue in -sdks if necessary
20:01:56 <rabel> thank you
20:01:58 <dtroyer> #endmeeting