15:02:40 <sdague> #startmeeting service-catalog-tng
15:02:40 <openstack> Meeting started Thu Feb 11 15:02:40 2016 UTC and is due to finish in 60 minutes.  The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:43 <openstack> The meeting name has been set to 'service_catalog_tng'
15:02:45 <cdent> o/
15:02:47 <sdague> who is about?
15:03:03 <bknudson_> what's up?
15:03:13 <sdague> #link Agenda https://wiki.openstack.org/wiki/Meetings/ServiceCatalogTNG
15:03:39 <sdague> #topic Nova project_id optional
15:04:17 <sdague> #status still waiting on test removes - http://lists.openstack.org/pipermail/openstack-dev/2016-February/086218.html
15:04:17 <openstackstatus> sdague: unknown command
15:04:27 <sdague> #info still waiting on test removes - http://lists.openstack.org/pipermail/openstack-dev/2016-February/086218.html
15:04:39 <sdague> #topic Service Catalog Names
15:05:08 <sdague> that conversation on the list seems to have resolved, and I proposed a dedicated repository for this work
15:05:19 <cdent> good outcome, I think
15:05:21 <sdague> yep
15:05:29 <cdent> practical, actionable, forward moving and thinking
15:05:58 <sdague> I guess we'll need to think a bit about file format
15:06:18 <sdague> the only thing I know we need to support is more than one type allowed per project
15:06:21 <bknudson_> use JSONSchema
15:06:33 <sdague> bknudson_: it's not going to be json
15:06:41 <bknudson_> it doesn't have to be JSON
15:06:43 <sdague> because json doesn't support comments
15:07:06 <bknudson_> you can use JSONSchema on YAML (validation takes a dict)
15:07:22 <sdague> ok, well, I think english might be a better first attempt
15:07:47 <notmorgan> sdague: i meant to say something on the list, just wanted to be sure we didn't replicate the volumev2 or versioned things.
15:08:01 <cdent> One thing I think is critical that this file (or whatever it is) is have a definition of terms
15:08:12 <cdent> until we agree some of those defintions all this is playing with words
15:08:16 <notmorgan> sdague: i know we have it today, but hopefully we can move away from it. otherwise the ML topic sounded good as proposed.
15:08:53 <sdague> cdent: can you expand on that?
15:09:50 <sdague> bknudson_ / cdent - honestly I was kind of thinking something as simple as this - https://etherpad.openstack.org/p/service-registry-format
15:09:51 <cdent> We don't have a lot of terms, maybe just one, but we need to make sure that "service type" (I think that's the term or art, yes?) is described effectrively: what it is, where it will be used, why it is used for that.
15:10:04 <sdague> ok, sure, so we need a GLOSSARY
15:10:07 <sdague> that's fine
15:10:41 <sdague> do you want to throw any thoughts on that into https://etherpad.openstack.org/p/service-registry-format - and we can seed the first few commits from there?
15:10:45 <cdent> that format seems reasonable to me, leaves room for comments
15:10:52 <cdent> sure
15:11:04 <sdague> notmorgan: my intent is not to codify any of the volumev2 bits
15:11:12 <sdague> because, I agree, that's all goofy
15:11:15 <notmorgan> sdague: yay.
15:11:34 <bknudson_> didn't we have 2 services where the type was telemetry?
15:11:34 <sdague> however, I do want to reopen the conversation about explicit version in endpoints, as a structured field
15:11:43 <sdague> bknudson_: we do, we're going to need to resolve that
15:11:47 <annegentle_> o/ sorry I'm late, prior meeting ran over
15:11:51 <sdague> it will be one of the sticky points
15:12:28 <notmorgan> i'm ok if we want to encode a version in the catalog as a structured (optional) field - however, i do prefer to encourage folks to use discovery
15:12:30 <sdague> notmorgan: because I think seeing the catalogs in the wild, it's clear people want explicit versions, they just hacked up service type to get there
15:12:55 <notmorgan> sdague: yeah we can't eliminate it. just as long as it's not overriding the URL or the service_type
15:13:08 <notmorgan> or that is must override url/service_type to get there
15:13:09 <annegentle_> sdague: but the catalogs in the wild were from devstack right?
15:13:25 <notmorgan> annegentle_: not all.
15:13:33 <annegentle_> ok
15:13:38 <sdague> notmorgan: yeh, agreed. Once this ball gets rolling I'll propose things on the ML about it
15:13:54 <sdague> trying to keep only so many uncommitted balls in the air at once
15:14:02 <annegentle_> sdague: I have a question about the service registry when it's appropriate to ask
15:14:03 <notmorgan> ideally it shouldn't be needed but it totally should be supported as a structured field. it saves having to ask 20 cinder endpoints if they are v2
15:14:25 <sdague> notmorgan: right, and a lot of software only works with 1 major version
15:14:26 <notmorgan> if you *must* work with a v2 endpoint for example. [future proofing]
15:14:45 <sdague> so it is nice to just be able to get that, instead of boiler plate a ton of discovery code
15:14:50 <sdague> in the client side
15:14:58 <sdague> annegentle_: fire away
15:15:17 <notmorgan> sdague: in most cases it wont eve rmatter but hey we'll get grumpy people w/o it. might as well make transitioning easyish
15:15:25 <annegentle_> I think in the service catalog spec, we said we'd use the projects.yaml as the first test. why does that not work?
15:15:37 <notmorgan> btw i am here for ~20mins then off to the dentist so.. just figured i'd drop in for the meeting :)
15:15:49 <annegentle_> ah, the dentist, good times :)
15:15:49 <bknudson_> the reason for the separate repo from projects.yaml was just so a separate group could merge?
15:15:58 <notmorgan> bknudson_: ++
15:16:01 <sdague> bknudson_: yes, pretty much
15:16:10 <annegentle_> ah, for governance
15:16:12 <annegentle_> sorta
15:16:26 <notmorgan> while this is under the purview of the TC [obviously], API-WG owns [according to the RFC] the repo
15:16:27 <annegentle_> I'd prefer we make the TC do it, but that's me.
15:16:28 <notmorgan> which i like
15:16:36 <sdague> as exposed in the thread, most people were fine for this being an API WG governed thing, with the TC only handling edge cases
15:16:43 <sdague> right, it's delegation
15:16:48 <bknudson_> who do you think is the consumer for the service registry?
15:16:48 <annegentle_> I wanted to talk more about it at this week's API WG meeting
15:17:03 <annegentle_> for example, this service registry is only for services
15:17:04 <cdent> annegentle_: yeah, I put it on the agenda there
15:17:12 <annegentle_> do we need to get into resources and where would that happen?
15:17:14 <notmorgan> bknudson_: two people: developers [ i have a new thing ], and deployers [i deployed a thing]
15:17:36 <annegentle_> What's nagging at the back of my mind is this is something that can be solved with a lookup, and the lookup should be the docs as source of truth.
15:17:39 <notmorgan> bknudson_: and end users can reference it if they want, but ideally it should be mostly transparent to them.
15:18:03 <annegentle_> cdent: yeah Everett and I talked about it too and said we'd discuss at the API WG meeting too
15:18:13 <annegentle_> cdent: so might be all of the agenda ha ha
15:18:31 <sdague> annegentle_: honestly, right now, we're trying to create a source of truth. And it seemed a bit simpler to do that in a dedicated space where it's clear this is all it is. Like IANAL port numbers
15:19:00 <annegentle_> "In a world where every service has to have API docs complete, we can all look for collisions before they happen."
15:19:18 <annegentle_> (that should be read in that movie guy's voice)
15:19:22 <sdague> heh
15:19:25 <bknudson_> he he
15:19:25 <notmorgan> annegentle_: hehe
15:19:34 <cdent> we'll sell you the whole seat, but you'll only need the edge
15:19:43 <annegentle_> so that's what I was thinking of -- not a new repo or effort but a further focus for API WG
15:19:51 <annegentle_> cdent: LOL omg
15:19:53 <notmorgan> cdent: oh is it going to be in 70mm too?
15:20:01 <notmorgan> cause i'll buy that ticket!
15:20:23 <sdague> annegentle_: the proposal is api-wg + this wg as the approval team
15:20:52 <cdent> So, yeah: I get the sense that the goals of the api-wg are very closely tied or even dependent on the success of the sctng
15:21:00 <sdague> so I don't see how this is in conflict with it being follow on api wg mission
15:21:08 <annegentle_> sdague: okay, still, if teams met higher expectations for dev experience earlier, would we be better off?
15:21:28 <bknudson_> once we get the data we can reformat it or move it around
15:21:34 <annegentle_> yeah, I think the blended teams are the ones who can get stuff done
15:21:40 <notmorgan> annegentle_: sure, but i don't think that is going to change this need really.
15:21:53 <sdague> annegentle_: that seems like an obvious yes, but I'm not sure how that's in conflict with a repo and a yaml file
15:21:57 <annegentle_> it's not
15:22:01 <sdague> ok
15:22:03 <annegentle_> and I'm not arguing against it, believe me
15:22:07 <sdague> ok
15:22:14 <cdent> violent agreement!
15:22:15 <annegentle_> I'm just asking if ...
15:22:17 <annegentle_> wait.
15:22:27 <sdague> cool, I'm just saying we start moving forward, do all the easy bits like 'compute' => nova
15:22:32 <annegentle_> I'm asking if the API docs were further along if we'd have these struggles.
15:22:34 <annegentle_> probably not.
15:22:38 <annegentle_> but wondering aloud
15:22:43 <sdague> annegentle_: maybe, maybe not
15:22:55 <sdague> we still need the registry
15:22:58 <annegentle_> for example, if we had a great api docs reference, discoverability of collision is easier
15:23:18 <annegentle_> but what I'm asking is whether collision at the resource level matters as much as service level
15:23:19 <notmorgan> annegentle_: i think we still need the registry, it's like an IANA thing as sdague said.
15:23:33 <annegentle_> I guess we are going in phases... first is service, then comes resources
15:23:40 <sdague> annegentle_: oh, right, that question
15:23:40 <annegentle_> which is all good
15:23:42 <notmorgan> oooh
15:23:51 <annegentle_> and I don't want to conflate or try to bite off more than chewable.
15:23:51 <notmorgan> uh the other thing.
15:23:54 <sdague> so, I had a conversation with jaypipes about that yesterday
15:23:58 <annegentle_> oh good do tell
15:24:08 <sdague> I think he was using 'top level resources' == 'service types'
15:24:20 <sdague> it was a naming problem
15:24:22 <notmorgan> sdague: oh that makes a lot more sense now.
15:24:48 <sdague> because compute/flavors dataprocessing/flavors is not actually confusing
15:25:10 <notmorgan> but calling it /flavors would be
15:25:20 <sdague> right, but it's scoped to a service
15:25:24 <annegentle_> yeah it's the context that matters, again a good docs site would show this to us.
15:25:28 * annegentle_ cries
15:25:29 <bknudson_> it would be great if we could view the whole of openstack as the interface, rather than separate interfaces like identity / compute / networking
15:25:43 <sdague> yeh, well, let's solve 1 problem first
15:25:49 <annegentle_> bknudson_: I think that's how jaypipes tries to get us to think -- and yeah users too
15:25:51 <cdent> annegentle_: I agree with you, but I also think achieving that kind of docs site in a big tent world is _really_ hard, so we need some granularity.
15:25:54 <notmorgan> bknudson_: i'm trying to slowly move us that way, this wg is def. part of that goal though
15:25:59 <sdague> and realize there are N more problems to solve
15:26:00 <annegentle_> cdent: yeah I agree, and ordering
15:26:19 <annegentle_> ordering of priority helps us eat the elephant
15:26:23 <notmorgan> bknudson_: but it is slooooow
15:26:31 <notmorgan> annegentle_: but i want to boil the ocean nowwww! :P
15:26:37 <annegentle_> anyway, we can talk more about it at the API Wg :)
15:26:37 <notmorgan> anyway.
15:26:38 <sdague> I also think top level service resource policing is a lot of work, for not a huge amount of benefit
15:26:39 <annegentle_> heh
15:26:48 <annegentle_> sdague: I know what you mean
15:26:50 <cdent> woot! I was waiting for someone to say "boil the ocean" :)
15:26:59 <notmorgan> cdent: happy to oblige
15:27:03 <sdague> structured error documents, for instance, would be so much more helpful to consumers
15:27:05 <bknudson_> could also say "rearranging deck chairs on the titanic"
15:27:10 <notmorgan> sdague: ++
15:27:14 <annegentle_> bknudson_: noooo
15:27:21 <cdent> bknudson_: slightly different conotation
15:27:29 <sdague> rearranging deck chairs on the hindenburg
15:27:51 <notmorgan> sdague: i... the huge manatee? /meme
15:28:04 <sdague> ok, anything else on service types?
15:28:11 <bknudson_> we need a few more cross-project workgroups
15:28:19 <notmorgan> i think the service_types are a solid starting place
15:28:27 <cdent> I'd like us to make sure we have some concrete (written down) goals for what we want this thing to enable or accomplish
15:28:29 <sdague> annegentle_: https://etherpad.openstack.org/p/service-registry-format - is the scratch pad
15:28:39 <cdent> But overall +1, let's get on with it
15:29:01 <annegentle_> ok, tahnks
15:29:07 <sdague> ok
15:29:09 <annegentle_> for what it's worth it's way better than tags :)
15:29:14 <notmorgan> sdague: +1 generally for thawt
15:29:20 <notmorgan> and pleaseeeee no tags :P
15:29:34 <annegentle_> please.........
15:29:37 <sdague> heh
15:29:56 <sdague> #topic JSON Schema for SC
15:29:58 <notmorgan> sdague: one last thing i want to toss on the pile to think about - no answer needed yet
15:30:06 <sdague> notmorgan: ok, go for it
15:30:25 <notmorgan> the concept of the service type being used as the mount-point for a service
15:30:30 <notmorgan> e.g. /compute /identity
15:30:32 <notmorgan> etc
15:30:36 <sdague> yes
15:30:52 <sdague> that will be recommended
15:30:52 <notmorgan> just something to mull over as a group while we're pondering this. if we want to codify that or not.
15:30:56 <notmorgan> great
15:31:03 <bknudson_> I started a github project to codify the service catalog schemas: https://github.com/brantlk/service-catalog-schema
15:31:13 <bknudson_> not sure if that was the best place, but needed some way to share it
15:31:22 <notmorgan> gh is goot enough to start imo
15:31:26 <annegentle_> oh for sure
15:31:28 <sdague> notmorgan: I think it's a thing we shouldn't say is required, because we do have this whole service catalog and all, but it does seem like a good recommendation
15:31:32 <bknudson_> so here's the v2 schema: https://github.com/brantlk/service-catalog-schema/blob/master/schemas/v2.yaml
15:31:46 <bknudson_> and here's the v3 schema: https://github.com/brantlk/service-catalog-schema/blob/master/schemas/v3.yaml
15:32:04 <bknudson_> and the next-gen schema: https://github.com/brantlk/service-catalog-schema/blob/master/schemas/ng.yaml (which is just the v3 schema for now)
15:32:07 <sdague> bknudson_: ok, cool, how do you want to take feedback on this?
15:32:09 <notmorgan> sdague: i would almost push for it to be the general case even if nova [for example] is the only thing on the host. but e can circle back on that.
15:32:17 <notmorgan> sdague: i'm 100% ok with "strongly recommended"
15:32:28 <cdent> notmorgan: (reasonable defaults)++
15:32:37 <bknudson_> sdague: how about for next meeting, take a look at it.
15:32:52 * notmorgan yeidls the floor.
15:32:54 <annegentle_> nice bknudson_
15:32:57 <sdague> bknudson_: sounds good
15:33:02 * notmorgan also type yields right this time.
15:33:11 <bknudson_> so what I did with this repo is I pulled all the sample catalogs from the wiki page
15:33:16 <annegentle_> does v2 correspond with v2.0 keystone api? what's the meaning there
15:33:20 <sdague> #action everyone take a look at bknudson_'s schema for next meeting - https://github.com/brantlk/service-catalog-schema
15:33:24 <annegentle_> oh i see, reading
15:33:29 <cdent> so now is probably as good a time as any to ask this question: why are there both a service type and a service name and can we just kill service name?
15:33:32 <sdague> we'll make that the frist agend ideam
15:33:37 <sdague> item
15:33:46 <bknudson_> and if you run test_catalog_schema.py it validates all the sample catalogs against the schema
15:33:59 <sdague> cdent: killing name is probably fine
15:34:07 <notmorgan> bknudson_: oh good, this can actually be used as a template-y thing for another thing i want to do.
15:34:16 <sdague> I think it was a dolphm original point
15:34:19 <notmorgan> sdague: we shoiuld kill name, it's not useful.
15:34:20 <bknudson_> so one way we can go -- create sample NG catalogs and update the NG schema.
15:34:28 <notmorgan> service_type is what matters.
15:34:31 * cdent is relieved he's not totally stupid
15:34:40 <annegentle_> I think showing examples is helpful
15:34:55 <sdague> yeh, I can get my head around samples much easier that the schema
15:35:00 <cdent> me too
15:35:02 <bknudson_> annegentle_: yes, the v2.0 catalog is what you get in a v2 token (from v2.0/tokens), and the v3 catalog is what you get in a v3 token (from v3/auth/tokens)
15:35:04 <annegentle_> dolphm would know/remember history
15:35:11 <sdague> the schema is good for machines, less for my brain
15:35:13 <annegentle_> ok thanks bknudson_ I think I know enough to review
15:35:23 <notmorgan> sdague: i believe it, cause even though i know whatthe catalog should be, it's hard to read the schema
15:35:24 <sdague> but this is looking good
15:35:31 <bknudson_> the v2 catalog is not compatible with the v3 catalog
15:35:46 <notmorgan> i expect the NG catalog to likewise be incompatible, sadly
15:35:53 <notmorgan> but ... expected and needed
15:36:04 <notmorgan> otherwise we'd carry cruft.
15:36:11 <sdague> bknudson_: also, are you really using yaml for jsonschema?
15:36:21 <sdague> that's almost really awesome
15:36:23 <cdent> I think that's great. so much more redable
15:36:27 <annegentle_> easier to write, right?
15:36:34 <sdague> and it can have comments!
15:36:40 <notmorgan> sdague: it wouldn't be hard to do it like that.
15:36:44 <bknudson_> sdague: yes, I went with YAML for the JSONSchema definition due to JSON not allowing newlines in strings!
15:36:47 * cdent sends praises to ingy
15:36:52 <bknudson_> I started with json and got sick of it.
15:36:52 <notmorgan> bknudson_: ++
15:37:00 <sdague> crap, I'm going to need to redo bits of nova this way
15:37:02 <notmorgan> json is GREAT for a wire thing
15:37:09 <notmorgan> but ends at the wire
15:37:10 <sdague> this is so much better
15:37:18 <sdague> bknudson_ gets the cookie for the day
15:37:24 <notmorgan> bknudson_: i think we should re-do keystone's validation like this ;)
15:37:31 <bknudson_> mmm cookies
15:37:38 <annegentle_> too crumby :)
15:37:43 <cdent> screw cookies, whole cake
15:37:48 <notmorgan> annegentle_: brownies?
15:37:50 <notmorgan> ;)
15:37:52 <annegentle_> gold star stickers and glitter!
15:38:03 <annegentle_> bknudson_ takes it up a notch!
15:38:05 <bknudson_> glitter gets everywhere
15:38:11 <annegentle_> heeee
15:38:15 <notmorgan> sdague: blame annegentle_ when someone asks why this channel; is covered in glitter.
15:38:25 <sdague> heh
15:38:35 <annegentle_> ok, you get the velociraptor Valentine's card!
15:38:39 * cdent fetches the disco ball
15:38:44 <notmorgan> ok anyway
15:38:54 <notmorgan> this is a good format :) yay
15:38:55 <bknudson_> so I think we should consider what we think is the "ideal" catalog
15:38:56 <sdague> ok, now that we're in full dance party mode
15:38:59 <annegentle_> cool
15:39:07 <annegentle_> great way to end a standup!
15:39:08 <bknudson_> and propose those as samples
15:39:15 <cdent> bknudson_++
15:39:28 <bknudson_> and, apparently, not even consider backwards-compatibility
15:39:31 <sdague> bknudson_: agreed, so maybe just throw up some PRs with ideas to rough things up at this point
15:39:33 <notmorgan> so i have one other question annegentle_, what was the result of the three urls/interfaces convo?
15:39:42 <notmorgan> since we're talking examples.
15:39:45 <sdague> notmorgan: we never really got resolution
15:39:59 <notmorgan> sdague: if at all possible i'd like to propose 2 urls to start then
15:40:05 <notmorgan> internal/public
15:40:13 <notmorgan> and if we need to expand back to admin, we can.
15:40:14 <sdague> I decided to pivot to more tractable problems
15:40:15 <cdent> the summit-based goal was 1
15:40:21 <cdent> was it not?
15:40:21 <bknudson_> I think we found that deployments were using them all?
15:40:38 <sdague> cdent: it was, the ops folks really wanted internal for billing reasons
15:40:54 <notmorgan> so, lets start with 2 and plan to add admin back in if it turns out really needed
15:40:59 <notmorgan> i know we can;'t do 1
15:41:11 <cdent> reality is such a pain
15:41:16 <sdague> cdent: heh
15:41:37 <sdague> ok, so for next week, come with comments on bknudson_'s current work, as well as what else we want in the ideal
15:41:48 <sdague> #topic Open Discussion
15:41:55 <sdague> any further things today?
15:42:05 <notmorgan> i was glan i was awake randomly for this. yay
15:42:12 <notmorgan> now i know when it is so i can be here next week too
15:42:33 <bknudson_> it's an early start for some
15:43:01 <sdague> ok, thanks for coming folks.
15:43:05 <sdague> #endmeeting