15:00:33 <krotscheck> #startmeeting storyboard
15:00:34 <openstack> Meeting started Mon Jun 16 15:00:33 2014 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:37 <ttx> o/
15:00:38 <openstack> The meeting name has been set to 'storyboard'
15:00:41 <krotscheck> Roll call!
15:00:47 <ttx> \o
15:01:20 <NikitaKonovalov> hi
15:01:31 <krotscheck> #topic Validate Project and Project Group Names.
15:01:52 <ttx> I added it to the agenda because Nikita mentioned we shoudl discuss it at the meeting
15:02:05 <NikitaKonovalov> so, yep
15:02:05 <krotscheck> Righto, so what’s the summary?
15:02:08 <ttx> #link https://review.openstack.org/#/c/98728/
15:02:42 * krotscheck is reading
15:02:58 <NikitaKonovalov> The idea of making projects' names shorter is not that simple as it looks like
15:03:07 <jeblair> o/
15:03:27 <NikitaKonovalov> ttx said we should keep full names with a slash inside
15:03:29 <krotscheck> Was that a goal of project group? I thought it was more of an arbitrary organization thing.
15:03:33 <ttx> I think validating project and projectgroup names is good -- I just don't think we can assume that the / in there aligns to projectgroup boundaries
15:03:54 <NikitaKonovalov> it means we cant use this name in a url
15:04:08 <ttx> so let's take an example
15:04:46 <ttx> we have the storyboard API project. It maps to a repository called openstack-infra/storyboard. It belongs to several project groups, including "Infrastructure" and "All of Storyboard"
15:05:09 <ttx> What should the "project name" be ?
15:05:54 <ttx> should the name be the git repo name ?
15:06:02 <ttx> (that's what it currently is)
15:06:02 <jeblair> to elaborate on ttx's point (which i agree with), the '/' in git repo names is more or less ignored by gerrit -- there is no hierarchy there.  the only place that assumes that kind of hierarchy is github (which is an ancillary tool; not something that storyboard is designed for tight interaction with (though it should be _compatible_)
15:06:23 <jeblair> )
15:06:38 <ttx> I think one project = one git repo, so the name should be the same
15:06:42 * krotscheck thinks that the git repo should be a property of a project, but not tightly coupled to the name/title
15:07:03 <NikitaKonovalov> btw' are there projects w/o repos?
15:07:07 <ttx> krotscheck: that would work as well. The name would be an alias
15:07:14 <mordred> there have certainly been a request for them recently
15:07:20 <ttx> like "Storyboard API side" -> openstack-infra/storyboard
15:07:26 <SergeyLukjanov> o/
15:07:49 <ttx> I'm fine with that, as long as we keep the 1:1 mapping
15:07:51 <mordred> yah. and project groups were to encode that storyboard and storyboard-webclient are really both parts of "Storyboard"
15:07:55 <krotscheck> ttx: Right - OpenStack would just happen to have the convention that project name == gerrit name.
15:07:58 <krotscheck> Because that’s easy to remember.
15:08:02 <ttx> (1:n being modeled by projectgroups, basically)
15:08:28 <ttx> krotscheck: +1
15:08:48 <ttx> so Nikita's point is that "/" make unfriendly URLs
15:09:05 <ttx> although gerrit survives them alright
15:09:18 <krotscheck> NikitaKonovalov: There aren’t any right now, because (I think) jeepyb currently autocreates a repo whenever we add a project. There’s been a request for them though, just a lack of teaching jeepyb to do that thing we want it to.
15:09:57 <mordred> krotscheck: yah. and also, lack of clarity if we _should_ support that or not
15:10:05 <ttx> so he would prefer excluding "/" from project names, and goes on to use "/" as a way to separate projectgroups and project names at autocreation time
15:10:12 <mordred> or if we should assume that something should get a git repo even if it doesn't use it
15:10:27 <ttx> I think we should just accept "/" in project names.
15:10:27 <krotscheck> Angular doesn’t care about /’s in the URL, because it handles its own URL parsing in everything after the ‘#’. I think WSME/Pecan care though.
15:10:31 <krotscheck> mordred: That too
15:10:41 <SergeyLukjanov> ttx ++
15:11:14 <SergeyLukjanov> krotscheck, I think Pecan will ignore it after #
15:11:29 <NikitaKonovalov> we are not passing anything with a # to pecan
15:11:35 <NikitaKonovalov> so it should never know
15:11:36 <krotscheck> SergeyLukjanov: It will, but all of our API requests are pure URI's.
15:11:46 <krotscheck> #! routing is a javascript thing only
15:11:50 <SergeyLukjanov> krotscheck, oh, it was bad idea ;)
15:12:16 <jeblair> it seems slightly wasteful+confusing to do that; i think my inclination would be to not create a repo unless one is actually desired
15:12:18 <ttx> The alternate solution would be to use a simplified project name for every project (and have the repo name in a field)
15:12:26 <mordred> jeblair: yah. same here
15:12:30 <ttx> StoryBoard -> openstack-infra/storyboard
15:12:45 <NikitaKonovalov> If we are going to request projects by name from pecan, then simply escape all slashes or whatever
15:12:51 <ttx> StoryBoard Webclient -> openstack-infra/storyboard-webclient
15:12:56 <jeblair> ttx: that seems reasonable and compatible with krotscheck's suggestion of a few mins ago
15:13:09 <krotscheck> NikitaKonovalov: I can do that.
15:13:11 <ttx> It would certainly increase readability
15:13:40 <ttx> although that space i nthe second example is begging for abuse
15:13:58 <ttx> storyboard-api -> openstack-infra/storyboard
15:14:04 <krotscheck> ttx: Maybe in titles, but we do want the ability to type in storyboard.o.o/#!/project/openstack/superpants
15:14:11 <ttx> storyboard-webclient -> openstack-infra/storyboard-webclient
15:14:14 <ttx> dunno
15:14:24 <krotscheck> Ok, so here’s what I got from NikitaKonovalov’s suggestion
15:14:26 <mordred> I think I probably do
15:14:32 <ttx> krotscheck: "openstack/" has no value in there
15:14:33 <mordred> I mean, I could be wrong though
15:14:44 <mordred> but I'm _really_ used to config's name being openstack-infra/config
15:14:45 <krotscheck> ttx: It does, because it maps to gerrit
15:14:46 <jeblair> so as a convention, we have required that project names be globally unique (not just within their github-org)
15:15:08 <mordred> it would be weird to me to type storyboard.o.o/#!/project/config
15:15:33 <ttx> hmm, I think I just prefer we bite the bullet and use the repo name
15:15:38 <mordred> but I can also get over that if it makes everythign hard
15:15:49 <krotscheck> So, mapping #!/project/name-with-slashes to /v1/api/projects/escaped-name-with-slashes is easy
15:15:58 <NikitaKonovalov> krotscheck: agree
15:16:17 <krotscheck> Which means that in the URL, we use the git repo name because of convention.
15:16:29 <krotscheck> Sorry, not git repo name, you know what I mean
15:16:31 <krotscheck> With the slashes
15:16:46 <ttx> jeblair: so in theory we could say "storyboard" and have a field that is called github-org and that is used to build the full repo name
15:16:48 <krotscheck> It just happens to be the title, because that’s what OpenSack convetion is all about
15:17:12 <jeblair> gerrit uses: GET /a/changes/openstack-infra%2Fconfig
15:17:24 <krotscheck> Perfect
15:18:24 <krotscheck> Ok, so if it turns out that our naming validation on projects and project groups is : “Anything, you just have to escape it”, does it make sense to have any API-side validation at all?
15:18:27 <jeblair> ttx: as long as it isn't called "github" org, but just "org" or something -- but i think it would be better to ignore it as much as possible so we can support 0-N levels of hierarchy
15:18:43 <mordred> jeblair: +10000
15:19:18 <NikitaKonovalov> the second part of this is Should the prefix be treated as a project group or as an origanization field for a project?
15:19:20 <ttx> jeblair: I for one don't look forward to having new SB/gerrit mapping tables to replace the LP/Gerrit ones
15:19:40 <krotscheck> NikitaKonovalov: Neither, I think. If it’s a string, then the full title is the string.
15:19:43 <ttx> so I'm fine with using repo names directly
15:20:34 <jeblair> krotscheck: agree
15:21:15 <ttx> My only gripe with using full repo names is that they eat valuable space, but I'm pretty sure we can optimize that. Like if there is what appears to be a github-org prefix, display it nicely
15:22:45 <NikitaKonovalov> ok, then we keep the titles as they are, and the only thing needed to support them in urls is making projects API work with names
15:22:48 <krotscheck> What’s the full repo name thread about? I thought we were talking about names, where the project name will be ‘openstack-infra/storyboard’ by convention.
15:23:29 <ttx> krotscheck: it's an orthogonal discussion, ignore me. i'll be back with it
15:23:43 <krotscheck> ttx: Okie
15:23:48 <krotscheck> Summary:
15:23:58 <krotscheck> Project names are going to be escaped when they hit the API
15:24:17 <krotscheck> And we need to make them unique.
15:24:28 <krotscheck> Groups are not going to be automatically inferred from project names.
15:24:56 <krotscheck> And the webclient will start using unescaped-project-name and parse it to escaped-project-name.
15:25:02 <krotscheck> Did I miss anything?
15:25:22 <mordred> krotscheck: that seems like an excellent summary
15:25:33 <krotscheck> Any disagreements?
15:25:40 <NikitaKonovalov> names are already unique by constraint https://github.com/openstack-infra/storyboard/blob/master/storyboard/db/models.py#L141
15:25:54 <ttx> +1
15:25:57 <jeblair> +1
15:26:20 <krotscheck> Cool, let’s move on.
15:26:30 <krotscheck> #topic Specs
15:27:00 <krotscheck> Go talk about specs in the specs repo!
15:27:09 <SergeyLukjanov> krotscheck, +1 re prev point
15:28:08 <krotscheck> So we have three specs out there: Tagging, Search, Subscriptions
15:28:28 <krotscheck> The first two are still under active discussion, the latter seems to have settled?
15:28:38 <krotscheck> I wouldn’t mind having mordred or jeblair look at it though
15:28:47 <ttx> krotscheck: I had a question about your comments on tags
15:28:53 <krotscheck> Or, well, anyone form infra-core who’s familiar with how queues break down when under load.
15:29:01 <krotscheck> Ok, let’s talk about tags!
15:29:05 <krotscheck> #topic Spec: Tags
15:29:17 <krotscheck> What’s up?
15:29:30 <mordred> tags like lazer tag?
15:29:39 <mordred> cause that's fun
15:29:44 <ttx> krotscheck: tags are keywords, and you seem to hint you'd like to use them as a more generic name/value thing
15:29:46 <jeblair> krotscheck: looking forward to it, thanks
15:30:47 <ttx> a property that could be attached to any object
15:30:48 <krotscheck> ttx: Generic, yes. Name/value no. I’m starting to see them as our associations.
15:31:20 <krotscheck> So, for instance, if there are several people working on a task, that is represented at two tags that link task-to-user
15:31:37 <ttx> krotscheck: that's quite different from what I'm proposing. I'm not sure we can tweak my proposal until it does that instead of what I had in mind
15:32:19 <mordred> is it possible you're each talking about different features and both of them happen to be called "tag" ?
15:32:29 <ttx> maybe you should draft a separate one to explain what you start to see... it certainly sounds more ambitious than my lowly Launchpad tag equivalent
15:32:33 <krotscheck> mordred: That’s what I’m thinkign
15:33:04 <mordred> ttx: ++
15:33:16 <ttx> "My" tag is just about assocaiting keywords to stories, to get the same functionality we have with LP bug, a feature that we've come to rely on
15:33:28 <mordred> like "this is a gate bug"
15:33:39 <jeblair> mordred: ++
15:33:44 <ttx> associating them to stories let us get the benefit for bugs *and* blueprints.
15:33:50 <jeblair> or low-hanging-fruit, etc
15:33:56 <mordred> yah. low-hanging-fruit
15:34:02 <mordred> although I still dont' think we use that one well
15:34:03 <ttx> it's just a loose way to allow free-form categorization
15:34:10 <jeblair> mordred: mostly because we don't use bugs well
15:34:38 <ttx> krotscheck: that's what my spec is about... so i'm not sure how I should address your comments
15:34:48 <krotscheck> I still think they can be one and the same, but I’ll happily write up a spec to explain what I’m trying to accomplish.
15:35:23 <ttx> krotscheck: and i'll happily read it. As long as we can get the same functionality I'm looking for, I'm certainly open to an implementation that opens up more possibilities
15:35:33 <krotscheck> Works for me :)(
15:35:35 <krotscheck> :)
15:35:53 <ttx> the trick generally being... opening those extra possibilities without making the basic one unusable :)
15:35:53 <krotscheck> Honestly, I think that what you want is the first step to what I want.
15:36:24 <ttx> krotscheck: cool, we could even approve BOTH specs!
15:36:32 <krotscheck> MADNESS
15:36:42 <mordred> zomg
15:36:45 <krotscheck> Ok, so action for me: Write a generic tagging spec.
15:37:06 <krotscheck> We’ve got the search spec out there as well, anything you want to discuss NikitaKonovalov?
15:37:45 <NikitaKonovalov> the main discussion there is what should the query look like
15:38:10 <ttx> krotscheck: if there is time at the end of the meeting, i'd like to present https://wiki.openstack.org/wiki/StoryBoard/Roadmap again
15:38:16 <ttx> since last week it was just Nikita and me
15:38:37 <mordred> ++
15:38:55 <NikitaKonovalov> we can keep discussing it there
15:38:56 <krotscheck> ttx: kk
15:38:59 <krotscheck> ALright
15:39:04 <krotscheck> #topic Ongoing work
15:39:19 <krotscheck> Today in REVERSE ALPHABETICAL ORDER
15:39:42 <krotscheck> yolanda’s not here, she’s working on timestamps and date display, and sent me a directive that I need to debg
15:39:48 <krotscheck> ttx?
15:39:51 <ttx> The roadmap is basically taking the Juno etherpad, but I added a new milestone based on a suggestion from mordred. I think it nicely splits the MVP 1.2 work into more manageable chunks
15:40:01 <ttx> #link https://wiki.openstack.org/wiki/StoryBoard/Roadmap
15:40:18 <mordred> eek. giving me credit for ideas is scary
15:40:37 <jeblair> so, use openstack projects drop blueprints first, before bugs
15:40:46 <ttx> we basically implement the features needed to get integrated projects to use StoryBoard for feature planning, before the ones needed to get them to use it to track bugs
15:41:09 <jeblair> sounds reasonable, and i like the ramp-up aspect to it
15:41:10 <ttx> it's just a sane way to prioritize that big chunk of features
15:41:20 <krotscheck> Makes sens
15:41:23 <ttx> not sure how many projects will take the bait
15:41:39 <ttx> but in all cases that chunk was just too big, so splitting it made sense
15:41:42 <jeblair> ttx: we pretty much have to tell people not to use storyboard all the time.  :)
15:42:06 <ttx> krotscheck: I'm pretty sure you completed a few of those 1.1 lines, so feel free to edit that wiki page
15:42:17 <mordred> can I disagree with two of the thigns on that wiki?
15:42:36 <ttx> mordred: hey, it's a wiki. OH WAIT WHAT?
15:42:59 * krotscheck has tried to get mordred not to disagree on other things without much success.
15:43:07 <mordred> "task ordering" - blueprints doesnt have that right now
15:43:10 * krotscheck apparently likes his triple negatives, too.
15:43:18 <ttx> mordred: they actually havce
15:43:23 <mordred> and we use them?
15:43:23 <jeblair> mordred: yeah, work items
15:43:27 <ttx> mordred: it's called work items
15:43:30 <mordred> and we use them?
15:43:30 <jeblair> i just saw them used the other day
15:43:34 <mordred> oh. ok
15:43:39 <mordred> nevermind then
15:43:44 <ttx> mordred: we don't really use blueprints! So that's unfair.
15:43:45 <jeblair> mordred: i was like "oh yeah, that exists" :)
15:43:48 <mordred> I didn't think openstack used them
15:44:05 <ttx> mordred: but I see your point
15:44:22 <mordred> I guess what I'm trying to say is that we dont need to be feature complete with blueprints -we need to be feature complete with our incomplete usage of them
15:44:25 <ttx> it's just that to make a set of tasks useful in a blueprint setting, you kinda need to be able to order them
15:44:42 <mordred> sure
15:44:45 <ttx> to be feature complete with blueprints you'd have to allow only a single task in a blueprint story.
15:44:53 <krotscheck> FYI, I’m cutting this discussion off in 5 minutes, we need to give time for NikitaKonovalov and I to give summaries.
15:44:58 <jeblair> yeah, i think task ordering makes the cutoff for "usable with, borderline-unusable without", especially for a significant story
15:45:24 <jeblair> (without it, people would probably have to duplicate the info in the description to get it ordered)
15:45:31 <mordred> jeblair: ++
15:45:38 <mordred> I think I'm good with the wiki description in general then
15:45:39 <ttx> that's all I had. tried to spend time on reviews last week. Will do more.
15:45:51 <krotscheck> Thanks, ttx- we did land some good ones.
15:45:51 <mordred> although I think we need bulk import before 1.2.1 ... but that's not what we're talking about
15:46:28 <krotscheck> Ok, so summary of the roadmap: Task ordering is something we want?
15:46:31 <jeblair> yeah, that's in 1.1.1, but i think it may need to be in 1.1
15:47:22 <mordred> jeblair: oh! my bad. I was equating "bulk import" from the future with "lp data import"
15:47:24 * mordred shuts up
15:47:27 <NikitaKonovalov> krotscheck: I've been busy with my university graduation last week, and we had holidays is Russia
15:47:39 <krotscheck> NikitaKonovalov: You graduated?
15:47:45 <NikitaKonovalov> pretty much
15:47:45 <krotscheck> NikitaKonovalov: AWESOME
15:47:51 <mordred> NikitaKonovalov: congratualtions!
15:47:53 <ttx> and I thought French people were the only ones to have holidays
15:47:54 * krotscheck puts on a party hat
15:48:03 <mordred> krotscheck: you arent' still wearing one?
15:48:25 <NikitaKonovalov> so I was updating my Search spec and will continue doing that
15:48:32 <krotscheck> mordred: no, there was a very insistent gentleman who took it off with his teeth.
15:48:41 * krotscheck has no idea why
15:48:44 <mordred> oh my
15:48:54 <krotscheck> NikitaKonovalov: Ok. I’m starting to work on the UI section of search btw.
15:48:57 <krotscheck> So about that.
15:49:17 <krotscheck> I discovered thu/fri that there’s actually enough search-like functionality in storyboard to build out the UI I had in mind for search
15:49:32 <mordred> ooh neat
15:49:47 <krotscheck> So I’m working on that, and the mulit-resource search and routing is already all there.
15:49:58 <krotscheck> The missing piece is the advanced input field
15:50:13 <krotscheck> So you can search via the header, but that search string isn’t persisted into the actual search UI
15:50:29 <krotscheck> I’ve been doing that because my work on subscriptions is currently pending on config review
15:50:42 <krotscheck> First this one: https://review.openstack.org/#/c/98007/
15:50:48 <krotscheck> Then this one: https://review.openstack.org/#/c/98474/
15:51:41 <krotscheck> The first one grew out of the openstack-ci/puppet-storyboard disucssion where I’m tying to bring the two modules in sync with each other so we can eventually move infra over to the one in openstack-ci
15:52:14 <krotscheck> And in reality, the approach I’m taking is ‘doing a lot of work in infra-config, and then copying it over to openstack-ci
15:52:20 <jeblair> what's openstack-ci?
15:52:41 <krotscheck> jeblair: Argh
15:52:47 <jeblair> do you mean openstack-infra?
15:52:48 <krotscheck> jeblair: That’s be being stupdi
15:52:51 <krotscheck> Yea
15:53:02 <krotscheck> Eventually all that work will land here: https://review.openstack.org/#/c/96290/
15:53:28 <jeblair> okay, i'm confused because aren't we running the puppet that's in openstack-infra?
15:53:36 <krotscheck> jeblair: yes
15:53:43 <krotscheck> Which I thought was a bit confusing too.
15:53:47 <jeblair> or do you mean moving from openstack-infra/config to openstack-infra/puppet-storyboard?
15:53:54 <krotscheck> yes
15:54:01 <jeblair> that's a plan i'm fully in support of :)
15:54:09 <krotscheck> Right
15:54:19 <mordred> so the idea is to make all of the changes you would make to make a standalone module _in_ the config tree
15:54:20 <krotscheck> I would like to get the puppet module cleaned up a bit before moving over to puppet-storyboard though
15:54:31 <jeblair> krotscheck: that's a fine idea
15:54:32 <mordred> then land that as a patch to the empty puppet-storyboard repo
15:54:36 <krotscheck> And then to copy it all over.
15:54:39 <mordred> yes
15:54:39 <jeblair> yup
15:54:43 <krotscheck> Right.
15:54:44 <mordred> this is excelelnt plan
15:54:52 <krotscheck> So: Step one - https://review.openstack.org/#/c/98007/
15:54:59 <krotscheck> Step two: https://review.openstack.org/#/c/98474/
15:55:13 <krotscheck> Step three: copy step one and two to https://review.openstack.org/#/c/96290/
15:55:32 <krotscheck> Though technically step two can happen anywhere
15:56:04 * krotscheck is a little worried about the maount of work he’s already put into subscriptions without having the spec approved.
15:56:09 <krotscheck> But that’s my summary
15:56:19 <krotscheck> #topic Open Discussion
15:57:21 <mordred> krotscheck: I haven't followed the rabbit things ... which thing should I read to learn more about that?
15:57:44 <krotscheck> mordred: https://review.openstack.org/#/c/95307/
15:57:54 <krotscheck> mordred: Subscription spec
15:57:54 <mordred> thank you
15:58:54 <krotscheck> ANy other open discussion topics?
15:59:32 <krotscheck> Alright, let’s call it :)
15:59:37 <krotscheck> #endmeeting