16:03:05 <krotscheck> #startmeeting Storyboard
16:03:06 <openstack> Meeting started Mon Dec 15 16:03:05 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:10 <openstack> The meeting name has been set to 'storyboard'
16:03:23 <krotscheck> Agenda:
16:03:25 <krotscheck> #link https://wiki.openstack.org/wiki/StoryBoard#Agenda
16:03:38 <NikitaKonovalov> hi
16:03:40 <krotscheck> hey hey!
16:03:55 <krotscheck> #topic Actions from Last Week
16:04:24 <krotscheck> I pestered fungi some, and am working on a patch to add the new server.
16:05:01 <krotscheck> rcarrilocruz appears to be gone at the moment?
16:05:01 * fungi was not sufficiently pestered
16:05:05 <fungi> pester harder ;)
16:05:13 <krotscheck> fungi: I was busy writing cron things :-P
16:05:24 <fungi> touché
16:05:35 <krotscheck> #action krotscheck: Write a cron thing to pester fungi
16:05:56 <krotscheck> My patch is here: https://review.openstack.org/#/c/140466/
16:06:13 <krotscheck> I forgot to drop a line to both persia and rayna, my bad.
16:06:14 <krotscheck> Ugh
16:06:21 <krotscheck> #topic User Feedback:
16:06:31 <krotscheck> Anyone get any feedback from users?
16:06:37 <CTtpollard> krotscheck, I'll ping persia
16:07:16 <krotscheck> CTtpollard: Thanks. He said he’d do doc work on storyboard, but with no representation at the meeetings we can’t really get a sense of what he’s doing.
16:07:50 <krotscheck> A user feedback note from rcarrilocruz- we really need to add some documentation on how the deferred procesing engine works.
16:07:56 <krotscheck> #action krotscheck document deferred processing engine.
16:08:09 <krotscheck> Any other user feedback?
16:08:31 <CTtpollard> _o_
16:09:03 <krotscheck> kk
16:09:08 <krotscheck> #topic Urgent items.
16:09:17 <krotscheck> Is anything grossly broken at the moment?
16:09:47 <NikitaKonovalov> nothing that I've seen
16:10:05 <rcarrillocruz> working ok for me so far
16:10:15 <krotscheck> kk
16:10:36 <ttx> o/
16:10:43 <krotscheck> #topic Discussion Topics: Branch support
16:10:44 <ttx> sorry for being late, world on fire
16:12:02 * krotscheck hands ttx a fire extinguisher
16:12:19 <krotscheck> #link https://review.openstack.org/#/c/139613/
16:12:23 * krotscheck has not yet read that
16:12:28 * krotscheck feels bad about that.
16:12:48 <yolanda> i added some comments
16:13:58 <ttx> waiting for a bit more of feedback before pushing a rev2
16:14:08 <krotscheck> Ok, me will make it a point to comment today.
16:14:10 <ttx> especially need to know if everyone prefers calling branches branches
16:14:38 <krotscheck> jedimike isn’t here, so we can’t talk paging either.
16:14:43 <yolanda> calling him
16:14:52 <ttx> Called them "areas" in that draft to make them more generic and less code-oriented, but "branches" is probably also valid
16:15:18 * krotscheck doesn’t really have enough context yet.
16:15:19 <jedimike> o/
16:15:24 <krotscheck> Hey there!
16:15:29 <rcarrillocruz> tbh, i think branches make it more understandable , at least to me
16:15:40 * rcarrillocruz just reading quick the spec now...
16:15:58 <krotscheck> Ok, 5 minute break while everyone reads the spec, let’s actually discuss this thing.
16:16:16 <CTtpollard> I think the cross over to none code related work is the hardest to resolve
16:17:26 * SergeyLukjanov lurking
16:18:07 <yolanda> MikeHeald, that's the well written spec i've seen in long time :)
16:18:10 <rcarrillocruz> i assume this will need some schema change, what about schema migration?
16:18:18 <krotscheck> Ok, so ++ on the project-can-have-a-repo thing.
16:18:32 <rcarrillocruz> not sure if we could put something in the spec, or leave it for later on the change implementing it...
16:19:17 <NikitaKonovalov> rcarrillocruz: That looks like a typical schema + data migration
16:19:32 <krotscheck> I prefere branches too, though I’m a little concerned that it’s a word too closely tied to git?
16:19:34 <NikitaKonovalov> we've done that a few times in StoryBoard
16:19:55 <yolanda> +1 for branches
16:20:09 <NikitaKonovalov> +1 for calling branches branches
16:20:17 <ttx> a "branch of work" is clear enough
16:20:27 <ttx> even for non-git things
16:20:37 <krotscheck> +1 for calling branches “ponies"
16:20:37 <ttx> will fix in rev2
16:20:52 <CTtpollard> +1 for branch -1 for ponies
16:20:52 * krotscheck doesn’t actually want to call them ponies.
16:20:55 <krotscheck> :D
16:20:56 <ttx> I thought changesets would be ponies
16:21:11 <ttx> ponies in the sky with branches
16:21:19 <krotscheck> Ok, so consensus on actually using VCS terms to describe the VCS integration.
16:21:22 <krotscheck> ttx wins
16:21:34 <krotscheck> madness.
16:22:41 * krotscheck may have some real comments on the data table, but other than that he thinks this works.
16:23:37 <krotscheck> Is everyone still reading, or are we ready to move on?
16:23:57 * gothicmindfood is just wondering what unicorns are, then
16:23:59 <rcarrillocruz> we can move on
16:24:07 <jeblair> i'm fine with storing the git repo explicitly...
16:24:31 <jeblair> however i'm not convinced at the moment we should do anything other than what we're doing with the project names currently
16:24:59 <krotscheck> I’m just wondering if it should be a different table rather than a column in the projects table.
16:25:13 <jeblair> krotscheck: so that it could be 1-many?
16:25:36 <jeblair> that sounds frightening...
16:25:37 <ttx> I hate losing so much horizontal space. I would display "storyboard" instead of "openstack-infra/storyboard" on task lists. We can have the git repo appear on hovering
16:25:39 <NikitaKonovalov> do we need multiple repos for one project?
16:25:49 <ttx> NikitaKonovalov: no
16:25:54 <ttx> that's what projectgroups are for
16:25:57 <krotscheck> jeblair: Eeeh… perhaps? I’m still pondering it. Really I’m less of a fan of having empty unused fields in projects that don’t need a repo
16:26:32 <jeblair> krotscheck: i think that's what NULL is there for :)
16:26:52 <NikitaKonovalov> krotscheck: the projects table isn't big now, so the field should not make much harm to it
16:27:02 <krotscheck> jeblair: But it’s inefficient! [/german]
16:27:03 <jeblair> honestly, field in projects table with NULL is the best normalized form for this data i think, since it's either a single value or not present
16:27:27 * krotscheck doesn’t really have a valid argument
16:27:46 <jedimike> jeblair, +1
16:28:33 <jeblair> ttx: it's actually really a pita that launchpad project names don't match everything else... i'd like to avoid reinventing that pain...
16:29:00 <jeblair> ttx: the explicit field for git repo however, may be a mitigating factor (since we don't have that with lp)
16:29:02 <fungi> i saw getting rid of that mismatch as one of the up-sides to moving to sb
16:29:24 <ttx> jeblair: right, we basically store the missing indirection directly in the tool
16:29:33 <ttx> rather than maintain it elsewhere, which is where the pain lies
16:29:44 <jeblair> ttx: i think i'd like to see what that looks like before we consider altering the universal names....however...
16:29:48 <NikitaKonovalov> btw, are the repo urls stored anywhere in infra-config?
16:30:26 <krotscheck> I think I agree with ttx on this one. When we talk about storyboard amongst ourselves, we say: “Storyboard”. We don’t say “openstack infra slash storyboard"
16:30:27 <fungi> NikitaKonovalov: the components are implied from the full project names in openstack-infra/project-config:gerrit/projects.yaml
16:30:31 <jeblair> ttx: i still think we should allow storyboard to do what we are doing right now (openstack/foo) because it should be easy for people to create a system that supports multi-tenancy in the way that github and even git itself natively support
16:31:03 <fungi> NikitaKonovalov: but no, we don't have a file containing them all in actual url form
16:31:29 <fungi> NikitaKonovalov: so far that file assumes a 1:1 correspondence between project name and git repo url
16:31:29 <ttx> jeblair: But I like the diea that the git repo is not the main characteristic of a project. For example, calling "security advisory" the work aroudn a security advisory, with openstack/ossa being the associated git repo
16:31:32 <jeblair> so i don't think we should ever go as far as to say that '/' is not allowed in the name.  and for the moment, i think we should keep it in our names until we are certain it will not cause problems for us.
16:31:58 <NikitaKonovalov> then it looks like Storyboard is going to become a primary source for git repos
16:32:16 <jeblair> ttx: yes, i think it's a good idea
16:32:35 <ttx> jeblair: but frankly I hate "openstack-infra/storyboard-webclient" as a project na�e
16:32:37 <ttx> +m
16:32:52 <jeblair> ttx: also, i would like to get rid of the openstack/ by moving everything into openstack/.  ;)
16:33:13 <jeblair> but that's a different meeting
16:33:26 <ttx> jeblair: that would mitigate it. As would the UI writing the prefix in smaller font
16:33:58 <ttx> it's just wasting valuable space with non-information
16:34:25 <jeblair> well, potentially less valuable information depending on what you are doing, but i see your point.
16:34:33 <ttx> but then, the spec is not about that. It proposes a model that opens up more possibilities
16:34:57 <krotscheck> Does anyone disagree with having the full git repo be a primary field on the projects table?
16:34:59 <ttx> so that bridge can be burnt when we... err wait
16:35:07 <jeblair> ttx: ++ more possibilities.  let's explore how this will affect integration, etc, and burn bridges later :)
16:35:46 <NikitaKonovalov> krotscheck: what do you mean by primary?
16:36:04 <krotscheck> It doesn’t sound like it. Deciding how to name things after we get the repo path in can be left to the management team.
16:36:23 <krotscheck> NikitaKonovalov: It’s a new column in the projects table.
16:36:56 <CTtpollard> I think it's good to keep the repo as a primary field, for example some work my be on an in house git server and some might be on a public server
16:37:12 <CTtpollard> this might not apply to Openstack however
16:37:59 <krotscheck> CTtpollard: Interesting point.
16:38:06 <CTtpollard> but as was mentioned, maybe when you hover over a project name it could give you the repo url
16:38:51 * krotscheck wonders at the federation implications of that.
16:39:40 <CTtpollard> I've witnessed example for instance when somebody has gone routing through private git servers, to be then told later it was on github for instance
16:40:04 <krotscheck> Either way, I feel like the “what we name it” discussion is something that infra should do in its own meeting, as adding a repo column to projects neither harms them, and does present them with interesting new options.
16:40:31 <CTtpollard> ^ +1
16:40:33 <krotscheck> How someone uses a field is orthogonal to providing it.
16:41:10 <krotscheck> Everyone ready to move on? I want to give jedimike the floor
16:41:25 <krotscheck> #topic Discussion: Paging (jedimike)
16:41:38 <jedimike> let me just get the review url ready...
16:41:48 <jedimike> https://review.openstack.org/#/c/139638/
16:41:58 <jedimike> ok, first, thanks for everyone's comments and reviews
16:42:19 <jedimike> I've updated the spec today with an alternate snapshottig mechanism which ttx reminded me about
16:42:55 <jedimike> it's much lighter on the server and works much better with larger result sets, with a slight comprimse about how new data is shown. I've detailed it all in today's patch set
16:43:27 <jedimike> so, open to comments, questions :)
16:44:19 <krotscheck> jedimike: How do you want to proceed, do you want to bring up a specific thing for open discussion right now, or just defer to the spec?
16:44:38 <yolanda> spec looks good to me on the server side, i feel a bit strange how it works on the client side but i think it's a good compromise
16:45:04 <jedimike> I'll defer to the spec, but i'll just give the big picture view on what the expanding snapshot mechanism does
16:45:50 <jedimike> it's basically a way of guaranteeing that what you've *already seen* will not change, and when you want more pages, they'll be generated and snapshotted
16:46:21 <jedimike> so there's a comment in the spec about a slight ordering anomaly that might occur
16:46:31 <jedimike> but I think it's a decent compromise
16:47:01 <jedimike> and I'd quite like to see us produce a pagination lib that other projects can reuse too
16:47:36 <krotscheck> Well, that begs the question on what other pagination libs are available already :)
16:47:42 <krotscheck> But we’ll leave that to the implementor
16:47:44 <jeblair> jedimike: you may want to start talking to the oslo folks about that
16:48:13 <jedimike> jeblair, yes, I was a little bewildered about how horizon is doing pagination in the future too, it seemed a little strange
16:48:30 * krotscheck is going to move us to ongoing work
16:48:36 <krotscheck> In reverse alphabetical order!
16:48:51 <krotscheck> #topic Ongoing Work (yolanda)
16:48:57 <krotscheck> You were on call last week, yes?
16:49:02 <yolanda> krotscheck, yes, no much time
16:49:12 <yolanda> i added some tests to the grouping tasks today
16:49:13 <krotscheck> You had time to do code reviews, that’s good :)
16:49:23 <yolanda> and i started to work on angular-cache for preferences
16:49:32 <yolanda> but past week was quite busy for me
16:50:13 <yolanda> https://review.openstack.org/#/c/139100/
16:50:17 <yolanda> that needs review ^
16:51:10 <krotscheck> Cool!
16:51:17 <krotscheck> #topic Ongoing Work (NikitaKonovalov)
16:51:30 <NikitaKonovalov> so SDK is in progress
16:51:37 <NikitaKonovalov> rather slow though
16:51:51 <NikitaKonovalov> I have a change on review with base stuff
16:52:29 <NikitaKonovalov> so if everyone likes the approach I use there, I can add support for endpoints in a few changes after it
16:52:47 <NikitaKonovalov> #link https://review.openstack.org/#/c/138092/6
16:53:18 <NikitaKonovalov> right now it has /users endpoint and user_preferences subresource
16:54:07 <krotscheck> Alright, we’ll get t reviewing that :)
16:54:17 <krotscheck> #topic Ongoing Work (jedimike()
16:54:20 <krotscheck> Go go :)
16:54:58 <jedimike> sorry, this week has been quite busy and I've mainly been reviewing and working on specs
16:55:05 <krotscheck> We appreciate it :)
16:55:13 <krotscheck> #topic Ongoing Work (krotscheck)
16:55:17 <krotscheck> I wrote cron things!
16:55:21 <krotscheck> With TONS OF TESTS
16:55:24 <krotscheck> Which are now breaking.
16:55:26 <rcarrillocruz> heh
16:55:29 * krotscheck sighs
16:55:29 <jedimike> woohoo!
16:55:32 <jeblair> that's how you know they're tests
16:55:38 <CTtpollard> :P
16:56:05 <krotscheck> Well, for a time there I had a test that was breaking because of the speed of execution of the script could create an assertion race condition
16:56:10 <krotscheck> But hey.
16:56:12 <krotscheck> It works
16:56:14 <yolanda> krotscheck, you should end everything with self.assertTrue(True)
16:56:41 <krotscheck> Sometimes I end it with self.assertTrue(False) :)
16:57:02 <krotscheck> Anyway, I’m back on email full bore now, and spent most of friday reading all the various email header RFC's.
16:57:47 <krotscheck> I do have some questions on header rfc’s and will ping jeblair on that.
16:57:55 <krotscheck> #topic Ongoing Work (rcarrillocruz)
16:58:25 <rcarrillocruz> been off last week on vaca, and looked on things this weekend
16:58:38 <rcarrillocruz> i'm leaning towards gevent-socketio for the websocket streaming api
16:58:48 <rcarrillocruz> amongst the work items, that's the task i'm focusing on
16:58:52 <krotscheck> Alrightey.
16:59:01 <rcarrillocruz> hoping to have some prototype by the end of the week
16:59:01 <krotscheck> rcarrillocruz: Do you want discussion time next week to go over your findings?
16:59:13 <rcarrillocruz> sure, that'd be good
17:00:21 <krotscheck> Cool.
17:00:26 <krotscheck> And with that, we’re out of time.
17:00:28 <krotscheck> Thanks everyone!
17:00:30 <krotscheck> #endmeeting