21:02:31 <markmcclain> #startmeeting crossproject
21:02:31 <lifeless> no ping this week
21:02:32 <openstack> Meeting started Tue Oct  6 21:02:31 2015 UTC and is due to finish in 60 minutes.  The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:33 <skraynev_> o/
21:02:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:35 <nikhil> o/
21:02:37 <fungi> thanks markmcclain!
21:02:38 <openstack> The meeting name has been set to 'crossproject'
21:02:38 <lifeless> its a very odd ping list
21:02:39 <lifeless> o/
21:02:45 <edleafe> o/
21:02:58 <stevebaker> \o
21:03:16 <markmcclain> lifeless: should be the superset of ptls until I've got list errors
21:03:24 <markmcclain> s/until/unless
21:03:30 <stevemar_> o\
21:03:31 <markmcclain> fungi: here to please
21:03:33 <lifeless> markmcclain: + tc :)
21:03:41 <markmcclain> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:03:54 <markmcclain> lifeless: I'll correct it for next time
21:03:56 <lifeless> markmcclain: unless the TC isn't relevant to the meeting... :)
21:04:05 <nikhil> can we add a section to the wiki for all those who want to be notified/pinged?
21:04:06 <stevemar_> lifeless: ohhh burn
21:04:11 * Rockyg lurks
21:04:50 <markmcclain> nikhil: sure
21:04:53 <lifeless> markmcclain: sorry, enough kibbitzing from me, on ward and upward :)
21:04:56 <markmcclain> no action items from last time
21:04:58 <markmcclain> #topic Horizontal Team Announcements
21:05:38 <markmcclain> Any horizontal announcements?
21:05:44 <ttx> On the Design Summit front, the per-track schedule is now officialized at mitakadesignsummit.sched.org
21:05:50 <ttx> The scheduling system is also available for the PTLs scheduling pleasure
21:05:54 <ttx> Details at:
21:05:56 * armax here if you need me
21:05:57 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/076172.html
21:06:10 <ttx> It's the same system as last summit. Let me (or thingee) know if you have any questions.
21:06:26 <ttx> On the release management front, we are about 9 days before the end of the liberty dev cycle
21:06:34 <ttx> We have release candidates for everything, and are actively respinning RCs to include latest translations
21:06:41 <ttx> You should all start working on the release notes at:
21:06:45 <ttx> #link https://wiki.openstack.org/wiki/ReleaseNotes/Liberty
21:06:58 <ttx> On the governance front, we have a TC membership election going on, please vote!
21:07:02 <ttx> That is all from me
21:07:11 <markmcclain> ttx: thanks for the update
21:07:20 <annegentle> thanks for the release notes reminder!
21:07:22 <stevemar_> general note saying the tool for updating the design sessions is awesome
21:07:36 <annegentle> #info Work on those release notes for liberty
21:08:06 <markmcclain> annegentle: yes.. good release notes are critical part of the release
21:08:16 <markmcclain> Any other horizontal team announcements?
21:08:35 <ttx> stevemar_: I should put it under Gerrit
21:09:04 <dhellmann> ttx: ++
21:09:09 <stevemar_> ++
21:09:22 <ttx> stevemar_: there is a bug when adding "another track" to a session, but that's actually sched API acting up
21:09:43 <ttx> stevemar_, dhellmann: we are supposed to drop Sched and work on our own system
21:10:01 <ttx> so I always thought it would not be necessary to go beyond github.
21:10:40 <ttx> https://github.com/ttx/summitsched for reference
21:10:43 <dhellmann> ttx: orly?
21:11:27 <ttx> anyway, moving on ;)
21:11:30 <lifeless> ttx: where do we get the resources to do that?
21:11:39 <ttx> lifeless: foundation
21:11:49 <markmcclain> #topic Service Catalog Standardization
21:11:54 <ttx> lifeless: (not done yet)
21:12:10 <markmcclain> #link https://review.openstack.org/#/c/181393/
21:12:19 * annegentle waves
21:12:29 <annegentle> where's that etherpad from last week?
21:12:39 <stevemar_> sdague: ^
21:12:48 <markmcclain> #link https://etherpad.openstack.org/p/mitaka-service-catalog
21:12:58 <annegentle> thanks
21:13:47 <annegentle> much overlap, there is. But I think that the spec covers everything in the etherpad, am I missing anything?
21:14:10 <annegentle> We'd love an unauthed service catalog but documenting how to filter it might work too
21:14:24 * stevemar_ is still concerned that removing project IDs is gonna be hard for swift
21:14:39 <stevemar_> i've love an unauthenticated catalog
21:14:44 <annegentle> stevemar_: yeah looking at that, hm
21:14:48 <bknudson> if swift isn't willing to sign up to remove project IDs from their catalog then this is a non-starter.
21:14:56 <stevemar_> bknudson: yep
21:14:58 <annegentle> bknudson: the whole spec?
21:15:14 <annegentle> do we have swift ptl notmyname's input?
21:15:23 <notmyname> ah, sorry, I didn't get a ping. looking
21:15:59 <annegentle> where {account} is equal to project, right bknudson?
21:16:08 <bknudson> not the whole spec.
21:16:14 <markmcclain> notmyname: my apologies... error in my list
21:17:23 <bknudson> $SWIFT_SERVICE_PROTOCOL://$SERVICE_HOST:8080/v1/AUTH_\$(tenant_id)s
21:17:27 <annegentle> This etherpad is a great continuation of the etherpad that got... lost... in Vancouver
21:17:29 <notmyname> no worries. typing to catch up :-)
21:17:29 <bknudson> that's what devstack is setting for the endpoitn now
21:17:37 <bknudson> http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/swift#n619
21:17:45 <stevemar_> bknudson: but could it work without that?
21:17:53 <stevemar_> just cause devstack sets it up like that
21:18:00 <stevemar_> doesn't mean we want it that way
21:18:18 <bknudson> stevemar_: I don't get to decide that.
21:18:30 <stevemar_> bknudson: that's where notmyname comes in :)
21:19:01 <annegentle> devstack becomes docs for many people for "how do I configure this" including the docs team, so understanding if devstack _has_ to do it that way is pretty crucial
21:19:22 <notmyname> AIUI, looking to remove the "tenant_id" part? completely or to replace with something else?
21:19:46 <dtroyer> IIRC the inital reason DevStack does that is due to client requirements.  If the client can work with a SC endpoint without the account it should be OK
21:19:58 <dtroyer> a lot has changed since that was done...
21:20:10 <bknudson> notmyname: for nova the plan is to make the tenant_id optional. If it's not present then it'll get the project from the token.
21:20:12 <annegentle> dtroyer: yeah
21:20:34 <notmyname> bknudson: what if it's some other string besides the project id?
21:20:55 <bknudson> keystone only supports replacing tenant_id and user_id in the service catalog
21:20:56 <stevemar_> notmyname: ideally we want it to just be an unversioned URL
21:20:56 <notmyname> or is the choice project/tenant id or nothing?
21:21:13 <notmyname> stevemar_: "Versioned" is confusing here. a tenant id isn't a version
21:21:28 <stevemar_> notmyname: sorry, you guys only have v1
21:21:40 <stevemar_> notmyname: ideally we want it to be: http://hostname:8080
21:21:43 <notmyname> /v1/{account}
21:21:43 <stevemar_> that's it
21:21:46 <notmyname> hmm
21:21:46 <stevemar_> nope
21:21:56 <stevemar_> let the clients handle /v1/account
21:21:57 <notmyname> sorry, that was a reply to your earlier one
21:22:26 <notmyname> so there would need to be some sort of catalog so clients can look up what their account string is, right?
21:22:33 <stevemar_> keystone tokens already have project ids in there, so we can determine the URL
21:22:58 <annegentle> notmyname: right, a lookup
21:23:20 <stevemar_> well when you authenticate with keystone you project a project name/id, so we would just re-use that one
21:23:24 <notmyname> annegentle: if only we had an openstack project that could server some sort of catalog about services available ;-)
21:23:33 <stevemar_> notmyname: hehe
21:23:56 <notmyname> stevemar_: is that in the identity response from the auth_token middleware or encoded int he token itself?
21:23:58 <bknudson> in the case of nova devstack sets "$nova_api_url/v2/\$(tenant_id)s" -- so the idea is to change to "$nova_api_url/v2"
21:24:02 <annegentle> notmyname: :)
21:24:29 <bknudson> and nova will work with either tenanted URLS or non-tenanted URLs for a while.
21:24:43 <stevemar_> notmyname: it's definitely in the token itself, and the middleware has an option for setting the project too
21:24:59 <notmyname> stevemar_: ah ok. so eg "the first 15 bytes" or something
21:25:00 <bknudson> auth_token middleware sets the project ID in the environment
21:25:36 <stevemar_> bknudson: yep in X-Project-Id
21:26:26 <redrobot> bknudson I think you mean jus $nova_api_url  ... version should be added by the client.
21:27:25 <bknudson> redrobot: yes, I was splitting out the versioning conversation from replacing tenant_id conversation
21:27:55 <bknudson> strangely, devstack also sets "$nova_api_url/v2.1/\$(tenant_id)s"
21:28:36 <annegentle> bknudson: that can be changed as long as we know things will work after the change
21:28:38 <annegentle> bknudson: right?
21:29:03 <notmyname> I'll have to look at this in more detail. at minimum, this will take a lot of dev work and testing in swift, if it's even possible. I know most people in here hate to hear this, but it also will be tricky to make sure all the non-keystone auth integrations still work
21:29:16 <bknudson> annegentle: right, we can change the contents of the catalog... the server and clients need to support it.
21:29:26 <annegentle> notmyname: that's a fair assessment and then risk analysis
21:29:34 <annegentle> bknudson: ok right
21:30:05 <stevemar_> notmyname: cool, might be worth bugging the nova folks to see how they are transitioning from project IDs in the url to not have them
21:30:09 <bknudson> if they don't have keystone then they don't have to worry about a service catalog
21:30:31 <notmyname> stevemar_: yeah, but I doubt that nova uses that string for actual data placement
21:30:55 <notmyname> in swift, that string is used as one of the inputs to the hash function for data placement and retrieval
21:31:03 <bknudson> so clients must already be adding account id on their own.
21:31:22 <stevemar_> notmyname: so in swift you actually use the service catalog entries?
21:31:32 <bknudson> ... this might be why you were asking about {account_id}
21:31:33 <notmyname> bknudson: no, the auth system, whatever it is, returns a storage url that includes the account part
21:32:01 <notmyname> stevemar_: ^ answers your question too :-)
21:32:06 <markmcclain> #action notmyname to investigate how proposed service catalog change impacts swift further
21:32:14 <mordred> oh
21:32:18 <bknudson> I think the point of the spec is to have a static service catalog (no replacements)
21:32:22 <mordred> is the TC proposed catalog changes?
21:32:50 <mordred> (or cross-project or whatever that spec was)
21:33:36 <stevemar_> bknudson: yes, that's hopefully the outcome :)
21:33:55 <annegentle> mordred: it's the cross-project spec
21:33:59 <mordred> cool
21:34:16 * mordred loves that spec - just making sure he hadn't missed other catalog change proposals
21:35:36 <markmcclain> Any last thoughts on this topic?
21:35:45 <annegentle> on Q
21:35:59 <annegentle> er, one Q, do I need to update the spec with a link to the etherpad above?
21:36:12 <annegentle> or can I add on later?
21:36:24 <markmcclain> I think it can be added later
21:36:27 <notmyname> annegentle: at least in a comment for now would be nice
21:36:29 <notmyname> IMO
21:36:50 <markmcclain> notmyname: good idea
21:37:08 <markmcclain> ok moving on
21:37:10 <markmcclain> #topic Vertical Team Announcements
21:37:45 <annegentle> notmyname: check
21:38:17 <markmcclain> Seeing no announcements moving on
21:38:25 <markmcclain> #topic Open Discussion
21:39:56 <fungi> reminder: the gerrit maintenance for the stackforge namespace retirement starts at 18:00 utc october 17 (a week from saturday)
21:40:31 <markmcclain> fungi: thanks
21:40:56 <markmcclain> Last call...
21:42:08 <markmcclain> Thanks to everyone for joining this week. EmilienM will be chairing next week.
21:42:15 <markmcclain> Have a great week.
21:42:16 <annegentle> good call fungi
21:42:17 <markmcclain> #endmeeting