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