21:02:07 <ttx> #startmeeting crossproject
21:02:07 <SergeyLukjanov> o/
21:02:08 <openstack> Meeting started Tue Apr 21 21:02:07 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:12 <openstack> The meeting name has been set to 'crossproject'
21:02:13 <mikal> ttx: I actually have to run away today...
21:02:16 <etoews> o/
21:02:21 <ttx> mikal: run
21:02:27 <dhellmann> o/
21:02:32 <ttx> Our agenda for today:
21:02:33 <ttx> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting
21:02:38 <ttx> #topic api-wg discussion
21:02:41 <stevebaker> \o
21:02:42 <ttx> etoews: hi!
21:02:46 <ttx> I'll let you drive that one
21:02:47 <etoews> hi!
21:02:51 <etoews> sure thing
21:03:04 <etoews> this is something i want to do on a semi-regular baiss
21:03:08 <SpamapS> o/
21:03:10 <etoews> s/baiss/basis/
21:03:26 <SlickNik> o/
21:03:52 <etoews> once we've discussed and reached consensus on api guidelines in the api wg, we bring them up here for more viz before merging them.
21:04:15 <etoews> #link https://review.openstack.org/#/c/155620/
21:04:38 <etoews> we'd like to get some API CPLs to look at that one.
21:04:48 <nikhil_k> etoews: nice
21:05:07 <etoews> likewise #link https://review.openstack.org/#/c/159892/
21:05:43 <agentle_> really nice writing, clear
21:06:03 <etoews> one thought is that if we get no response from API CPLs by the eow then we can assume lazy consensus the merge by the following week.
21:06:30 <etoews> feedback on that plan?
21:06:37 <nikhil_k> umm, I would suggest giving a few more days
21:06:46 <nikhil_k> with rc2 lined up for most prj
21:07:12 <etoews> ah yes. i should give some consideration to the time of cycle. :)
21:07:28 <ttx> etoews: same for weeks that cover Design Summits :)
21:07:51 <asalkeld> etoews: both +1 from me
21:07:54 <ttx> but yes, generally speaking, raise them at meeting and do lazy consensus at week+1
21:08:13 <devananda> etoews: less than one week for lazy concensus, especially with RC periods or holidays, is generally not enough IMO.
21:09:16 <etoews> understood. maybe we should sync the lazy consensus time to the cross-project meeting
21:09:19 <Rockyg> etoews: did you advertise these to the operators list? They might want to at least have a look
21:09:21 <etoews> tues to tues
21:09:36 <etoews> Rockyg: will do
21:09:54 <devananda> etoews: also, the commit message is super short. I'd suggest copying the first few para from the spec to the commit message, or including a summary, or something like that
21:10:26 <etoews> fair enough
21:11:01 <devananda> etoews: also, this spec describes what a tag is and how to address it, but gives no guidance on when to use tags
21:12:05 <etoews> it's not my guideline. can you comment directly on the review? :)
21:12:18 <devananda> sure
21:12:31 <agentle_> tues to tues works well for synch
21:12:48 <ttx> etoews: looks like we have general agreement
21:12:57 <ttx> Anything else you wanted to cover ?
21:13:08 <etoews> and i think i'll send out an email to -dev and -operators advertising guidelines up for final review.
21:13:23 <etoews> ttx: nope. that covers it. thx.
21:13:25 <ttx> you can send those in advance of the Cross-project meeting
21:13:36 <ttx> so that people interested know they can join and discuss them
21:13:36 <etoews> sure
21:13:50 <ttx> #topic openstack-specs discussion
21:13:58 <ttx> We have two openstack-specs up for discussion
21:14:00 <jokke_> and have time to read it before if new thing ;)
21:14:03 <ttx> SpamapS: around?
21:14:14 <SpamapS> ttx: I am
21:14:15 <ttx> * Supported messaging drivers policy (https://review.openstack.org/#/c/174105/)
21:14:27 <ttx> I'll let you introduce yours
21:14:50 <SpamapS> Right, so the intention is to ensure that oslo.messaging only ships drivers which the community is able to fully support.
21:15:16 <SpamapS> In surveys, we have seen almost no respondents with anything other than RabbitMQ. Recently we've seen increased interest in the zmq driver, but not much investment of time and resources.
21:15:42 <bknudson> what's tested in the gate?
21:15:44 <SpamapS> So this policy is intended to define some clear policy for messaging drivers to meet to stay in oslo.messaging.
21:15:51 <SpamapS> bknudson: only rabbitmq
21:16:14 <SpamapS> And that is one of the requirements in the proposed spec. :)
21:16:57 <asalkeld> SpamapS: do we need some kind of deprecation window?
21:17:08 <asalkeld> rather than just remove
21:17:12 <SpamapS> asalkeld: Yes definitely.
21:17:15 <ttx> it is in the spec
21:17:17 <SpamapS> asalkeld: that is also in the proposed spec.
21:17:33 <asalkeld> o, missed that
21:17:34 <SpamapS> Including provisional time for new drivers to meet all requirements.
21:17:43 <SpamapS> So that progress can be made from within the tree in good faith.
21:17:46 <ttx> ok, I think it makes sense. We may have to recruit people
21:18:39 <ttx> I think it all makes sense
21:18:43 <johnthetubaguy> something similar worked quite well for Nova virt drivers, in many ways, it seems like a good path
21:18:47 <ttx> questions?
21:19:24 <jokke_> SpamapS: this looks to be oslo messaging policy, is there a reason why it's on openstack-specs rather than oslo-specs? ;)
21:19:27 <gordc> if we mark a driver deprecated... what happens if it becomes compliant later?
21:19:31 <SpamapS> Please do provide feedback on the spec. I intend to get any out of policy drivers deprecated mid-liberty if nobody shows up to maintain and test them.
21:19:35 <gordc> we just take back the deprecated status?
21:19:38 <asalkeld> SpamapS: is it worth having some kind of support_status like we have in heat resources, so the operator knows the state of it
21:19:43 <SpamapS> jokke_: because nearly everything requires oslo.messaging.
21:19:45 <ttx> jokke_: that's a good point
21:19:45 * gordc will comment on spec
21:20:13 <SpamapS> I don't think it is a decision the oslo core team should be making alone.
21:20:25 <jokke_> SpamapS: tru, but the change is still just oslo change ... oslo.messaging consumers should not need to take actions on the provider, right?
21:21:15 <jokke_> SpamapS: I think it's fair point to bring it up, here, appreciated. Just technicality out of my curiosity
21:21:29 <jokke_> s/, here/ here/
21:21:32 <SpamapS> So, this may be totally off base, but ot me, oslo-specs are about implementation of common code. Because oslo is always cross-project, any policy is an openstack-wide policy and should be more broadly considered.
21:22:06 <ttx> doesn't shock me either way
21:22:19 <SpamapS> Anyway, your comments are appreciated very much, thank you!
21:22:22 <ttx> OK, last coments/questions before we move on ?
21:22:39 <ttx> * Return request ID to caller (https://review.openstack.org/#/c/156508/)
21:22:40 <asalkeld> seems sensible
21:22:45 <tpatil> Hi
21:22:53 <tpatil> Jamie has suggested a new approach to pass request id using keystone client.session instead of making changes to the individual clients
21:22:56 <ttx> tpatil: hi!
21:23:05 <jokke_> SpamapS: I might be wrong, but I have been looking those two spec repos in a light that oslo-specs contains proposals implemented within oslo projects and openstack-specs common guidelines followed withing individual OS projects
21:23:47 <tpatil> I would like to know whether it's ok to pass request id between services or each service should generate it's own request id.
21:24:28 <johnthetubaguy> tpatil: I think we actually need both
21:24:52 <asalkeld> johnthetubaguy: so parent child request_ids?
21:25:00 <johnthetubaguy> tpatil: think about a single nova command makes many glance requests
21:25:04 <notmyname> as long as the request ID passed in isn't trusted
21:25:08 <johnthetubaguy> asalkeld: I was thinking simpler
21:25:15 <asalkeld> do we really need to pass it in tho'
21:25:17 <tpatil> If request id can be shared between OpenStack services, then I think Jamie solution is worth
21:25:36 <johnthetubaguy> so think about doing both, and the trusted issues seems to go away
21:25:41 <johnthetubaguy> every request has its own id
21:26:03 <johnthetubaguy> but a caller can give their own id too (up to a certain size limit)
21:26:08 <johnthetubaguy> I think that works
21:26:17 <johnthetubaguy> so thinking of a single nova request id
21:26:26 <tpatil> we have started understanding keystonemiddleware, will work on spec and upload new before the next meeting.
21:26:27 <johnthetubaguy> that creates several neutron requests and glance requests
21:26:33 <johnthetubaguy> each need their own id
21:26:52 <johnthetubaguy> but its handy to give them the caller, Nova in this case, request uuid
21:26:58 <notmyname> hmm...looks like I need to figure out how this works with the existing fuctionality in swift
21:27:03 <devananda> johnthetubaguy: and nova logs could contain both the nova and $other_service request-id's on certain log lines
21:27:29 <johnthetubaguy> devananda: agreed, but I think we are better having both, glance logs with nova, and nova with glance
21:27:32 <notmyname> x-trans-id header (with an optional user-settable suffix)
21:27:39 <devananda> i've had concerns in the past with allowing the python clients to pass a request id *to* a service. basically allows end users to specify arbitrary strings that show up in logs in place of meaningful data
21:28:15 <devananda> johnthetubaguy: and passing it from nova to glance means that a user could also pass their own garbage directly to glance, unless something else i'm not aware of would prevent that?
21:28:18 <jokke_> I really don't like that idea ... for us to keep them unique, they need to be really long even in short period of investigation. That means that soon enough we have few first lines of log message different IDs if we chain them
21:28:24 <johnthetubaguy> devananda: right, but if each request also has its own generated id, you don't leave the logs in a bad state (assuming there is a limit on that values passed in), I think
21:28:31 <asalkeld> johnthetubaguy: surely you just need one log that maps the parent to child
21:28:53 <tpatil> devananda: we can encrypt request id and the service in question should decrypt and use it instead of creating it's own.
21:29:00 <johnthetubaguy> jokke_: I see only two for now, the caller and the local id, but maybe thats just me
21:29:01 <notmyname> isn't this solving the same problem that "user-agent" is solving?
21:29:10 <devananda> +1 for parent logging both its request-id and any request-id returned from services it called
21:29:26 <johnthetubaguy> tpatil: I don't see why we want to add encryption when its not required here
21:29:54 <devananda> tpatil: yea... encryption just for passing a request-id is going to add a lot more complexity that isn't necessary
21:30:11 * jogo is amazed this same conversation has been going on for what seems to be years now
21:30:19 <bknudson> keystone tokens have an audit_id now that could be used for tracking.
21:30:45 <devananda> bknudson: what if the same token is used to issue multiple requests in parallel?
21:30:51 <johnthetubaguy> bknudson: thats shared between request though, I guess, which breaks the concept, I think
21:30:59 <bknudson> you'd still need a request ID.
21:31:00 <tpatil> johnthetubaguy: nova talking with cinder, if we don't encrypt it then malicious user can send random request id, which we don't want
21:31:09 <bknudson> it could just be much shorter
21:31:16 <asalkeld> i really think the main thing here is to make the request_id accessible from the client
21:31:21 <devananda> tpatil: we shouldn't be sending a request-id in a request.
21:31:24 <johnthetubaguy> tpatil: but whats the halm, if you already have your local request_id there too?
21:31:25 <devananda> asalkeld: ++
21:31:40 <notmyname> jogo: log your own request id. log the first 32 (or whatever) bytes of the passed-in request id. done. :-)
21:31:55 <johnthetubaguy> notmyname: +1
21:32:08 <notmyname> asalkeld: is it? I thought it was to correlate logs? end-users better not see those
21:32:09 <mtreinish> notmyname: all the request ids should be the same format
21:32:12 <jogo> notmyname: but why do that when we can make this so much more complex?
21:32:17 <mtreinish> well except for swift I guess
21:32:19 <devananda> notmyname: if by "passed in" you mean "returned from the service you just called" -- then +1
21:32:27 <mtreinish> but everything else uses the oslo lib to generate them
21:32:33 <asalkeld> notmyname: sure, you can do that once you can get the request_id
21:32:34 <notmyname> mtreinish: absolutely. the format is "a string less than XYZ bytes long"
21:33:02 <johnthetubaguy> notmyname: +1
21:33:28 <notmyname> devananda: I mean given on a request header
21:33:49 <notmyname> devananda: thinking from the server side. yes a client sdk could plumb those together
21:34:19 <Rockyg> tpatil: when will the spec rewrite be available for these folks to comment?
21:34:39 <tpatil> Rocky: If each service is suppose to use it's own request id, then I would request you to please provide feedback on the current spec
21:34:51 <ttx> Sounds like a good topic for a cross-project track session
21:35:00 <ttx> (and there is one posted)
21:35:00 <Rockyg> Already on the llist!
21:35:07 <jokke_> :)
21:35:16 <tpatil> txt: we have already added a session for this
21:35:27 <tpatil> s/txt/ttx
21:35:47 <notmyname> tpatil: it seems that this spec is designed more for client SDKs?
21:35:58 <ttx> I'm just unsure we can make a lot more progress in a 30-min IRC discussion
21:36:36 <asalkeld> ttx: do you have the link to cross project sessions?
21:36:44 <Rockyg> ttx: that's why I was wondering when this alternative might turn up in the spec.  So we can do this offline in prep for the summit
21:37:08 <tpatil> notmyname: but it can be used by the OpenStack services as well for logging mapping of request ids
21:37:13 <ttx> asalkeld: http://lists.openstack.org/pipermail/openstack-dev/2015-April/061070.html
21:37:17 <asalkeld> thx!
21:38:25 <ttx> tpatil: planning to rewrite the spec to include the alternative ?
21:38:33 <ttx> In time for the Design Summit ?
21:38:36 <tpatil> ttx: Sure, will do that
21:38:46 <ttx> ok, I think that would be the next step
21:38:49 <Rockyg> tpatil: thanks!
21:38:58 <tpatil> ttx: yes, before the design summit
21:39:07 <ttx> Any other remark/question on that topic ?
21:39:50 <asalkeld> no
21:40:05 <ttx> ok
21:40:10 <ttx> #topic Design Summit scheduling
21:40:15 <ttx> I sent an email last week with the proposed Design Summit slot layout
21:40:16 <bknudson> keystoneclient session is moving to keystoneauth
21:40:25 <ttx> #link https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing
21:40:47 <ttx> I got a complaint from Manila which would like to be more separated from Cinder
21:41:23 <morganfainberg> ttx, i will need to have a keysotne session traded as we have a conflict with a presentation being given by a number of keystone cores
21:41:28 <morganfainberg> ttx, if possible
21:41:37 <ttx> it's tricky since Cinder has 13 sessions, Manila 7, and there are only 18 available time slots
21:42:00 <ttx> morganfainberg: when?
21:42:06 <ttx> I tried to anticipate those
21:42:15 <ttx> guess I missed one
21:42:16 <morganfainberg> the worksession at wed 1:50
21:42:29 <david-lyle> same for horizon session
21:42:36 * devananda is apparently behind on emails and did not see it yet
21:42:40 <morganfainberg> conflicts with http://sched.co/2qch
21:43:09 <david-lyle> Thurs 4:10- 5:00, multiple cores giving talk
21:43:30 <ttx> OK, I'll try to move things around a propose a new one tomorrow
21:43:38 <david-lyle> http://sched.co/2qeB
21:43:46 <david-lyle> is the conflict
21:44:12 <ttx> Oh right I detected this one.
21:44:31 <ttx> it's with a work session. I'll trto move it out
21:44:35 <ttx> try
21:44:49 <david-lyle> ttx: thanks
21:45:12 <ttx> Any change on that grid is cascading new failures though
21:45:30 <morganfainberg> then i'd be willing to surrender the worksession actually.
21:45:46 <morganfainberg> for keystone at least.
21:45:53 <ttx> anyway, if you have other remarks, post them now on that thread (or here) so I can include them in the final layout
21:46:04 <ttx> I'll push placeholder sessions to the Design Summit sched before end of week
21:46:15 <david-lyle> ttx: is that the middle of a work session?
21:46:17 <ttx> Then you'll be able to use a new tool called Cheddar to update the contents of each slot in your track
21:46:17 <david-lyle> for horizon
21:46:22 <ttx> david-lyle: yes
21:46:23 <morganfainberg> ttx: which thread?
21:46:27 <david-lyle> if so, we can let it stand
21:46:53 <david-lyle> we can come and go
21:47:05 <ttx> morganfainberg: http://lists.openstack.org/pipermail/openstack-dev/2015-April/061770.html
21:47:11 <morganfainberg> ttx, thnx
21:47:27 <ttx> Cheddar is a sched proxy that lets you edit some (but not all) of the details of sessions
21:47:33 <ttx> Like you can't change the time or the room.
21:47:38 <ttx> I'll send an email about it soon
21:47:48 <ttx> Note that you can have several people registered to admin your track. By default, will be the PTL, but let me know if you want to delegate that to others
21:48:46 <ttx> #topic Open discussion & announcements
21:48:53 <ttx> I posted the proposed Liberty release date and milestone schedule last week:
21:49:02 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061331.html
21:49:17 <ttx> Let me know if you have problems with it, would be good to make official soon
21:49:23 <morganfainberg> lgtm.
21:49:56 <ttx> On the release side, we started to roll out RC2s, but the requirements clusterf*ck hit us again
21:50:09 <ttx> hopefully will be solved soon
21:50:25 <ttx> Anything else, anyone ?
21:51:28 <devananda> ttx: any guidance on room sizes on the spreadsheet?
21:51:31 <devananda> if so, I dont see it
21:52:01 <devananda> ttx: I only requested 2 fishbowl sessions for ironic this cycle, but i expect them to be very crowded. in paris our room was overflowing ...
21:52:08 <ttx> devananda: not really. We can switch those if needed. The column width gives you an idea.
21:52:13 <bknudson> fishbowls actually sound smaller than work rooms.
21:52:34 <devananda> I think of fishbowls as the place everyone comes to look at and poke the fish :)
21:52:41 <devananda> where fish == core devs
21:52:49 <ttx> fishbowl 4 is....
21:52:50 * ttx checks
21:52:56 <bknudson> don't bang on the glass... scares us.
21:53:07 <ttx> 182 seats
21:53:49 <ttx> hmm, actually might be a 212 seat one
21:53:52 <thingee> I'm experiencing the issue where most people are assigning stuff to working sessions rather than fishbowl for cinder https://etherpad.openstack.org/p/cinder-liberty-proposed-sessions
21:54:06 <thingee> I think some of these can be moved around, but maybe cinder won't need as many fish bowl
21:54:21 <ttx> thingee: you can disguise a fishbowl into a meeting room in the agenda
21:54:31 <ttx> by using the right title
21:54:37 <thingee> :)
21:54:43 <ttx> All work sessions have the same (boring) title
21:55:09 <ttx> since they are like 30-seat rooms, better not attract random people
21:55:38 <ttx> but that doesn't prevent you from using the same boring title for your fishbowls. A sort of anti-honeypot.
21:55:40 <jokke_> thingee: if you are really struggling, we (Logging WG) might be able to utilize your fishbowl :P
21:56:21 <thingee> jokke_: We're going to be discussing these in the next cinder meeting. I'll reply to the list and let ttx if we don't need so many
21:56:31 <thingee> next cinder meeting being tomorrow
21:56:46 <ttx> ack
21:57:02 <ttx> ok, let's close this
21:57:13 <ttx> #endmeeting