15:03:24 <sdague> #startmeeting service-catalog-tng
15:03:25 <openstack> Meeting started Thu Dec 10 15:03:24 2015 UTC and is due to finish in 60 minutes.  The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:30 <openstack> The meeting name has been set to 'service_catalog_tng'
15:04:00 <sdague> #link Agenda - https://wiki.openstack.org/wiki/Meetings/ServiceCatalogTNG#Service_Catalog_TNG_Meeting
15:04:32 <sdague> ok, this is sparse and missing anne, so I'll try to provide some summary kickoff
15:04:47 <sdague> #topic overview
15:04:52 <sdague> #link https://wiki.openstack.org/wiki/ServiceCatalogTNG
15:05:23 <sdague> there is a service catalog main wiki page with what we are trying to do, which is mostly make the service catalog something that gets more used going forward
15:05:58 <sdague> the cross project spec - https://review.openstack.org/#/c/181393/ has some of the background on weirdnesses we currently have
15:06:29 <sdague> #topic Realistic Goals for Mitaka
15:06:53 <sdague> anne and I were discussing this the other day, and trying to establish what those goals would be
15:07:16 <bknudson> https://wiki.openstack.org/wiki/ServiceCatalogTNG#Mitaka_Goals ?
15:07:39 <cdent> (is it the case that, as usual, swift is special?)
15:07:39 <sdague> yes, that's our current best guess of things
15:08:10 <sdague> cdent: well, the project_id in swift is semantically meaningful
15:08:22 <cdent> yeah
15:08:24 <sdague> which is really not true for other projects
15:08:27 <bknudson> have we identified the projects?
15:08:49 <bknudson> that need the project_id removed
15:08:57 <agentle> o/ sorry I'm late
15:09:26 <ayoung> MEETING PARTY CRASHER
15:09:32 <ayoung> Sorry
15:09:48 <sdague> bknudson: I don't have the complete list, that would be a good thing to capture here. nova, and things that forked out from nova mostly
15:10:12 <sdague> #action need to capture authoritative list of projects that use project_id
15:10:30 <sdague> that could use a volunteer, if anyone wants to pitch in
15:10:53 <ayoung> sdague, notmorgan was doing a POC and identified the ones he tripped over
15:11:00 <ayoung> I think it might be a very short list
15:11:10 <sdague> ayoung: yes, it's not huge
15:11:13 <agentle> sdague: I think Thomas Goirand had one, I'll find it
15:11:18 <sdague> agentle: great
15:11:20 <ayoung> it really is only an issue if project_id is in the service catalog itselfm, and not in the URL
15:11:44 <sdague> ayoung: right, that's what I mean, if project_id is dynamically serviced by the service catalog
15:12:01 <ayoung> that we can tell by the SC generated by devstack
15:12:11 <ayoung> I only ever saw a problem with Nova
15:12:36 <ayoung> but I tend to do limited deployments...
15:13:10 <sdague> ok, so agentle can I sign you up for having the athoritative list by next week?
15:13:16 <sdague> or is there someone else that would like to volunteer for that?
15:13:24 <sdague> it's probably about 2 hrs worth of work tops
15:14:03 <agentle> sdague: Yep, by next week thurs.
15:14:11 <sdague> agentle: sounds great
15:14:37 <sdague> #action (annegentle)  capture authoritative list of projects that use project_id in catalog entries
15:14:39 <ayoung> how definitive tdoes this need to be? Everything in the Big Tent?
15:14:56 <agentle> ayoung: i'll use the list of service catalogs we gathered round the world
15:15:04 <agentle> #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
15:15:09 <sdague> ayoung: as authoritative as we can get it
15:15:50 <sdague> ok, given that the goals get somewhat duplicated in the next set of topics, lets go through the topics in order
15:15:57 <sdague> #topic Service Catalog Spec
15:16:31 <sdague> agentle: the update was on your plate, what additional things do you need before pushing the next update?
15:17:22 <sdague> agentle: ?
15:17:27 <agentle> sdague: I think we have a response for John er, notmyname, but I might update that vision section for the focus this release
15:17:32 <agentle> sorry slow typing this morning :)
15:17:37 <sdague> agentle: ok, no prob
15:18:11 <agentle> sdague: I can't get the eavesdrop for the first part, is the focus: project id and?
15:18:11 <sdague> agentle: ok, are you able to get things into shape by next meeting?
15:18:16 <agentle> sdague: ayup
15:18:41 <sdague> #action (annegentle) update service catalog cross project spec by next meeting
15:18:50 * agentle gets all the actions today
15:18:56 <sdague> well, so far :)
15:18:59 <agentle> heh
15:19:17 <sdague> #topic Project Id Optionality in projects
15:19:29 <sdague> ok, so we have the action for anne about building the complete list of services
15:20:07 <bknudson> next step is to get the projects to support no project id
15:20:14 <sdague> we've got a nova functional patch up https://review.openstack.org/#/c/233076/ that's mostly waiting on some refactoring of our in tree testing to get it landable
15:20:44 <sdague> #action check in on nova patch for next week's meeting
15:20:48 <bknudson> that his a lot of files
15:20:58 <sdague> I'm hopeful that is ready to go next week
15:21:25 <sdague> it's router changes in 3 files, and microversion bumps
15:21:54 <sdague> a microversion bump changes a constant in about 6 places in the tree, it's pretty small change really
15:22:14 <bknudson> looks pretty easy
15:22:18 <bknudson> devstack change, too?
15:22:29 <sdague> there is a devstack change to set the catalog as well
15:22:48 <agentle> sdague: and I wonder what docs will need updating
15:23:03 <sdague> #link https://review.openstack.org/#/c/233079/
15:23:16 <sdague> that's the devstack change, it works with that nova change
15:23:24 <bknudson> there's a novaclient change, too?
15:23:36 <sdague> bknudson: yes, it's already landed
15:23:43 <sdague> it was mostly about discovery
15:23:50 <ayoung> I wonder if this is going to be a problem with Policy enforcement.  If the projectID is dropped from the URL, is it possible that a check will also be dropped?
15:23:59 <bknudson> kind of scary, but whatever
15:24:21 <sdague> ayoung: do you have an example of where such a policy enforcement check is today?
15:24:37 <ayoung> sdague, I can show you nova's
15:24:43 <bknudson> ayoung: are you worried the project ID won't be in the context?
15:24:45 <sdague> ayoung: yeh, link would be great
15:24:53 <ayoung> so...not sure, but
15:24:55 <sdague> the project_id is still in the context
15:25:17 <ayoung> the token has a proj id that is used to generate the url...the url then has a project Id that needs to match that of the resource
15:25:24 <ayoung> say...and image or a vm
15:25:27 <sdague> the code in nova litterally only cared about project_id in url for 10 lines of code
15:25:45 <sdague> where it did a project_id == context.project_id or die
15:25:59 <sdague> and the url was fully ignored beyond that
15:25:59 <cdent> death++
15:26:17 <ayoung> right. that is important, though.  Still need a check like that, but it is not sufficient
15:26:17 <agentle> interesting
15:26:43 <sdague> ayoung: it's not though, because the acl is enforced on the uuid of the server as well
15:26:45 <ayoung> I need to think this through...I'll come back
15:26:59 <sdague> you can't just find someone else's uuid of server, put it under your project id, and delete it
15:27:15 <ayoung> sdague, meaning context.project_iod == server.proejct_id or die?
15:27:48 <sdague> so, I'd recommend looking at the nova patch directly if there are concerns there
15:27:57 <sdague> because I'm pretty sure things are fully covered
15:28:09 <sdague> ok, lets move on to next topic
15:28:11 <ayoung> I suspect it is fine, but we should be testing
15:28:18 <cdent> presumably there is test coverage for this sort of thing already?
15:29:15 <sdague> cdent: there is, we had to change a tempest test though because it was no longer possible to ask for servers by wrong project id when project_id is not in the url
15:29:36 <cdent> ✔
15:29:52 <sdague> we could determine if there is another test that's appropriate here
15:30:15 <sdague> cdent: anything you might want to look at? :)
15:30:21 <sdague> given you are diving into nova now
15:30:37 <ayoung> sdague, the token.project_id should be different from the one requested.  Suspect that is already tested
15:30:50 <sdague> ayoung: yes, already tested
15:30:50 <cdent> I'm hesitant to make any commitments just yet because I don't know the lay of the land, but this is definitely an area where I'm very interested
15:31:20 <cdent> So I'm trying to get myself oriented so I can safely say "yupppers, I'm on that"
15:31:24 <sdague> ok, no prob
15:32:00 <sdague> #action nova functional test to ensure we don't loose any safety in removing project_id from url
15:32:08 <sdague> we'll see who ends up with that
15:32:14 <sdague> ok, really next topic
15:32:21 <sdague> #topic What URLs are needed
15:32:35 <sdague> this is part of coming up with a draft schema for the service catalog
15:32:41 <cdent> I found the mailing list thread on this topic challenging to parse.
15:32:52 <sdague> today, we have 3 things: publicURL, adminURL, internalURL
15:33:19 <notmorgan> sdague: and unfortunately it's different dependint on the catalog version
15:33:22 <ayoung> do we have defintions of what is meant by those?
15:33:25 <sdague> #link http://lists.openstack.org/pipermail/openstack-operators/2015-December/009061.html
15:33:33 <bknudson> I think adminURL was only there for for keystone since we have admin and public APIs
15:33:39 <notmorgan> so really we have 6 iirc. :(
15:33:40 <bknudson> (in v2)
15:33:41 <sdague> there is an openstack operators thread on this
15:33:53 <sdague> notmorgan: ok, sure, well really we have N
15:34:03 <sdague> because that's all convention, and not enforced anywhere
15:34:08 <ayoung> OK.  I know what they are supposed to mean in Keystone.
15:34:23 <sdague> and as such gets used wildly inconsistently
15:34:45 <bknudson> I think operators like internalURL and publicURL for services. I want my internal users to use internalURL and outside users only have publicURL
15:34:47 <sdague> as can been seen by some of the responses there
15:34:58 <ayoung> THey are not such horrible ideas, but we should probably taylor the SC to return the right ones
15:35:01 <bknudson> maybe there's a better way to do internal/public access
15:35:16 <sdague> bknudson: honestly, it sounded like from that thread a lot of operators don't like the current split
15:35:29 <ayoung> bknudson, different hostnames is really the best option.
15:35:29 <sdague> bluebox uses hosts overrides
15:35:41 <ayoung> THat way you can have different interfaces on the same machine handle them
15:35:46 <ayoung> its a firewall issue
15:35:47 <sdague> to always get internal users to the right address
15:35:56 <sdague> for instance
15:36:10 <sdague> I would recommend everyone read and comment on the operator thread
15:36:10 <ayoung> different ports was always sketchy, but that was an impl detail we could work around
15:36:14 <bknudson> y, putting the knowledge in the network makes sense
15:36:29 <bknudson> since otherwise apps have to provide config options or know where they're running somehow
15:36:32 <sdague> #action (sdague) revisit operator thread try to reexpress current common themes
15:37:04 <ayoung> So, here is what they are supposed to mean, and this is not Keystone specific:
15:37:06 <sdague> I think the one thing that did arrise that was new was the desire that services have dedicated urls for them to talk to each other
15:37:08 <david-lyle> so I can say the HP Public Cloud (RIP) used adminURL for nova at least
15:37:17 <ayoung> Public is what users outside the firewall get for normal useage
15:37:27 <ayoung> admin is the same, but an higher level of control and security
15:37:41 <agentle> yes david-lyle same for Rackspace also
15:37:45 <david-lyle> certain extensions were only enabled when going through adminURL rather than public
15:37:46 <ayoung> some deployments want to put that inside dfirewall
15:37:59 <ayoung> internal is service to service
15:38:19 <bknudson> if HPE and RAX both find this useful/necessary then seems like we'd keep it?
15:38:21 <ayoung> We don't Need them per-se, as there are other ways to do the same thing, but this was not a horrible approach
15:38:35 <sdague> david-lyle: for keystone only, right?
15:38:49 <david-lyle> no for nova
15:38:51 <ayoung> However...we could also deduce which one to return based on the caller
15:39:04 <sdague> david-lyle: hmmm... it doesn't appear in the catalog that was captured
15:39:11 <sdague> https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog#HP
15:39:20 <ayoung> IE, the nova service user gets the right Keystone URL, and the right Glance url, both internal
15:39:20 <agentle> sdague: that catalog is the public one not the "I'm a cloud admin" one
15:39:39 <sdague> ah, ok, so you only get an adminURL if you are an admin?
15:39:54 <agentle> sdague: I'm not an admin on any cloud to test that theory :)
15:40:02 <david-lyle> that catalog is not from sufficiently empowered I think
15:40:11 <ayoung> sdague, so, I'm not certain about that.  It is more likely that is supposed to be location aware
15:40:35 <david-lyle> that's the end user view
15:40:35 <ayoung> if you are inside the firewall, and a regular user, I don't know which you would get
15:40:53 <sdague> so, maybe we really should step back and describe the personas here
15:41:05 <sdague> perhaps that's the next step
15:41:07 <notmorgan> sdague: ++
15:41:27 <cdent> that's a good idea
15:41:31 <ayoung> The idea is that you want to do more than just Token securet (heh) if you are, say, adding a user.  You only want that done from inside the firewall.  Good concept, don't think the SC is the right way to enforce it
15:41:44 <ayoung> m,ayeb add user is a bad example, tho9ugh
15:41:54 <ayoung> more like adding a service or endpoint
15:41:56 <cdent> I get the sense that there are some conflicts between the technical goals and the user stories...
15:41:58 <sdague> ok, anyone interested in starting to hack out the personas? That seems like an etherpad activity.
15:42:04 <sdague> cdent: yeh
15:42:05 <bknudson> ayoung: I think david-lyle says it's not inside/outside firewall at all, but the user's auth.
15:42:15 <ayoung> bknudson, I said that
15:42:24 <ayoung> bknudson, it is a case of userauth +  more security
15:42:30 <ayoung> at least, that was the concept
15:42:42 <ayoung> we could do it with just user auth, but that is not sufficient for some people
15:42:53 <ayoung> they want to reduce their attack surface
15:43:04 <ayoung> ask gyee, this is his kind of thing 2FA and all that
15:43:05 <sdague> yeh, the "more security" seems weird though. If you don't trust keystone to enforce security correctly on 1 url, I'm not sure why 2 makes it better :)
15:43:25 <ayoung> sdague, cuz tokens suck
15:43:55 <ayoung> you want to make it if an admin user loses a token in the wild, the server can't even be reached and it is not attackable for the sensitive operations
15:44:08 <sdague> #info we need a personas document to really determine what data / urls will be needed in a new catalog
15:44:34 <bknudson> I think we'll need more operator feedback into personas
15:44:37 <ayoung> this is just the rationalization I have been able to piece together over the years.  I was not there for the initial discussion
15:44:49 <notmorgan> ayoung: i also don't think most operators actually do that.
15:44:58 <notmorgan> ayoung: HP is one of the few.
15:44:59 <ayoung> notmorgan, Heh, neither do I
15:45:09 <notmorgan> ayoung: i also think it's a false set of security.
15:45:21 <sdague> ok, I'm going to move us to open discussion
15:45:27 <sdague> #topic Open Discussion
15:45:33 <sdague> so, a few things quick
15:45:50 <ayoung> notmorgan, I'm guessing you would argue "if you need to be inside the firewall, use a CLI with direct access to the machine" is the right approach?
15:45:50 <sdague> 1) volutneers wanted / needed if we are going to make real progress here
15:46:34 <notmorgan> ayoung: that is my general view - if it's something that really is *that* sensitive, you probably shouldn't be exposing it via a REST API and it should be CMS
15:46:38 <sdague> the idea is this meeting becomes more of a status check in. less discussion. disucssion should go to the lists.
15:46:51 <ayoung> sdague, got iot
15:46:53 <ayoung> it
15:47:20 <agentle> stand up :)
15:47:21 <cdent> sdague: keep after me to be an active part of this
15:47:30 <agentle> thanks cdent
15:47:43 <bknudson> I posted a related change to devstack, removing /v2.0 from the identity entry in the catalog: https://review.openstack.org/#/c/255294/
15:47:43 <sdague> related, notmorgan and I have been working towards having nova know how to talk to glance via service catalog entries
15:47:59 <ayoung> notmorgan, I think that makes sense.
15:47:59 <sdague> as it's the last service nova talks to with hardcoded values only
15:48:14 <ayoung> sdague, the MOC guys are working on that too.
15:48:16 <sdague> link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:glance_image_config,n,z
15:48:17 <notmorgan> sdague: actually... i think neutron needs work.
15:48:20 <bknudson> which version of the service catalog are you using?
15:48:25 <bknudson> also, which endpoint?
15:48:26 <ayoung> I'll ask them to comment and contriubte
15:48:35 <sdague> ayoung: MOC?
15:49:04 <ayoung> Mass Open Cloud.  Resourece Federation
15:49:06 <sdague> notmorgan: ok, cool, I thought we had base infrastructure for that
15:49:09 <sdague> ayoung: ah great
15:49:14 <ayoung> say glance and Nova are owned by two different orgs
15:49:26 <notmorgan> sdague: ran into this with my POC
15:49:31 <sdague> ok, any other related work from people to highlight that we should keep an eye on things?
15:49:36 <ayoung> sdague, add gsilvis to any reviews you have along those lines
15:49:56 <sdague> ayoung: ok, will do
15:50:23 <sdague> ok, anything else, or time to end meeting?
15:50:36 <sdague> next week we'll start with outstanding actions from this week
15:50:45 <sdague> then a 2 week hiatus re:holidays
15:50:55 <sdague> then back with a furry in 2016
15:51:13 <cdent> what kind of furry? a teddy bear? reindeer? kitty cat? ;)
15:51:22 <sdague> cat bus
15:51:26 <cdent> YES
15:51:29 <bknudson> new year's resolution will be to fix the service catalog
15:51:29 <cdent> \o/
15:51:32 <sdague> I brought one back for my daughter
15:51:37 <sdague> it's awesome
15:51:50 <sdague> ok, thanks for showing up to our kickoff, see you all next week
15:51:54 <sdague> #endmeeting