21:02:46 <ttx> #startmeeting crossproject
21:02:46 <thingee> o/
21:02:48 <openstack> Meeting started Tue May 26 21:02:46 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:49 <edleafe> o/
21:02:51 <openstack> The meeting name has been set to 'crossproject'
21:02:53 <ttx> Today's agenda:
21:02:56 <ttx> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting
21:03:25 <dims> o/
21:03:43 <docaedo> o/
21:03:48 <ttx> #topic Design Summit feedback
21:03:54 <ttx> Last week was the Liberty Design Summit, as you may have noticed
21:04:04 <ttx> We did a feedback session there with the survivors, but I realize not everybody was there
21:04:10 <ttx> We put the feedback to:
21:04:16 <ttx> #link https://etherpad.openstack.org/p/YVR-design-summit-feedback
21:04:28 <ttx> Anything specific anyone wanted to mention, while the memories are still clear ?
21:04:47 <bknudson> at least for keystone the work session rooms were the right size.
21:05:26 <notmyname> looks like some of the comments I heard are in that etherpad: need projectors in work sessions, work sessions too short
21:05:31 <ttx> At the feedback, only neutron was really off, with too many people everywhere
21:05:42 <notmyname> overall I liked the format for fishbowl+work+meetup
21:05:45 <jokke_> ttx: one thing I noticed hard way on the conference side (not sure where to feedback that), no wutah for the speakers
21:05:52 <dims> ttx: the red apron(?) for ATC(s) and associated warnings was a bit off putting
21:05:55 <johnthetubaguy> I think Nova was happy to the same again next time, although a smaller room would have worked, an extra monitor/projector in the meetup would be handy
21:05:59 <ttx> notmyname: I think we would add a monitor in every work room. Would that work ?
21:06:12 <johnthetubaguy> so yeah, I think its all captured
21:06:14 <notmyname> ttx: yea, a large-ish monitor would work too
21:06:22 <morganfainberg> dims: ++ I had to ask people to move forward constantly
21:06:31 <mariojv> o/
21:06:32 <ttx> dims: I think we'll just keep the red thing but remove warnings. So that people can say "if you want to discuss, move to the red seats"
21:06:42 <dims> ttx: awesome!
21:06:53 <jokke_> ++
21:06:53 <notmyname> ttx: I also really liked cheddar for the scheduling, especially the ability to tag things for more than one track
21:06:54 <ttx> happy to just remove them though, but some people said they were useful in session
21:06:55 <morganfainberg> ttx: ++ yeah just no warning would have been good.
21:07:12 <ttx> notmyname: I'll make sure whatever we use for next time has the same capabilities
21:07:14 <notmyname> I think the 2 schedules was kinda silly. no need for that level of obfuscation
21:07:22 <mestery> ++ for cheddar scheduling
21:07:42 <mestery> For Neutron, my feedback is that we can never have a room that holds less than 200 people again :)
21:07:50 <mestery> We had 100+ people in our work group rooms
21:07:53 <dims> ttx: request the design summit area be open for folks earlier than they were (heard some complaints)
21:07:54 <mestery> It made it uncomfortable
21:08:08 <Madasi> o/
21:08:16 <ttx> mestery: so looks like you should have requested only fishbowls (and nova should have requested a mix)
21:08:26 <ttx> if people will find Neutron however we hide it...
21:08:27 <mestery> ttx: Yes, I've learned my lesson :)
21:08:27 <thingee> +1 cheddar is good
21:08:52 <mestery> ttx: Actually, if you could make all our sessions be BEFORE 10AM of the local timezone we'd be ok as well ;)
21:08:57 <jokke_> mestery: or come up with even more repelling work session names
21:09:30 <dims> wireless was good, had enough plugs for charging. so +1
21:09:31 <johnthetubaguy> ttx: not sure we had any work sessions in Nova really, just folks didn't turn up in droves, as they normally seemed to, but thats OK I think
21:09:36 <ttx> jokke_: "Useless Neutron work session: we won't mention Docker here"
21:09:43 <anteaya> flash mob for neutron
21:09:52 <mestery> jokke_: In one session around ironic/neutron integration, I asked how many of the 100+ people would be contributing code, and 40+ people raised their hands. o_O
21:09:56 <bknudson> at least for keystone our work sessions really had no topic
21:09:58 <bknudson> maybe that helped
21:10:13 <ttx> mestery: so who are the other ones ? Managers of the contributors ?
21:10:18 <morganfainberg> bknudson: because of the short windows, i think the "no fixed topic" was a bit help
21:10:22 <mestery> ttx: Lurkers and tourists
21:10:32 <jokke_> mestery: at that point "Rest of you out so we can actually preserve the available oxygen for the people who do!"
21:10:32 <jroll> mestery: yeah, that one was a mess, I have no idea how that happened (only 2-3 of those were ironic folks) :|
21:10:46 <ttx> The less likely place I would have a vacation to is one of those Neutron fishbowl rooms
21:10:51 <mestery> It was very odd
21:11:01 <mestery> ttx: lol
21:11:03 <bknudson> 40 mins did make it unlikely that anything would get completed.
21:11:20 <ttx> bknudson: for work sessions ? Or both ?
21:11:24 <thingee> cinder working session had someone passed out on the ground snoring. ground breaking development in progress
21:11:24 <jungleboyj> o/
21:11:26 <morganfainberg> ttx: work sessions
21:11:36 <morganfainberg> ttx: as we discussed in the feedback session
21:11:40 <ttx> morganfainberg: yes, I think we should allow double work sessions
21:11:53 <jungleboyj> thingee:  My topics are just that exciting!
21:12:00 <ttx> oslo work sessions included sun bathing
21:12:07 <dims> ++ :)
21:12:11 <jungleboyj> ttx ++
21:12:12 <fungi> also plane watching
21:12:14 <mestery> The oslo folks know how to do things the right way :)
21:12:18 <bknudson> we did double up a keystone work session and that left more time.
21:12:22 <morganfainberg> mestery: ++
21:12:33 <ttx> Alright. If you have further feedback, you can add it to that etherpad at the bottom, or send me email
21:12:49 <notmyname> +1 to having double work sessions. I had people say that the rapid context switching was hard
21:12:50 <ttx> I have no idea what Tokyo holds for us so hard to make commitments right now
21:12:58 <jungleboyj> Sorry I am late, but I thought the set up of everything worked quite well!
21:13:10 <annegentle> ttx: other than it's only 5 months away :)
21:13:23 <ttx> and that it fully overlaps with conference
21:13:33 <krotscheck> I'm guessing tokyo will have less sunbathing and more pod hotels.
21:13:48 <ttx> ok, back to work
21:13:49 <ttx> #topic CORS Support for OpenStack (krotscheck)
21:13:53 <krotscheck> Hi hi!
21:13:53 <ttx> #link https://review.openstack.org/#/c/179866/
21:13:56 <ttx> krotscheck: hi! Care to introduce the topic ?
21:13:59 <krotscheck> Yes!
21:14:21 <krotscheck> So, CORS is a spec published by the w3c that permits selective breaking of the browser's single-origin policy.
21:14:38 <krotscheck> In short, an API can say: You there, on that domain, running in a browser, you're allowed to talk to me too.
21:14:56 <krotscheck> This permits javascript clients to talk to the APi directly, rather than having to proxy through something like horizon.
21:15:13 <johnthetubaguy> krotscheck: thats all about adding oslo middleware I guess?
21:15:32 <bknudson> so horizon needs it?
21:15:33 <krotscheck> johnthetubaguy: Mostly. The middleware's already landed.
21:15:35 <bknudson> why middleware?
21:15:59 <krotscheck> bknudson: I chose middleware because it was framework agnostic.
21:16:17 <krotscheck> It's a wsgi thing.
21:16:18 <krotscheck> So it doesn't try to force you into pecan, flask, etc etc.
21:16:34 <jroll> bknudson: the code needs to be in any api server a browser client would talk to, if that wasn't clear
21:16:51 <bknudson> ah
21:17:09 <ayoung> It was kindof weird that we would have two keystone sessions back to back, but would have to jump rooms depending on "fishbowl" or "work"
21:17:09 <ayoung> its like " ok, everyone, time to move to a new room"  and then move en masse
21:17:09 <ayoung> not a huge problem, though
21:17:33 <krotscheck> Current potential consumers are in the spec, but include Horizon (not yet on the roadmap, as this spec hasn't landed), merlin (mistral), ironic-webclient, etc.
21:18:02 <bknudson> also, not sure why this is cross-project and not just oslo.middleware?
21:18:13 <bknudson> what do we need to do in keystone for example?
21:18:26 <bknudson> it's not enabled by default, I assume.
21:18:32 <krotscheck> It is not.
21:18:56 <krotscheck> I have an example patch up for ironic: https://review.openstack.org/#/c/180680/
21:19:01 <johnthetubaguy> krotscheck: this spec proposes its on by default I guess?
21:19:06 <bknudson> it would be helpful to get a call on whether paste.ini is a config file or "code"
21:19:29 <ttx> ayoung: keeps the team healthy
21:19:31 <notmyname> the idea of "let's support CORS" seems reasonable. I'm leery of reimplementing swift's existing functionality for this and the associated risk that assumes
21:19:35 <krotscheck> johnthetubaguy: It proposes that it be included, but since the middleware doesn't activate itself without a configuration, it ends up being a no-op.
21:19:59 <krotscheck> notmyname: From what I understand, swift's implementation just mirrors back the url provided by the client.
21:20:01 <johnthetubaguy> krotscheck: gotcha
21:20:17 <krotscheck> notmyname: I could be wrong.
21:20:40 <krotscheck> notmyname: If I'm not, that's an xss exploit waiting to happen.
21:20:52 <devananda> bknudson: the reason for cross project proposal is that it requires a change in the API service, eg. loading the middleware and enabling it, and if we go this route, it should probably be consistent across projects that want such an API
21:21:00 <notmyname> krotscheck: it's configurable per-container as to how CORS support is enabled
21:21:09 <notmyname> krotscheck: but if there is a bug, please report it :-)
21:21:35 <bknudson> for keystone we've got a paste config file so you can put whatever middleware you want in there
21:21:49 <krotscheck> notmyname: Sounds like we need to discuss more details on how this would work for swift.
21:21:57 <ayoung> In general, access to the Keystone token in a specific header should deal with the XSRF attacks.
21:22:06 <etoews> miguelgrinberg: you'll be interested in this topic ^
21:22:06 <ayoung> XSS is a little different
21:22:39 <krotscheck> bknudson: That config file doesn't permit middleware to explicitly hook into oslo.
21:22:47 <miguelgrinberg> etoews: hi, and thanks
21:23:04 <stevebaker> ayoung: would this not all be a non-issue if all services + horizon ran on the same IP, default port? I recall you proposing such a thing
21:23:09 <krotscheck> bknudson: Design request from dhellmann and dims was to make passing oslo's CONFIG object explicitly, rather than implicitly.
21:23:09 <notmyname> ttx: what's the question with this meeting topic? is there a particular resolution or action that needs to be taken?
21:23:17 <devananda> stevebaker: different ports ...
21:23:23 <morganfainberg> bknudson: the way I see it ( krotscheck correct me if i'm wrong ) CORS just informs a browser it is "ok", but all thread modling/access control still remains the same
21:23:24 <ayoung> stevebaker, I only proposed making it possible
21:23:32 <bknudson> you could set up apache to proxy the APIs then you wouldn't have to worry about CORS.
21:23:38 <ayoung> but I would not say that solves the problem, as that menas only one endpoint of each service
21:23:40 <devananda> so yea, if all the services ran on the same port, it would be a non-issue, except they dont (and can't)
21:23:45 <ttx> notmyname: it's a proposed cross-project spec, so it would be good to know which projects are happy with it and which are not
21:23:46 <ayoung> and we should be able to have multiple endpoints
21:23:52 <krotscheck> bknudson: That doesn't work in the case of an API that decalres dependencies as absolute URI's.
21:23:55 <notmyname> ttx: ok :-)
21:23:59 <ayoung> its not just a port issue, but hostname as well
21:24:02 <krotscheck> bknudson: You'd have to have apache rewrite all those links.
21:24:20 <ayoung> I mean, yes, if all the services were on 443 on the same host, you don't need  CORS
21:24:22 <krotscheck> bknudson: Example: Ironic.
21:24:26 <notmyname> I'd consider it a long-term, low-priority thing for swift (since we already have CORS support)
21:25:00 <devananda> ttx: iroinc is happy with it
21:25:23 <krotscheck> morganfainberg: That is correct. It just says "You're allowed to talk to this API"
21:25:31 <ttx> notmyname: right, unless it's incomplete/broken and krotscheck can prove it :)
21:25:32 <bknudson> ok, so we're not going to be able to put this middleware in our paste pipeline(s)... then we do have some work to do for keystone
21:25:48 <notmyname> ttx: right :-)
21:26:00 <krotscheck> ttx, notmyname: Even then, it's pretty important to make sure swift's awesome container-scoped CORS is supported.
21:26:06 <morganfainberg> bknudson: yeah. This is something that needs to follow the wsgi-layer fix for us.
21:26:19 <ttx> krotscheck: indeed
21:26:25 <bknudson> y, we're going to use flask.
21:26:40 <morganfainberg> bknudson: or it could be a lot of redundant work.
21:26:51 <notmyname> krotscheck: I have no problems with the idea, and having read the CORS spec many times, I think it's hard to read and very confusing. I'd love for it to be SEP ;-)
21:27:07 <notmyname> (Someone Else's Problem)
21:27:25 <krotscheck> notmyname: By which you mean, mine? The oslo team's?
21:27:33 <notmyname> heh. mostly "not mine" ;-)
21:27:42 <jokke_> notmyname: middleware and deployers responsibility to put it in the pipeline if feeling so?
21:27:51 * krotscheck doesn't know whether he can paint himself pink, and he's fresh out of italian bistro's.
21:27:54 <notmyname> that's the advantage of having the common code. you only have to solve it once
21:28:09 <annegentle> krotscheck: I may not be able to formulate my question well, but at the api docs session we talked about using Python's routes to auto-generate some API reference info.
21:28:20 <annegentle> krotscheck: do you expect another middleware would help or hurt that effort?
21:28:35 <krotscheck> annegentle: Had a conversation with someone during the ironic hack day about that.
21:28:44 <annegentle> krotscheck: guess it depends on configuration.
21:28:44 <jroll> notmyname: I think it's a solvable problem for swift; I see the shorter-term solution as using the middleware for the base api stuff, and then the swift built-in stuff for per-container things
21:28:46 <krotscheck> annegentle: I think the answer is: Both.
21:28:55 <annegentle> krotscheck: ha. Grrreeeeeaaaaattttt.
21:29:23 <krotscheck> annegentle: Help, because you can build swagger reference apps, that can be hosted anywhere, and talk to any API endpoint if it's properly configured.
21:29:34 <krotscheck> annegentle: Not help, because more documentation :/
21:30:00 <krotscheck> annegentle: But we did just manage to land the Config Reference autogenerator for oslo_middleware.
21:30:14 <bknudson> horizon and custom UIs might one day require this config.
21:30:31 <ttx> Alright, I think that's a nice overview/tour
21:30:33 <annegentle> krotscheck: okay. well, we don't need swagger reference app right away, we just want a JSON smoothie that we can build docs from. If I'm prevented from making my JSON smoothie I'm sad.
21:30:43 <ttx> Now it would be awesome if it translated to +1s on https://review.openstack.org/#/c/179866/
21:30:49 <ttx> (or -1s for the matter)
21:30:51 <krotscheck> annegentle: The only big catch is that, because of a browser's single origin policy, the error message from the browser itself is _not_ helpful if CORS isn't configured, and it's only accessible to people who happen to have the dev console open.
21:31:17 <krotscheck> annegentle: I'd be more than happy to provide any necessary ingredients for your smoothie :)
21:31:19 <annegentle> krotscheck: ok, yup.
21:31:23 <annegentle> krotscheck: awesome.
21:31:36 <bknudson> javascript must raise an exception if you violate cors.
21:31:37 <ayoung> If we go the CORS approach, and Horizon becomes a straight Javascript app, I think we would be heading the right direction.  Then  Horizon would use the same web APIs as the CLIs.
21:31:38 <etoews> annegentle: this wouldn't be a blocker for the api doc stuff
21:31:38 <annegentle> it might be a slurry. we're not real sure yet
21:31:57 <annegentle> etoews: ok cool. in a way it might help with consistency if we can set it locally while generating the docs
21:32:13 <ayoung> The degenerate case would then be the all-in-one install or the proxy/rewrite...I think we would have a range of options
21:32:15 <annegentle> "it" being "use CORS middleware please"
21:32:22 <krotscheck> It also permits each openstack service to build their own UI, should they want one, without having to depend on Horizon.
21:32:23 <devananda> ayoung: you have seen what I like about this :)
21:32:25 <etoews> might cause some bumps. could be another issue needing a spike solution to see if we can work with it.
21:32:32 <annegentle> etoews: I'll add to etherpad
21:32:42 <ayoung> devananda, I've been a proponent for a while.
21:33:30 <Madasi> krotscheck: that sounds like it could get confusing fast
21:33:33 <krotscheck> Frankly, the next big step would be to build JS-novaclient and js-keystonelcient and other things like that which can be used in whatever UI devs want to throw together.
21:33:48 <miguelgrinberg> etoews, annegentle: this shouldn't affect our ability to get the JSON data as we discussed last week, and it will help with issuing requests directly from the web based docs, so win-win in my view.
21:33:57 <bknudson> let's switch to node.js
21:34:00 <annegentle> nice
21:34:07 <krotscheck> bknudson: please no.
21:34:07 <devananda> so far I've only really talked to krotscheck about it, but having browser-based UI that talks directly to the API(s) is win, in my opinion
21:34:25 <ayoung> krotscheck, when I said "What this spec needs to show is where it should be in the pipeline for each of the projects."  Is that, if you are modifying the paste pipelines, thie needs to be before auth_token middleware
21:34:30 <ttx> it is win
21:34:35 <jroll> devananda++
21:34:40 <ayoung> and if there are any other middlewares that it also needs to preceed
21:34:47 <bknudson> ayoung: we were told that it can't be in the paste pipeline.
21:35:01 <krotscheck> ayoung: Gotcha. what bknudson said.
21:35:17 <ttx> krotscheck: ok.. anything else you wanted to cover ? Hopefully more people will vote on the spec now that it's been put in front of them
21:35:22 <krotscheck> ayoung: dhellmann and dims requested that passing the config object should be explicit, not implicit.
21:35:23 <ayoung> bknudson  and that also is now in the spec...I assume...I'm re-viewing
21:35:27 <krotscheck> Nope, I'm good!
21:35:38 <ttx> Last questions on that topic ?
21:35:51 <devananda> annegentle: re: autogenerating API docs discussion, this is the output of our autodoc runs: http://docs.openstack.org/developer/ironic/webapi/v1.html
21:36:08 <annegentle> devananda: yep I've studied :)
21:36:14 <devananda> annegentle: :)
21:36:15 <krotscheck> ttx: One question: How many +2's do I need?
21:36:54 <ttx> krotscheck: you actually need a general consensus... the TC usually picks up the spec once it has lots of +1s and will +2 it if it feels there is "consensus"
21:37:05 <ttx> by general I mean lazy
21:37:21 <krotscheck> ttx: Works for me :)_
21:37:50 <ttx> so exposing the spec at this meeting is to encourage people to express their +1/-1 on the spec so we can bring it to the next level
21:38:01 <ttx> #topic Suggestions to evolve this meeting format in Liberty
21:38:14 <ttx> This actually is a great intro to our next topic
21:38:23 <ttx> I'm looking at suggestions on how to improve this meeting for the upcoming cycle
21:38:32 <ttx> looking *for* I mean
21:38:39 <ttx> and the cross-project specs workflow in general
21:38:50 <ttx> IMHO it's not working that well, but it's still better than nothing I think
21:39:06 <ttx> So if you have suggestions on how to improve those please let me know
21:39:23 <ttx> In particular I think not having a clear attendance list for the meeting makes it a bit random
21:39:38 <ttx> A lot of people also seem to ignore specs until we raise them in-meeting
21:39:46 <johnthetubaguy> ttx: I should write up the details from the project management sessions
21:40:10 <johnthetubaguy> some good ideas for cross project epics, a little like the specs, but slightly different focus
21:40:14 <jokke_> I think we would need to clarify more between x-proj specs and oslo specs ... seems that lots of x-proj could just be dealt within oslo and adobted if necessary by projects. On the other hand This is nice to get heads up from people who thinks the spec affects many
21:40:58 <jungleboyj> I get the feeling that people are afraid to do x-project specs as they seem to not make progress.  Going to have to resolve that.
21:41:05 <notmyname> ttx: I think it would be good to have a more clearly defined goal for the standing meetings. other than "generally find out some things other people work on if ttx brings it up" having a meeting goal (per meeting or overall) would be helpful for me
21:41:08 <ttx> jokke_: yeah, we could have a look at the stuff we ended up approving a see a theme there
21:41:36 <notmyname> ie why do we have this meeting?
21:41:46 <notmyname> (not saying we shouldn't, but clarifying that would help, IMO)
21:41:48 <ttx> notmyname: right
21:42:11 <jungleboyj> notmyname: Seems like we need to publicize this meeting as they way to get x-projects specs looked at better.
21:42:12 <ttx> notmyname: at this point we are having it if somone puts a discussion topic to the agenda
21:42:14 <notmyname> ttx: and, honestly, I look to you as release manager to tell me the answer to that :-)
21:42:31 <ttx> it's more a "common meeting" than a release management one
21:42:37 <etoews> if there's any hope of getting these cross projects specs actually implemented we do need attendance from at least one representative from each project
21:42:42 <ttx> hence the new name last cycle ("crtoss-project meeting")
21:43:20 <ttx> etoews: we could technically turn it into a cross-project spec meeting (weekly or biweekly) where some liaison from each project would be required to attend
21:43:52 <nikhil_k> +1 biweekly if agena is open
21:43:54 <ttx> Like I said, I'm not happy with how it currently is, I just think that things would be worse if we just suppressed it
21:44:08 <etoews> ++
21:44:27 <nikhil_k> I think it would help to freeze the agenda a day before and have specs up so that people can check and plan to be here if needed
21:44:40 <fungi> the day-prior cancellations when teh agenda's empty seem fine to continue to me
21:44:47 <etoews> i'm not entirely sure how to get that one representative without overloading the teams
21:44:49 <ttx> nikhil_k: in the rare case someone else than me suggested an item, it was usually on the same day :)
21:44:55 <ttx> but yeah, we could set a deadline
21:45:01 <nikhil_k> :)
21:45:16 <annegentle> I agree with johnthetubaguy's suggestions for cross-pollination with the project management sessions, if they have valuable info it's good to share here.
21:45:18 <jokke_> Personally the biggest advantage of these meetings have been just general 1hr info about what's going on ... these things tends to raise rarely on the individual team meetings otherwise
21:45:34 <fungi> if someone comes up with an agenda item day-of, they can just use it to start the next week's agenda
21:45:34 <etoews> i think a deadline for the agenda is reasonable
21:45:41 <thingee> In my opinion, PTL's are suppose to help keep the bigger picture, not just be stuck in their project. I think PTL attendance is good versus liaison.
21:45:46 <annegentle> I also feel like I could have done a better job reporting docs work, but I didn't need to discuss each little bit of work, ya know?
21:46:12 <jungleboyj> thingee: ++
21:46:14 <annegentle> I wonder if Testing and Infra teams feel the same, since we're the cross-project teams but don't "use" this meeting necessarily to any end goal
21:46:14 <ttx> annegentle: in theory, horizontal team updates are fair game here, but almost none of them did such updates
21:46:29 <annegentle> ttx: right, noting that myself
21:46:47 <ttx> I like to have a point in time, weekly, where we can reach to all openstack projects, especially in a big tent setting.
21:46:52 <ttx> even if it's just a delegate
21:46:56 <annegentle> ttx: since we're all specialists with our own team meetings, not sure what we'd use this meeting for other than announcements
21:47:14 <etoews> ttx: yes, it's definitely necessary in one form or another.
21:47:23 <ttx> last cycle it turned out mostly cross-project specs.
21:47:27 <annegentle> etoews: agreed, it's needed
21:47:54 <ttx> But this cycle if we suppress weekly 1:1s between relmgt and PTLs(to replace them with adhoc pings) I guess we could reuse 5 min of the meeting to set the tone
21:48:36 <notmyname> ttx: I'd still like to be on the record as opposed to stopping 1:1s ;-)
21:48:38 * thingee uses this meeting to understand opinions on certain initiatives. Hearing thoughts from here and having a discussions on a spec is far better than just commenting on a spec and waiting.
21:48:51 <etoews> for me, this meeting is about the people who care about using openstack in its entirety.
21:49:16 <etoews> thingee: ++
21:49:34 <morganfainberg> thingee: ++
21:49:57 <ttx> notmyname: you can still ping me if we need to communicate. I'd say that in most of the weeks the Swift 1:1 was pretty boring -- something like "got the date for your next release ? Not yet."
21:50:29 <ttx> The project news update part of that 1:1 could easily migrate to another forum
21:50:48 <ttx> especially since nobody but me ever read those 1:1 meetings logs
21:51:10 <jroll> "if it's not on my calendar, it will never happen" is a real problem for some people, it would be nice if folks that want a 1:1 could continue to have one
21:51:18 <jroll> (imho, I am not a ptl) :)
21:51:36 <ttx> jroll: I guess the question is, to do what
21:52:05 <ttx> more than half of them were only duties communication, and we'll remove most of those duties and document the rest
21:52:06 * johnthetubaguy wishes the meeting was at a time he was so he felt he could contribute properly, and not be half asleep, or ideally send a substitute that could do a better job, notes he need to find someone to do that
21:52:07 <notmyname> the 1:1s are like the 1:1s you have between a boss and employee. normally nothing much happens, but it's a good time for both parties to hear the other one and know what's going on
21:52:23 <ttx> except I'm not the boss of anyone :)
21:52:35 <ttx> (well, I'm the boss of a few)
21:52:39 <johnthetubaguy> ttx: I see the change in the milestone tracking having the biggest impact on the 1:1s
21:52:41 <fungi> you're not the boss of me!
21:52:43 <fungi> oh, wait
21:52:58 <notmyname> ttx: sure, it's not a perfect analogy. just the principle of the idea in order to facilitate communication between parties that have very different views of the whole
21:53:14 <ttx> Anyway, I still hope to form some workgroup at the TC to improve that. That workgoup will be open so feel free to join it if it ever takes off
21:53:21 <jroll> ttx: right, so I have a standing 1:1 with my boss. sometimes it's cancelled. it's just nice to have the time blocked off in case one of the parties has a topic
21:53:27 <devananda> ttx: fwiw, I found them valuable around release time, in part cause I still forget some parts of that process
21:53:38 <ttx> right, we'd still have something around release times
21:53:42 <notmyname> jroll: yea,that
21:53:44 <jroll> ttx: for me, if it's not on my calendar, I'll forget to do it
21:53:46 <devananda> ttx: but in general i agree with everything else
21:53:50 <jroll> or push it off or whatever
21:54:03 <ttx> also FTR there will be at least two release managers for Liberty, dhellmann is now one too
21:54:06 <thingee> 1:1s for me is a time to get recommendations and to question some of my decisions. getting another perspective is useful.
21:54:14 <devananda> dhellmann: \o/
21:54:21 <morganfainberg> devananda: ++ around release time they are super super helpful
21:54:34 <jroll> ttx: maybe open "office hours" could work as a replacement, too, just an idea
21:54:46 <ttx> jroll: right, I think we'd do that
21:54:52 <johnthetubaguy> ttx: devananda: I was assuming we keep the release sync ups
21:54:52 <ttx> jroll: have some presence in some channel
21:55:04 <jroll> cool.
21:55:06 <ttx> although we also discussed moving back to #openstack-dev
21:55:13 <ttx> since it's unused
21:55:16 <ttx> mostly
21:55:24 <ttx> #topic Open discussion & announcements
21:55:42 <ttx> we can contiue on the previous topic, but anything can go now
21:55:46 <ttx> Anything else, anyone ?
21:56:05 <johnthetubaguy> ^ re previous comment, I meant 1:1 sync ups near release time
21:56:42 <johnthetubaguy> ttx: I want to write up the project manager discussion and get in touch with those folks to see if they remember it in the same way
21:56:45 <johnthetubaguy> that was kinda interesting
21:57:05 <ttx> johnthetubaguy: sound good
21:57:21 <johnthetubaguy> help collecting all the sub group feedback, and connecting them with the correct developers, and other things
21:57:31 <ttx> product^Wproject manager^Wmanagement^Winfluencers ?
21:57:37 <johnthetubaguy> a slight change in approach seemed to move towards something really useful
21:57:40 <johnthetubaguy> yeah
21:59:13 <ttx> hmm, is rbradfor here
21:59:20 <ttx> he had a quick thing to mention
21:59:52 <bknudson> what was with the rain jackets swag? does it rain the vancouver?
22:00:11 <fungi> i've pinged him in #openstack-infra but he must have /parted #-meeting
22:00:27 <fungi> bknudson: apparently it used to
22:00:27 <thingee> I appreciated it. I have way too many hoodies now.
22:00:38 <ttx> bknudson: apparently yes, usually
22:00:39 <fungi> like up until we showed up
22:00:44 <ttx> I guess that will be for another time
22:01:07 <ttx> Alright, that is a wrap
22:01:08 <bknudson> next is pants
22:01:09 <ttx> Thanks everyone
22:01:16 * jroll votes for sneakers
22:01:17 <jokke_> thanks
22:01:23 <nikhil_k> Thanks
22:01:26 <ttx> kimonos
22:01:28 <ttx> #endmeeting