15:01:46 <sdague> #startmeeting service-catalog-tng
15:01:46 <openstack> Meeting started Thu Feb 18 15:01:46 2016 UTC and is due to finish in 60 minutes.  The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:50 <openstack> The meeting name has been set to 'service_catalog_tng'
15:01:55 <cdent> o/
15:01:58 <sdague> bknudson_: ?
15:02:06 <sdague> may be very short
15:02:39 <sdague> #info service-types-authority repo has been created in gerrir
15:02:46 <cdent> huzzah
15:03:00 <sdague> we probably need an initial commit to get things rolling, I can do that tomorrow, unless you want to cdent
15:03:11 <cdent> my stack is deep today
15:03:13 <bknudson_> oops, I'm here.
15:03:54 <bknudson_> need link to agenda
15:04:14 <sdague> #link https://wiki.openstack.org/wiki/Meetings/ServiceCatalogTNG
15:04:28 <sdague> #topic JSON Schema for SC
15:04:34 <bknudson_> thanks!
15:04:43 <sdague> I was bad, and did not look at the schema this past week
15:04:52 <cdent> bknudson_: I buried some comments deep in the commits, did they hit your radar?
15:05:10 <bknudson_> cdent: I found them.
15:05:34 <bknudson_> #link http://git.openstack.org/cgit/openstack/service-types-authority/
15:05:44 <bknudson_> oh, we've moved on already
15:06:19 <sdague> bknudson_: ok, what more do you need to move forward? More comments?
15:06:28 <sdague> is this something that's at the point to drive an ML discussion
15:06:40 <bknudson_> #link cdent's comments: https://github.com/brantlk/service-catalog-schema/commit/8c44f18893a789ca6c9d4cf9c720e8a86f556aa1#commitcomment-16102155
15:06:50 <bknudson_> let's move on to the next topic.
15:07:08 <bknudson_> I think that will be more fruitful
15:07:21 <sdague> #topic Requirements for SC:TNG
15:07:32 <sdague> #link - https://etherpad.openstack.org/p/service-catalog-requirements
15:07:58 <bknudson_> so, might be worthwhile to take a look at this for a few minutes
15:08:14 <sdague> I think that's actually a pretty nice break down
15:08:15 <bknudson_> I was trying to come up with what the requirements actually are then we can make a schema that meets the requirements
15:09:05 <bknudson_> one thing that I got hung up on is the relationships between the objects
15:09:17 <bknudson_> for example, does a region have services? or endpoints?
15:09:35 <bknudson_> the schema is complicated.
15:09:52 <sdague> I think a region has to have endpoints
15:10:03 <sdague> because not all versions of all services might be in all regions
15:10:42 <sdague> interface is an overloaded term, though I'm trying to come up with a better one
15:12:58 <sdague> I put a couple of comments in the etherpad on those points
15:12:59 <cdent> I thought we wanted to deprecate versioned endpoints and use version discovery _at_ the endpoint (but maybe I'm misremembering, a lot of ideas get discussed, but not finalized):  "use the service catalog to find the versioned endpoint"
15:13:15 <sdague> cdent: bknudson_ and I chatted about it
15:13:25 <bknudson_> y, we did "want" to.
15:13:28 <sdague> I think that a lot of devs wanted to do that
15:13:41 <sdague> in reality all the consumers know the major version they need
15:13:46 <bknudson_> although "want" and what we can accomplish are probably not in agreement in this case
15:13:55 <sdague> so we ended up with volumev2
15:13:59 <cdent> ah, yeah, well, yeah
15:14:01 <cdent> feh
15:14:02 <sdague> because people actually needed that
15:14:07 <cdent> (reality)--
15:14:15 <sdague> so we should not disregard the need
15:14:21 <cdent> true
15:15:03 <sdague> I think the idea of supporting both is a good one, and will let us dig out of volumev2
15:15:08 <bknudson_> the amount of code required to do version discovery is pretty significant. Although we provide a library we should support a simpler interface.
15:15:38 <bknudson_> so what I propose for the NG catalog is we provide the versioned endpoints along with a "discovery" endpoint
15:16:00 <cdent> that's probably reasonable
15:16:02 <bknudson_> and if everybody loves the "discovery" endpoint we can eventually switch away
15:16:06 <sdague> yep
15:16:12 <sdague> ok, great
15:16:43 <sdague> bknudson_: what more do you need / want before we start floating this to a wider audience to get buy in?
15:17:10 <bknudson_> do we want to have a full proposal or get buy-in on the pieces?
15:17:21 <bknudson_> because we don't have a schema at this point.
15:17:38 <sdague> right, so I'd say lets try to get to a schema
15:17:53 <sdague> because that will be easier to discuss
15:18:03 <bknudson_> after the list of definitions I tried to come up with a sample catalog
15:18:17 <bknudson_> but this was proving difficult since I didn't know the relationships
15:18:33 <bknudson_> so I had a region in a service, service in a region, ... ???
15:18:53 <sdague> hmm... we had a note about that originally
15:19:04 <sdague> today regions are buried in services right?
15:19:14 <sdague> I think that confused people, because they know their region
15:19:17 <bknudson_> a region is something that a cloud sets up
15:19:24 <bknudson_> you have the "US-East" region
15:19:28 <bknudson_> and the "US-West" region
15:19:49 <bknudson_> and I guess you can have different deployments in each region
15:20:02 <bknudson_> so you have 1 keystone, but a nova in E and nova in W
15:20:27 <bknudson_> and E nova could be liberty while W nova is master
15:20:34 <bknudson_> I assume that's supported
15:21:08 <bknudson_> you could have nova-networking in W and neutron in E
15:21:17 <sdague> right, but today's hierarchy puts it the other way around - https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
15:21:28 <sdague> so I think all the feedback was that region should be the top container
15:21:48 <sdague> and regions have endpoints
15:21:49 <cdent> how does someone "know" their region?
15:21:50 <bknudson_> that makes more sense to me.
15:22:03 <sdague> cdent: because that was handed to them
15:22:09 <sdague> they kind of have to know that up front
15:22:31 <cdent> thanks, that was pretty much my question: if that's the one piece of knowledge we know up front, then that's the top container
15:23:06 <bknudson_> ok, what's after region?
15:23:17 <sdague> yeh, and it seems like we should probably have a sane fall back for "I only want 1 region"
15:23:33 <sdague> bknudson_: regions have endpoints I think
15:24:14 <sdague> or I guess you could do region -> service (keyed by type) -> endpoint -> interface
15:24:36 <sdague> I'm unsure if nesting service -> endpoint is better than endpoints just having a service
15:24:41 <sdague> as an attribute
15:24:54 <cdent> presumably we want to model this in terms of how people will use it
15:25:05 <cdent> I have a region, now I want a 'compute'
15:25:24 <cdent> a compute has the following endpoints, I want the internal one
15:25:25 <sdague> right, and at some level flat is easier because you have all the info about a thing
15:25:25 <cdent> right?
15:25:52 <sdague> because I expect a bunch of the time you are going to show up with all the data and ask for an answer
15:26:14 <sdague> service://region1/compute/2.1/internal
15:27:10 <sdague> realistically that's how I imagine the config will be for neutron encoding the nova endpoint
15:28:49 <sdague> any other thoughts on that?
15:28:49 <bknudson_> so do you want versions under services?
15:28:56 <bknudson_> or does it get flat under services?
15:29:05 <bknudson_> see line 37 in the etherpad
15:30:44 <cdent> (aside: I _hate_ lists of anonymous dicts. Presumably I have some query I know I want to make, now I need to search through a list to satisfy it, I'd rather  have a dict)
15:31:06 <sdague> cdent: ok, that's fair
15:31:22 <cdent> If we dict by version, how do we representate the unversioned?
15:31:33 <sdague> right, also a good point
15:31:56 <sdague> in bknudson_'s current schema he calls that discovery
15:32:04 <bknudson_> I gave it a special version name
15:32:07 <bknudson_> "discovery"
15:32:11 <cdent> that seems reasonable to me
15:33:00 <bknudson_> at line 64 is the example of a deeply nested sample
15:33:10 <bknudson_> template might be the right term
15:34:16 <bknudson_> let me put more info together
15:34:23 <bknudson_> the schema and some sample catalogs
15:34:25 <bknudson_> for next week
15:34:34 <sdague> so, I wonder if on interface we should actually have 'default' and then other special kinds
15:35:01 <sdague> because I get concerned about people asking for 'internal' on clouds that don't do that differently
15:35:53 <bknudson_> well, we already say the public one is always present
15:36:03 <sdague> sure, but don't call it public, call it default
15:36:04 <bknudson_> so that makes it the default implicitly
15:36:26 <sdague> it might make people less likely to specify other ones ... maybe?
15:36:37 <cdent> yeah words like "public" and "internal" are fraught with weird
15:37:06 <bknudson_> I think public is pretty clear that this is one that's accessable over the public internet
15:37:26 <bknudson_> although I guess not all deployments are going to be internet-accessible.
15:37:30 <sdague> right
15:37:39 <sdague> and public might be fine on internal network as well
15:38:08 <sdague> I do get it's semantics, but it is useful to set up the defaults as 'you should have one'
15:38:17 <sdague> and only do more if you really need
15:38:40 * cdent nods
15:38:55 <sdague> ok, I've got a bit of a hard stop at 15 of, so what do we need here to make progress for next week?
15:39:12 <bknudson_> I've got enough
15:39:15 <sdague> ok, great
15:39:20 <bknudson_> I'll make a schema based on what we talked about here
15:39:34 <bknudson_> and some sample catalogs
15:39:49 <bknudson_> then we can discuss next week
15:39:49 <sdague> sounds great, and we can review those by / during next week's meeting
15:39:51 <sdague> yep
15:39:55 <sdague> awesome, thanks much bknudson_
15:40:00 <bknudson_> no problem
15:40:17 <sdague> #topic Service registry
15:40:28 <sdague> ok, we got the git repo built
15:40:39 <sdague> #action sdague to put initial commit in tomorrow to get rolling
15:40:48 <bknudson_> #link http://git.openstack.org/cgit/openstack/service-types-authority/
15:41:05 <sdague> the review team is api-wg + bknudson_, cdent, sdague, annegentle
15:41:35 <sdague> #topic Project Id Optionality in projects
15:41:42 <sdague> Tempest patch needed - https://review.openstack.org/#/c/271467/ - ETA TBD
15:41:46 <cdent> I'm api-wg core now, so that's me in there twice (in case it matters)
15:42:04 <sdague> mtreinish: has said that's fine to move forward, I still need to follow up on an email
15:42:14 <sdague> #topic Open Discussion
15:42:27 <sdague> any last bits before we close out?
15:43:13 <sdague> ok, thanks folks, will talk to you all over the week
15:43:15 <sdague> #endmeeting