14:19:16 #startmeeting storyboard 14:19:17 Meeting started Thu Nov 28 14:19:16 2013 UTC and is due to finish in 60 minutes. The chair is cody-somerville. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:19:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:19:21 The meeting name has been set to 'storyboard' 14:19:26 o/ 14:19:27 o/ 14:19:33 hi 14:19:38 lookie here. how exciting 14:20:00 #topic Introductions 14:20:05 o/ 14:21:10 So I thought we could first start by introducing ourselves, where we're based out of, why we're interested in storyboard, and how we're interested in helping. 14:21:44 SergeyLukjanov: Would you like to start? 14:21:50 cody-somerville, sure 14:22:38 I'm the Savanna PTL, I'm interested in cool issues/specs tracking system 14:22:41 :) 14:22:59 especially for releasing, milestones, series and etc. 14:23:31 * mordred is on infra-core, and employs a set of people who will be hacking on this. also wants to finish killing launchpad 14:23:48 SergeyLukjanov: if everything goes well for Savanna, you might not have any time left anymore though. 14:24:00 Hi! You know me, based in France. Mostly interested in making sure the end result stays in the original philosophy and serves OpenStack coordination needs. Might continue coding it in my copious free time, just because I like small projects. 14:24:21 ttx: you have plenty of free time 14:24:28 mordred: I do! 14:24:39 all my time is free as in freedom. 14:24:57 ttx, I know now how it works and I'd like to make this process better :) 14:25:11 ttx, and we have a lot of other projects on stackforge 14:25:29 SergeyLukjanov: ack 14:25:41 My name is Cody, I'm in Ottawa Canada, interested in helping realize ttx's vision, and particularly interested in helping out from architectural and implementation perspective. 14:26:08 I have been developing a Horizon plugin for Savanna recently, and I'm interested in developing smart UI's, and since Storyboard is just starting, I see a great opportunity in it 14:26:38 I'm also in the process of hiring a set of people to help with storyboard development (I work for Monty). 14:27:24 Awesome. 14:27:25 cody-somerville: do you have a vague timeframe for that hiring process ? 14:27:43 ttx: So far I have two people starting on December 9th. 14:27:56 fwiw I'm dreaming about useful reporting, stats and etc... 14:28:19 cody-somerville: are their names public yet? 14:28:30 Awesome. I think that's everybody here today. Thank you SergeyLukjanov, mordred, ttx, and NikitaKonovalov :) 14:28:32 hi. i'd like to contribute all my available time to storyboard too. things i'd like to improve: search and reporting 14:28:47 Oh. Hey there ruhe! 14:28:48 ruhe: awesome! 14:28:49 Welcome! 14:28:58 cody-somerville, ttx: we sent out a third and fourth offer 2 days ago 14:29:10 tentative start date dec 16 14:30:19 ttx: Haven't released any names publicly per-say. 14:30:29 cody-somerville: ok 14:31:08 #topic Proposal: Use storyboard to develop storyboard - CD/CI from trunk to instance used track and plan storyboard development. 14:31:42 cody-somerville: I think that's a good idea, the trick is to arrive to the point where we can actually do that. Which would be.. a stable DB schema, I'd say 14:31:49 so, last time jeblair and I talked, he said "fix the leave-comments bug and infra can start using it now" 14:32:01 I'd like to propose that our first goal should be to take what we have and get it up and running with CD/CI from trunk and use that instance to track and plan storyboard. 14:32:05 cody-somerville, +1 14:32:18 yah. I'd like to that too - and if we have to do db migrations, then so be it 14:32:32 otherwise I fear we're going to sit in the land of not-quite-ready for ever 14:32:44 So in today's world, I'm not sure we'll ever have a stable DB and so we might as well solve the problem of db migrations now. 14:33:10 mordred: since I added project groups I think the biggest obvious DB overhauls are done now 14:33:17 yah. I agree 14:33:31 agree, so we have stabilize db and all frameworks around as soon as possible 14:33:32 also, when did I start saying "yah" instead of "ja" ... very weird 14:33:48 and using it for tracking storyboard (instead of ahem github issues) sounds like an obvious first step 14:34:00 Part of that will be investing in some features/scaffolding that is usually more indicative of a more mature project such as feature flags and incrementally landing changes that involve large db changes. 14:34:07 ttx: also, I think infra is game to be an aggressive first guinea pig too 14:34:36 currently we have a django-based PoC and planning to move Pecan/WSME backend 14:34:48 mordred: my only regret will be that it's two projects that won't make a lot of use of cross-project facilities, but meh 14:34:51 it could possible change db schema 14:34:58 SergeyLukjanov: so ... I pitched something to cody-somerville about that the other day 14:35:02 although you could imagine storyboard+infra stories, for sure 14:35:06 in auth/users part especially 14:35:15 oh. 14:35:17 oh. 14:35:20 we still can use wiki to keep important data safe, which db model 14:35:20 actually... 14:35:31 which -> when 14:35:33 which is that I _think_ we might want to think about pecan/wsme as a v2 idea 14:35:38 mordred: infra would be split by repo and use an "Infrastructure" project group 14:35:46 ttx: ooh. excellent! 14:35:53 since tere is a strong project/repo relationship in storyboard 14:36:03 yah. I think that's a great idea 14:36:09 mordred: so it would make sense to dogfood that extensively 14:36:25 my concern is that if we'll continue developing current code than migration to pecan/wsme will be full rewrite 14:36:27 SergeyLukjanov: so, if we get storyboard up and going and CI/CD on the django 14:36:42 and then we have a period of a month where we're not landing new features because we're redoing plumbing 14:36:55 with regards to Pecan/WSME, I think we need to evaluate that further. 14:36:55 and then we have a downtime event to do a migration - I think I'm fine with that 14:37:21 SergeyLukjanov: it might be a full rewrite - but it might also be able to be done incrementally 14:37:21 mordred: you could also additionally use a specific projects for random "infra" requests like tickets from people who have no clue if it belongs to config or jeepyb (i.e. most people) 14:37:38 i.e. infra-tickets or something 14:37:40 SergeyLukjanov: if we started by just splitting out the current db model and putting a pecan/wsme api on top of the current model api 14:37:52 we need support for fake projects anyway, for stuff like OSSA/OSSN 14:37:57 ttx: ++ 14:38:11 (i.e. stuff where the fix is not a commit) 14:38:24 SergeyLukjanov: I agree though about auth getting more complex 14:38:26 :) 14:38:31 the more I think about it, the awesomer it gets. 14:38:39 mordred, I mean that if we'll continue developing current code for the *long* time than ... 14:38:43 yah 14:38:46 We're getting a bit offtopic. 14:38:56 I think if we hack on it even for a little bit so that we get our hands dirty with 14:38:58 it 14:38:59 indeed. 14:39:10 it'll help to be able to make better long-term framework decisions 14:39:15 (I think we're still on topic) 14:39:25 (ttx: I'd like to solve that problem more gracefully then with fake projects, I have some ideas) 14:39:30 because we're talking about the pros and cons of deploying soon 14:39:37 agreed 14:39:53 (cody-somerville: ok, ping me anytime) 14:40:04 but - in any case, I think getting one up and letting a few resilient projects, like storyboard and infra and UX beat on it for a while 14:40:08 it'll serve us well 14:40:24 and then even if we do a full rewrite for a v2 - so be it 14:40:42 sure 14:40:48 v1 took ttx a day or so - a team of us who all grok the problem space should be able to churn out a better v2 in a couple of weeks :) 14:40:59 cody-somerville: so the on-topic answer is yes please. Anything we need to add to current storboard before going in CI/CD mode ? 14:41:01 grokking the problem space as well as ttx is the hardest ramp-up part 14:41:06 mordred: "or so" 14:41:08 probably some more work on v1 could help us to make right decisions 14:41:09 ttx: :) 14:41:12 we also can import data from LP to storyboard to see how it look on existing projects 14:41:37 ruhe: yes. and even if that isn't the final import tool, I think we'll learn alot about it 14:41:41 mordred: I was thinking this initial goal would be to get something up for storyboard, not necessarily for -infra as well. Are you suggesting the latter? 14:41:57 cody-somerville: I'm suggesting that infra is quite willing to also be early guinea-pigs 14:42:01 cody-somerville: step 1 storyboard, step 2 infra, UI 14:42:14 since this is ultimately part of the infra program 14:42:23 s/quite willing/eager/ 14:42:34 I just want to make sure we properly manage expectations. 14:42:38 I think organizing milestones around what it takes to get new guinea pigs is a good way to prioritize 14:42:46 ttx, so the plan is to get working rest backend and only then start working on UI part? 14:43:17 ruhe: nope. we're going to keep working on the current django codebase for now, and start deploying it asap 14:43:20 * cody-somerville curses ttx for having such a shiny proof of concept. 14:43:29 ruhe: I think the rest decoupling (as well as the potential move to SemanticUI) would be parallel to the Ci/CD/onboarding-guinea-pigs effort 14:43:38 ++ 14:43:42 ok, i see. thanks 14:44:16 I actually think it's great taht ttx's POC is distractingly shiny ... 14:44:21 I don't think anyone in storyboard or infra will require REST or Semantic UI to be present before they start using it 14:44:28 because it points out that at its heart we can keep this relatively simple 14:44:35 that's correct 14:44:47 we'll require that comments work 14:44:52 then, should we have a list of things to do before deploying? 14:44:53 and issues don'tget deleted 14:44:53 To put it another way I guess, storyboard today is so good people want to see and play with it. And it's strategic to do so to establish the project. CI/CD bit makes sense. Also still supports us being able to do fully rewrite still if we decide we need to go in crazy different direction. 14:45:09 agree 14:45:22 main thing we need is the puppet manifest written :) 14:45:33 yup 14:45:58 luckily - we have at least 2 other django apps we run (I think) so cargo-culting some puppet should not be hard 14:46:29 but yeah. IMHO there are 4 different areas. Concept (like that fake project discussion), Architecture (REST/UI decoulpling), UI (Semantic?), CI/CD/onboard-guinea-pigs 14:46:44 mordred: How easy is it to simulate deployment in say hpcloud of what -infra will do to get it running? 14:46:46 ttx: agreed. 14:46:50 and IMO we need to collect ideas/requirements, prioritize them and map to frameforks 14:46:51 but by using the last to drive the main milestones we stay close to our users 14:47:04 s/frameforks/frameworks/ 14:47:32 We need to tackle Concept asap due to its potential impact on CD 14:47:35 cody-somerville: pretty easy. we've got docs somewhere on how to get started with that 14:47:45 mordred: Can you shoot me some links? 14:47:56 yes 14:48:39 UI is what I'm the least concerned about. Changing templates is NOT difficult. 14:48:50 ttx, agreed 14:49:17 the main concern for me - correct and stable model / workflows 14:49:23 ++ 14:49:46 we can polish model on current poc except some auth/user related stuff 14:49:54 and maybe some django stuff 14:49:59 cody-somerville: so yes, agree on CI/CD as a primary target. ideally you would cut that into work items (can't use Storyboard for that yet) 14:50:41 Then second target is to get Storyboard itself to use it 14:51:32 Aye. 14:51:40 #topic Storyboard Sprint 14:51:47 looks like the #2 point will include some work on current code to improve it's usability for developing itself :) 14:52:14 I'd like to gauge interest in people attending an in-person storyboard sprint in the new year, hosted by HP. 14:53:01 If you're interested, please send me your name, e-mail address, location, and availability in the first three months of 2014 and I'll look into the possibility. 14:53:20 cody-somerville, which part of the globe? ;) 14:53:52 ruhe: Once I gauge interest and know where everyone is based, I'll determine a location with the lowest total cost for everyone. 14:54:02 cool 14:54:08 great 14:54:21 in which location are you hiring guys? 14:54:23 also if you happen to go to a given conference, include that as well, we may co-host 14:54:33 "location": syntax error 14:54:47 That's a great point re: conference. 14:55:06 cody-somerville: yeah, my schedule is filling so fast co-location might not be a stupid option 14:55:27 Is anyone else going to conferences early 2014? 14:55:33 it's all I do with myself 14:56:07 I go to FOSDEM/Brussels. Might have a Foundation sprint in UT mid-January (ski!) 14:56:46 cody-somerville: i'll send you the requested info 14:56:54 * SergeyLukjanov have no plans for the first three months of 2014 atm 14:56:58 Thanks. 14:57:06 My e-mail is cody.somerville@hp.com 14:57:17 We're now three minutes to the hour. 14:57:24 #topic Meeting Time 14:57:29 How does this meeting time work for everyone? 14:57:34 Should we change it or keep it the same? 14:57:37 perfect for me 14:57:41 ++ 14:57:52 ++ 14:57:54 only issue is that it can't have #openstack-meeting* because both channels are booked 14:57:56 +1 to keep 14:58:02 so we could consider moving to Fridays 14:58:11 but then that would be on Fridays. 14:58:12 It might be difficult for people on the west coast to attend at this time. 14:58:30 hrm. I'm tempted to say "life is hard" 14:58:43 and we make it hard for people in other timezones to attend openstack meetings all the time 14:58:44 cody-somerville: there will be no way to get California and deep Russia. 14:59:24 My new team is going to hate me. They're all on the west coast. 6am meeting every Thursday. :) 14:59:32 maybe we'll have alternating meetings if you get west coast people on board 14:59:49 are there any times which are late-night US west that are morning for russia? 14:59:51 I'm fine with one or two hours later 15:00:06 One or two hours later also works for me. 15:00:09 Let's defer. 15:00:12 SergeyLukjanov, NikitaKonovalov: later means late for you right ? 15:00:12 ++ 15:00:13 and keep current time. 15:00:25 ttx, it's ok for me 15:00:29 this is fine for me - new employees at hp will just learn to love it 15:00:34 ttx, project meeting is much later ;) 15:00:40 no kidding 15:00:50 #topic Quick Last Minute Things 15:00:52 forrks for me 15:00:55 one last question 15:00:59 cody-somerville: we can set it to the next hour. that way we'll have a meeting channel 15:01:00 what url should we use? 15:01:02 forrks - > works 15:01:14 bugs.o.o ? stories.o.o? issues.o.o? or? 15:01:26 mordred: or storyboard.o.o 15:01:35 (too long ?) 15:01:36 bugs.o.o for production instance 15:01:41 storyboard.o.o for our instance? 15:01:42 ttx, mordred, +1 for stroyboard.o.o or sb.o.o 15:01:51 well, we use review.o.o for gerrit, not gerrit.o.o 15:01:55 cody-somerville: or stories.o.o ? 15:02:03 so that we have it named after function, rather than software implementation choice 15:02:03 "bugs" sounds a bit... reductive 15:02:14 tasks.o.o ? 15:02:37 I like stories.o.o it's much less depressing than bugs 15:02:45 yeah. I thnk I like stories the best 15:02:46 i'd name this domain the same way this project is named - stroyboard.o.o 15:02:55 tasks sounds good, but stories is the better name 15:03:04 what if marketing wants stories.o.o for something? 15:03:15 cody-somerville: don't we control dns ? 15:03:46 heck, I have summit.o.o and then never coimplained. 15:04:21 Right. 15:04:34 * SergeyLukjanov likes short aliases like sb.o.o :) 15:04:51 cody-somerville: marketing can suck it 15:04:53 :) 15:05:11 openstack is a technical meritocracy, they work for us ... 15:05:28 I'd suggest we have two domains though - one for our cd/ci instance (which -infra and other beta testers can be Guinea pig on) and then another for when we actually deploy this for realz. 15:05:30 also, I bet they'd want openstack.org/stories in any case (the less antagonistic answer) 15:05:33 mordred, are you sure that they know it? :) 15:05:47 SergeyLukjanov: I'm sure that they don't :) 15:05:52 (as they should remain two separate instances) 15:05:56 cody-somerville: why? 15:06:07 cody-somerville: I expect our production instance to remain CD for its entire life 15:06:18 mordred, ++ 15:06:22 yeah, not convinced we need a separate domain for guinea pigs 15:06:33 mordred, so the first step is to configure backups :) 15:06:45 ruhe: luckily, this is something we have in infra already :) 15:06:48 but we can always move our CD 15:07:10 we do backups now ? awesome 15:07:22 ttx: yes! we also use trove-based mysql 15:07:29 it's like we dogfood this cloud stuff 15:07:31 now I'm scared 15:07:34 mordred: I suspect that for production we'll want it to be delayed a bit - little bit more conservative - not always running trunk. 15:07:38 hub_cap tells me it works 15:07:47 cody-somerville: I do not share that suspicion 15:07:48 heh, H/2 * * * * backup the world 15:08:00 cody-somerville: we run most of the rest of infra directly off of git master branches 15:08:14 zuul and nodepool both run that way 15:08:18 mordred: ie. around release time, storyboard dev shouldn't have to halt but we wouldn't want to risk disrupting openstack engineers. 15:08:49 cody-somerville: for the rest of infra we just soft freeze 15:09:03 hold on disruptive changes 15:09:04 yah. no dangerous changes - which means no patches written by monty 15:09:13 that's a good rule of thumb yes 15:09:17 cody-somerville, zuul/nodepool outage is the same risk 15:09:40 now - that said - we DO have the capability of spinning up a dev server and a feature branch 15:09:44 if we need to at that time 15:09:50 but I'd like to shoot for not needing that 15:09:57 because if we do need it, it means we've done something else wrong 15:10:26 the thing is, we're bound to do things wrong :) 15:10:29 #endmeeting