16:00:53 <krotscheck> #startmeeting Storyboard
16:00:54 <openstack> Meeting started Mon Dec 22 16:00:53 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:57 <openstack> The meeting name has been set to 'storyboard'
16:01:42 <rcarrillocruz> o/
16:01:48 <rcarrillocruz> hi everyone
16:01:53 <NikitaKonovalov> Hi o/
16:01:55 <krotscheck> Agenda!
16:01:57 <krotscheck> #link https://wiki.openstack.org/wiki/StoryBoard#Agenda
16:01:58 <ttx> o/
16:02:09 <krotscheck> Actions from last week!
16:02:14 <krotscheck> #topic Actions from last week
16:02:24 <krotscheck> I have continued to pester fungi, but he appears to be immune to pestering.
16:03:05 <krotscheck> rcarrillocruz: You’ve done a lot of work on the streaming API, with quite a bit of success. Can you give us a summary?
16:03:11 <rcarrillocruz> sure
16:03:15 <rcarrillocruz> #link https://review.openstack.org/#/c/143304/8
16:03:39 <fungi> krotscheck: yeah, setuptools 8/pbr has more or less beaten several of us into submission for a week or so now
16:04:12 <rcarrillocruz> so, i had initially in mind using gevent-socketio, since socketio is cool in the sense that it downgrades automatically between various protocols if websocket is not supported
16:04:18 <yolanda> hi there
16:04:22 * NikitaKonovalov needs to look carefully at this change
16:04:26 <rcarrillocruz> websocket-> then it tries flash -> then something else
16:04:27 <rcarrillocruz> etc
16:04:41 <rcarrillocruz> but the problem is that gevent does not play well with pika
16:04:45 <rcarrillocruz> tornado does
16:04:55 <rcarrillocruz> so providing we already have pika in requirements, i opted to use tornado
16:05:03 <SergeyLukjanov> please, no flash
16:05:14 * krotscheck has a love hate relationship with flash :D
16:05:35 <rcarrillocruz> with the change above, if you open a websocket to http://<storyboard IP>:8888/events , you get a websocket connected
16:05:43 <rcarrillocruz> then do a 'suscribe <thing>'
16:05:54 <rcarrillocruz> and you start getting <thing> events piped to the websocket
16:06:25 <rcarrillocruz> this is a POC, the subscribe/unsubscribe format should be JSON and allow granularity on things to subscribe/unsubscribe, but you get the idea
16:06:37 <rcarrillocruz> i wanted to share if you think this is a good way to go forward
16:06:50 <rcarrillocruz> otherwise i could look to gevent or something like autobhan
16:07:03 <rcarrillocruz> those are the 3 framewors i've seen most mature for python websockets
16:07:14 <NikitaKonovalov> rcarrillocruz: I dont see anything looking like an initial request object when setting up a connection
16:07:33 <NikitaKonovalov> is there a way to access headers while establishing ws?
16:07:43 <NikitaKonovalov> we might need those to check auth
16:07:48 <rcarrillocruz> yes
16:07:51 <rcarrillocruz> tornado allows all that
16:07:57 <rcarrillocruz> let me dig up
16:08:17 <rcarrillocruz> http://tornado.readthedocs.org/en/latest/guide/security.html
16:08:33 <rcarrillocruz> it has decorators to wrap functions to make them fail if there's no auth
16:08:38 <rcarrillocruz> it has stuff for OAuth
16:09:08 * NikitaKonovalov likes when a framework has all we need
16:09:14 <krotscheck> Me too
16:09:15 <rcarrillocruz> ++
16:09:22 <rcarrillocruz> seems pretty mature
16:09:48 <krotscheck> So, from an intital look at the code this seems pretty readable. I haven’t stepped through the logic myself, but it feels like you’re on the right path.
16:09:49 <rcarrillocruz> it even has stuff for allowing multiprocessing, although i think we may want to put a LB in front and scale out tornado servers...
16:09:58 <rcarrillocruz> great
16:10:04 <yolanda> tornado is the one used or created by facebook , right?
16:10:13 <rcarrillocruz> yes, i think so yolanda
16:10:14 <krotscheck> Is this something we can run concurrent on the same server?
16:10:46 <rcarrillocruz> yes, so the idea would be using http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
16:11:11 <rcarrillocruz> to allow websocket pass thru apache running on the machine and pass those connections to the tornado server listening in 8888 or whichever port we put
16:11:11 <krotscheck> Oh neat!
16:11:38 <krotscheck> This suggests we don’t need to open up any new ports.
16:12:07 <rcarrillocruz> yeah, the idea is that apache would do his thing detecting is a websocket, then passing that to other internal port on localhost
16:12:19 <krotscheck> Excellent!
16:12:21 <rcarrillocruz> haven't tested that yet, but it seems others do that thing with nginx or apache
16:12:38 <rcarrillocruz> i can work on that this week as well
16:13:00 <krotscheck> Coooooool
16:13:17 <krotscheck> Quick question for fungi: What’s the current thougths in infra on ansible vs. Puppet? Are we still doing all the puppet things?
16:13:40 * krotscheck thinks we are.
16:14:05 <jeblair> krotscheck: yep
16:14:10 <fungi> yes, ansible is merely being used for orchestration
16:14:16 <fungi> puppet is still used for configuration management
16:14:19 <krotscheck> The reason I’m asking is that it may make sense for us to put a bit of time into our installation docs vis-a-vis single server to multi-server
16:14:44 <krotscheck> Cool, I’ll add a story for that.
16:15:03 <krotscheck> So, rcarrillocruz - things are looking good there, keep it up :)
16:15:21 <krotscheck> Next topic: ctpollard isn’t here, on vacation. Postponing to the new year.
16:15:36 <rcarrillocruz> excellent, thx :-)
16:16:00 <krotscheck> I didn’t get much done on the deferred processing engine docs, was working on the cron things instead.
16:16:25 <jeblair> krotscheck: can you elaborate on "The reason I'm asking is that it may make sense for us to put a bit of time into our installation docs vis-a-vis single server to multi-server"
16:16:26 <krotscheck> Honestly I feel like I’m yak-shaving a bit. I submit a patch, someone makes a small comment that’s actually a ton of work. I submit another patch, same thing happens, etc etc.
16:16:30 <jeblair> krotscheck: i didn't quite follow that
16:17:34 <krotscheck> jeblair: Storyboard is becoming a bit complicated as far as the install base goes. While it’s nice to have it running on one server for our own purposes, with downstream users starting to show up it may make sense to think about how we’d recommend separating services.
16:17:43 <krotscheck> Sorry- not install base. Installed components.
16:18:47 <krotscheck> jeblair: I don’t anticipate us needing it, but making sure that’s at the back of our brains as we put this together is starting to bug me.
16:19:26 <krotscheck> jeblair: Any more questions on that?
16:19:26 <jeblair> krotscheck: yeah, should definitely keep it in mind.  though i'm still comfortable saying that we should focus on getting it running for openstack first, and we should expect to be the largest installation of it for some time
16:19:30 <jeblair> nope
16:19:36 <krotscheck> Coolio.
16:19:46 <krotscheck> #topic User Feedback
16:19:49 <krotscheck> Anyone hear anything?
16:20:01 <rcarrillocruz> niet
16:20:10 <jeblair> i think i've filed some stories about ui quirks
16:21:42 <krotscheck> jeblair: Nice. Those are getting lost at the bottom of the queue though ebcause bigger effort items are at the top.
16:22:25 <jeblair> rcarrillocruz: [btw, i think etherpad-lite can support websockets.  we should probably enable that apache module there not only because it's a good idea, but it'll also give us some more experience with it]
16:22:59 <rcarrillocruz> oh
16:23:06 <rcarrillocruz> sure, good idea
16:23:13 <krotscheck> #action krotscheck Figure out how to surface recent things so that we can work on them.
16:23:14 <jeblair> krotscheck: yeah, that makes sense.  i don't think any of them are critical
16:23:25 <rcarrillocruz> i'll work on a change for that
16:23:28 <jeblair> would make good little things to take a break from the bigger things ;)
16:23:51 <krotscheck> jeblair: Yep. Believe me, there’s something about the dashboard that’s been bugging me for AGES and I really want to fix it.
16:24:03 <krotscheck> I want to consolidate all changes to a specific story under one story header.
16:24:18 <krotscheck> Like: In story X, foo happened, then bar happened, then fwiffo said something....
16:24:20 <rcarrillocruz> maybe it improves etherpad latency, it has some issues for me sometimes...
16:24:50 <jeblair> krotscheck: in "recent events"?
16:25:01 <krotscheck> yep
16:25:09 <krotscheck> jeblair: Also, the fact that you can’t link through to comments.
16:25:27 <jeblair> i have no recent events right now, but i think i can imagine that and it sounds good :)
16:25:51 <yolanda> krotscheck, looks as a good idea to me
16:25:58 <yolanda> my recent events tab is messy
16:26:32 <ttx> no kidding. I clicked 234 times on that close icon today
16:26:49 <krotscheck> ttx: I know, right?
16:27:00 <yolanda> would it be a good idea to auto-remove some old recent events?
16:27:06 <ttx> Also reading a comment and having to guess which story it belongs to is a fun game
16:27:13 <zaro> o/
16:27:30 <ttx> especially when the comment is "that's the worst idea ever!"
16:27:40 <rcarrillocruz> :-)
16:27:54 <NikitaKonovalov> can we also have a list of stories that a user is subscribed to?
16:28:09 <krotscheck> NikitaKonovalov: Yeah, subscription management also seems like a sane thing.
16:29:35 <krotscheck> #action krotscheck Add Subscription management and Update Recent Events UI as Stories.
16:29:42 <krotscheck> Ok, moving on to urgent things
16:29:45 <krotscheck> #topic Urgent Items
16:29:51 <krotscheck> So updates on storyboard.o.o seem to be broken.
16:29:56 <yolanda> yes, we pinged fungi
16:30:09 <yolanda> looks as puppet was not running, he has submitted a change to fix it
16:30:17 <krotscheck> Cool, is there a patch?
16:30:32 <yolanda> https://review.openstack.org/143474
16:30:36 <rcarrillocruz> i think fungi pushed something already
16:31:05 <krotscheck> Ok, that was 8 mintues ago.
16:31:18 <yolanda> i still don't see new changes coming
16:31:42 <krotscheck> Let’s keep an eye on http://puppetboard.openstack.org/node/storyboard.openstack.org
16:31:47 <fungi> it will take minutes and minutes for that to go into effect
16:32:09 <fungi> you might check http://puppetboard.openstack.org/ in a few more
16:32:26 <krotscheck> Alright, so that’s well in hand. Moving on.
16:32:32 <krotscheck> #topic Discussion topics: Branch Support
16:32:53 <ttx> krotscheck: replied to your comment there
16:32:57 <krotscheck> ttx! Seems like that spec’s in good shape, and we’ve already got a patch from aleksey against it!
16:33:43 <krotscheck> #link https://review.openstack.org/#/c/143455/
16:33:53 <NikitaKonovalov> btw, Aleksey is a new developer @ Mirantis. He is dedicated to SB.
16:33:55 <krotscheck> (Incidentally, who’s Aleksey?)
16:33:58 <krotscheck> WOO
16:34:06 <krotscheck> Where’s he located?
16:34:07 <SergeyLukjanov> :)
16:34:14 <SergeyLukjanov> krotscheck, next table to us :)
16:34:18 <NikitaKonovalov> yep
16:34:21 <krotscheck> Oh good. Pelt him with chocolate.
16:34:27 <krotscheck> Or vodka
16:34:28 <yolanda> krotscheck, ok, i asked a question to Aleksey, because i only saw changes for git_repo
16:34:41 <krotscheck> Oh wait. Wrong story
16:34:44 * krotscheck cannot read.
16:34:47 <krotscheck> My apolgoies.
16:35:14 <krotscheck> Anyway, back to the topic, I’m pretty comfortable with the branch spec, does anyoen else have any issues with it?
16:35:40 <ttx> krotscheck: open question on the implementation side on whether we want to always assocaite tasks to branches (and use a default catch-all branch called 'master' in non-code cases), or allow NULL there
16:35:47 <rcarrillocruz> i'm ++ on it
16:36:03 <ttx> I'd argue a default branch is simpler (NOT NULL)
16:36:27 <ttx> but then I'd start treading into implementation too much
16:36:47 <NikitaKonovalov> NULL looks good because it will allow to filter out tasks w/o branches and tell some to assign branches
16:37:03 <NikitaKonovalov> the task with default branch can live unnoticed
16:37:04 <krotscheck> Good point NikitaKonovalov
16:37:09 <ttx> NikitaKonovalov: I'd argue there is no such thing as a task without branch
16:37:28 <ttx> A task has a project and a branch
16:37:33 <krotscheck> I don’t think the Win The Enterprise team has branches.
16:37:44 <ttx> krotscheck: they have a single branch.
16:37:49 <ttx> the default one.
16:38:12 <ttx> and the UI hides it away from them, since there is a single branch, so nothing to choose there
16:38:13 <krotscheck> Do they have a repository?
16:38:29 <ttx> krotscheck: srsly we had that discussion already
16:38:44 <ttx> I called it "area" so that you stop thinking about code branches
16:38:51 <krotscheck> Right.
16:38:54 <ttx> and then people complained that "area" was too vague
16:39:03 <ttx> so I fixed it back to call it "branch"
16:39:12 <ttx> but that may or may not represent a CODE branch
16:39:29 <ttx> that's a branch of work in the project. If you only have use for one category, then just use the default one
16:39:59 <ttx> so if WTE has no code and no branch, their work is always associated with the "default branch"
16:40:20 <ttx> which I would call 'master' since that's what the default branch is called for code-backed repos
16:40:31 <ttx> (but then, that's all written in the spec)
16:40:37 <yolanda> ttx, makes sense to me to always have a default branch
16:40:47 <krotscheck> Right. I think it’s just a question of calling a duck a duck. If a project has code, it shoudl have a git repo and branches. And I’m ok with that being represented directly in the table. I also feel that work areas may be separate from cdoe themselves, and that that idea also has merit, but perhaps not right now.
16:40:50 * krotscheck yet.
16:41:25 <krotscheck> i.e. I want both.
16:41:32 <krotscheck> But right now we only care about code.
16:41:40 <krotscheck> At least that’s the way I’m thinking about it.
16:41:45 <ttx> krotscheck: couldn't they be reporesented with the very same construct ?
16:41:54 <krotscheck> ttx: Should we overload the construct?
16:42:11 <krotscheck> ttx: Or, better question: Can a project have both code and distinct work areas?
16:42:21 <krotscheck> Say, security work on the icehouse branch?
16:42:57 <ttx> krotscheck: I'd say no
16:43:17 <krotscheck> That’s fair, and it’s orthogonal to the spec anyway.
16:43:21 <ttx> tasks are unit of work. They result in a patch on a branch, or something else
16:44:00 <ttx> so the branch/area thing is "where the work lands"
16:44:12 <krotscheck> Plus, if at some point in time we choose to create distinct different concepts of area and branch, we have a way to select tasks that have a default branch that are not associated to a project that has code - ergo we could clear those later if we need to.
16:44:25 <NikitaKonovalov> and we can allow a project to have its own default branch. Then it can be called whatever suits best. master for code repo, direction of work, etc
16:44:44 <ttx> right
16:45:22 <ttx> So I would answer my earlier question saying... all tasks must have a branch.
16:45:25 <krotscheck> So I have no objections to default branches.
16:45:40 <krotscheck> I’m ok with them not having a branch :)
16:46:08 <krotscheck> Either way, we can move forward.
16:46:10 <ttx> krotscheck: I'm not oK with that, because it creates an area where it's nobody's work to handle the task
16:46:22 <ttx> same reason why i don't like stories without tasks
16:46:43 <NikitaKonovalov> The migration script should create a default branch for each project then
16:47:47 <ttx> project/branch combination uniquely defines which group is responsible for the task
16:47:53 <ttx> project alone is not enough
16:48:24 <krotscheck> ttx: You’re starting to conflate groups and code now. Do we have a spec for groups yet?
16:48:25 <ttx> example: nova/stable-juno means the work is on backporters, and the stable liaison is ultimately resposnible
16:48:50 <ttx> example: nova/master: work on regular devs, PTL ultimately responsible
16:49:17 <ttx> krotscheck: not talking assignees here. I'm talking how people will use the thing
16:49:17 <krotscheck> ttx: For every example there’s counterexamples, let’s focus on how we handle adding code repository references to our tasks, ok?
16:49:38 <krotscheck> And on that topic, I feel we’re pretty well settled on the spec.
16:49:40 <NikitaKonovalov> but right now each task is assigned to a project so, the set of default branch per project should be enough to start
16:49:51 <ttx> NikitaKonovalov: ++
16:50:31 <NikitaKonovalov> and then let the people decide if they like the default branch or they want to change it immediately
16:50:36 <ttx> Just saying people will add stories and tasks. and some group will pick them up. And that group is uniquely defined by the project/branch combination
16:50:56 <ttx> not talking storyboard groups here)
16:51:01 <ttx> just people using it
16:51:44 <krotscheck> namaste, ttx. I totally understand your view of things. I disagree with some finer points, but you don’t have to convince me of the overall direction.
16:52:05 * ttx crawls back to his hole
16:52:16 <krotscheck> Oh no you don't.
16:52:21 <krotscheck> We need you out here.
16:52:26 * krotscheck drags ttx back out.
16:52:39 <ttx> ouch ouch
16:53:38 <krotscheck> We’re running out of time unfortunately.
16:54:11 <krotscheck> So: Active Specs Branch Support. I heard a + from me, from NikitaKonovalov, from yolanda and from rcarrillocruz, and ttx authored it.
16:54:41 <krotscheck> I don’t actually hear anyone disagreeing with this spec, so do we agree on moving forward with implementation?
16:54:52 * ttx will rebase the story types story on top of the branch/milestone specs
16:55:17 <ttx> and will work on a milestone report spec, even if that's further away in implementation time
16:55:37 <krotscheck> Speak now or forever hold your peace!
16:55:43 <ttx> I mean rebase the story types *spec* on top of the branch/milestone specs
16:56:05 <krotscheck> #agreed Mark https://review.openstack.org/#/c/139613 as ready for implementation
16:56:35 <krotscheck> I’m going to skip over all the next things to switch to open discussion in case there are burning issues for the last few minutes.
16:56:41 <ttx> +1
16:56:42 <krotscheck> #topic Open Discussion
16:56:44 <krotscheck> I’ve got nothing.
16:57:02 <yolanda> krotscheck, wanted to talk  about preferences caching
16:57:16 <yolanda> but we can talk after the meeting, no time...
16:57:17 <NikitaKonovalov> I've got base classes for python client covered with tests on review
16:57:18 <krotscheck> yolanda: Yes I did!
16:57:26 <NikitaKonovalov> now working on endpoints
16:57:31 <krotscheck> yolanda: Aren’t you on vacation?
16:57:38 <krotscheck> NikitaKonovalov: that makes me increidbly happy
16:57:40 <zaro> i wanted to discuss tasks and how they map to gerrit changes?
16:57:44 <yolanda> yes, but i'm computer addicted :)
16:57:44 <NikitaKonovalov> Users and Preferences are almost ready
16:57:58 <NikitaKonovalov> Teams, Projects, Project groups coming next
16:58:04 <krotscheck> NikitaKonovalov: Neat
16:58:12 <rcarrillocruz> NikitaKonovalov: awesome :-)
16:58:13 <krotscheck> yolanda: GO ON VACATION, YOU HAVE FAMILY :D
16:58:25 <yolanda> :)
16:58:39 <krotscheck> zaro: ttx: Sounds like tasks may need an adidtional field for patchset.
16:58:55 <krotscheck> That feels like it’s related to branch support.
16:58:59 <zaro> needs something.
16:59:27 <zaro> stories to changes is not grandular enough IMO
16:59:36 <krotscheck> zaro: Yeah, it should be tasks to changes.
16:59:55 <zaro> so it also means task needs status transitions
17:00:12 <krotscheck> zaro: We’re out of time, let’s take it into channel.
17:00:17 <krotscheck> Thanks everyone!
17:00:19 <zaro> basically IMO tasks needs to be the smallest unit in sB
17:00:29 <krotscheck> #endmeeting