20:02:00 #startmeeting tc 20:02:01 Meeting started Tue Nov 10 20:02:00 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:05 The meeting name has been set to 'tc' 20:02:05 Hi everyone 20:02:15 Long agenda for today, a bit of backlog accumulated over the last weeks: 20:02:19 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:24 Let's start 20:02:29 #topic Add senlin project to big tent 20:02:34 #link https://review.openstack.org/235172 20:02:38 Do we have anyone from the project ? 20:03:07 We have enough approvals to approve this now, any questions ? 20:03:10 it seems like we have a glut of orchestration-related projects 20:03:11 i'm here as a rep for senlin. qiming should be here as well 20:03:12 * edleafe is tempted to drink it, but sees it's 2pm... 20:03:22 I'm not sure I totally understand what a "generic clustering service" does, wouldn't mind a quick explanation 20:03:23 edleafe : convert to UTC 20:03:34 edleafe: what dhellmann said 20:03:35 :D 20:03:37 o/ 20:03:40 dhellmann: :) 20:03:42 ttx: ++ 20:03:57 I went through the wiki a bit but a clear explaination wouldn't hurt 20:04:01 jruano: do you have an elevator pitch for what Senlin does ? 20:04:05 jruano : can you explain senlin without using the word "cluster"? 20:04:15 or generic, or service 20:04:17 orchestration to me seems quite a lot like installation, there are going to be different approaches, that's fine 20:04:31 sdague : yeah, that wasn't a complaint, just an observation 20:05:02 This is meant to be a layered service, correct? And not used by other OpenStack services directly? 20:05:12 one sec, qi ming is joining 20:05:21 it sounded a bit like heat, except it seems to drive heat 20:05:32 when we talk about "cluster" it is more so an aggregation, or grouping 20:05:49 i have a hard time wrapping my head around 9 +1s on the project, but the discussion here is "so what is this project again?" 20:06:07 russellb: I was thinking the same thing 20:06:17 sorry for being late, was trapped in another meeting 20:06:33 russellb : I don't see anything *wrong* I'm just observing that their language is vague enough that potential users might not understand what they are building 20:06:34 not necessarily calling for specific action ... just an observation, i guess. 20:06:35 basically, it was started as a autoscaling-service (ASS) :) 20:06:43 what dhellmann said 20:06:49 russellb: +1 20:06:56 but we soon found out that it is really about a clutering thing 20:07:06 russellb: agreed :) my +1 is lets go for it. If people want to hold for discussion, that is kind of what the -1 vote is for 20:07:14 create and manage groups of homogeneous objects (heat stacks, nova severs) etc. 20:07:49 Qiming : can you explain how that's different from murano or heat? is it the fact that it manages a group of things? 20:08:00 an 'array' data type for programing openstack cloud 20:08:07 heh, ok 20:08:11 ok, that makes sense :) 20:08:24 Alright, other questions ? 20:08:31 otherwise I'll approve now 20:08:39 wfm, let's go 20:09:07 Alright, you're in. 20:09:22 Qiming: I really liked your Tokyo meetup summary on the ML, btw 20:09:40 thanks guys, we are still open to any suggestions/comments 20:09:41 gave me confidence you had a good grip on scope and feature vs. maturity 20:09:41 sdague : on a procedural note, I hope it's not required to vote -1 to ask questions or have a discussion about something 20:09:56 moving on... 20:10:00 #topic Freezer application to join the Big Tent 20:10:04 #link https://review.openstack.org/239668 20:10:08 Anyone from Freezer ? 20:10:11 re: Freezer I'm here just in case any clarification is needed 20:10:26 here the jury still sounds out 20:10:36 OK, so my initial take on this one is that it's a bit young (especially in using only logged IRC discussions) 20:10:41 But I could easily be convinced otherwise, Fausto's answers have been satisfying 20:10:47 And they streamlined the licensing 20:10:49 my only quibble here is on the mission wording, so if we want to add the project and iterate on that it's fine with me 20:11:14 sure we can iterate on the mission wording if it's not 100% there 20:11:22 Does anyone have questions for daemontool ? 20:11:41 :) 20:11:47 I don't. daemontool has been diligent and he has addressed most of the concerns on the review 20:11:59 I think maturity from a community perspective will grow 20:12:02 yeh, it also seems like the mission might evolve as it matures, because it is kind of a new area and you discover some things as you go 20:12:12 daemontool : did my most recent comments on the mission statement make sense? 20:12:28 dhellmann, I think they make sense 20:12:33 so fixing mission either in pre / post merge is fine by me 20:12:39 if there's something that can be addressed during the meeting, it'd be cool 20:12:51 k, I'll +1 and we'll see where we stand on votes and I can work with daemontool on wording 20:12:56 I'm fine with +1'ing it now or after a new patchset 20:13:03 perfect :) 20:14:00 ok, still a couple votes short 20:14:26 +1 20:14:36 +1 20:14:59 ok, it has majority now 20:15:03 and no objection 20:15:11 Will approve now unless someone screams 20:16:32 ok approved 20:16:53 daemontool: please work with dhellmann on polishing the mission statement 20:17:11 #topic Added JavaScript to Common Testing Interface 20:17:13 brilliant, will do, thanks a lot :) 20:17:16 #link https://review.openstack.org/232756 20:17:23 krotscheck: o/ 20:17:27 Feels like the latest rev addresses all the concerns posted so far 20:17:27 ohai 20:17:37 and it's 9 votes 20:17:48 right, approving now unless there is something to discuss ? 20:18:19 "bower, gulp, grunt, *sigh*" Approved 20:18:29 #topic Introduce assert:supports-upgrade and assert:supports-rolling-upgrade tags 20:18:33 Woot! 20:18:35 #link https://review.openstack.org/239771 20:18:39 #link https://review.openstack.org/239778 20:18:45 I think these are great maturity assertions and can't wait to see them in 20:19:03 any last-minute comment ? 20:19:13 FWIW I plan to engage with project teams on the assert:* tags so that they are aware of them 20:19:24 ttx: ++ 20:19:26 Before those are published on the project navigator and become embarassing to projects that should have asserted them 20:19:26 i think they're a very nice addition. 20:19:36 yep, nice job dansmith 20:19:40 i have a feeling we might need a way to add some attributes 20:19:40 \o/ 20:19:47 but we can deal with it later 20:19:57 yeh, this seems like a very reasonable stake in the ground 20:19:58 and project docs might be enough 20:20:00 quick and smooth, approved 20:20:04 russellb : yeah, we used to have tag attributes 20:20:07 woohoo, thanks! 20:20:23 #topic Add Fuel to OpenStack Projects 20:20:28 dhellmann: could just be an attribute that says "see this page for project docs that go into detail about the upgrade procedure / caveats / limitations / whatever" 20:20:29 #link https://review.openstack.org/199232 20:20:33 moving on :) 20:20:39 dansmith: thanks for pushing that 20:20:43 russellb : exactly what I was thinking 20:20:49 anyone from Fuel around ? 20:20:52 I'm here 20:20:57 angdraug: o/ 20:21:11 looking at current state of votes 20:21:21 Looks like we still have two -2s 20:21:22 so I -1ed https://review.openstack.org/199232 just until the 7 tests get over, which seem like they are in progress. I'm +1 once those are in. 20:21:45 do we really need to hold until that's done? 20:22:06 I'm fine trusting them on delivering those (and if they don't remove them) 20:22:19 i think the multinode thing is unclear -- are you working with anyone from infra on that? 20:22:28 having gates is of tremendous value to our project, no reason to remove them 20:22:30 it sounds like everything we've asked for is in progress, right? 20:22:33 because we *can* run multinode tests, however, we can't run test on specialized hardware. 20:22:42 dhellmann: or done already, yes. 20:22:45 angdraug : I think ttx meant remove fuel from official status if the tests don't materialize 20:22:56 I don't think we need to hold them off on that, if there's work in progress and reviewable things up 20:22:57 jaypipes : k 20:22:57 I think multinode is out of scope 20:22:59 yes, what dhellmann says 20:23:05 sdague : agreed 20:23:06 sdague: why? 20:23:07 it needs a lot more generic work 20:23:16 we have multinode tests for nova and neutron 20:23:17 * flaper87 +1'd 20:23:24 jeblair: they aren't voting 20:23:26 dhellmann: ttx: got it, sounds fair to me :) 20:23:38 there are no currently binding multinode jobs 20:23:56 sdague: that's not because we lack the ability to run the jobs, it's because the jobs themselves aren't ready 20:23:58 ttx: I'm fine flipping to +1 under your condition 20:24:14 there's a lot of expectations about multi-node environments wired into fuel-qa 20:24:19 sdague: I think current +1's are under that condition 20:24:26 at least mine is for sure 20:24:28 what i'm concerned about is whether there is effert to work with and improve upstream testing 20:24:47 rather than "meet minimum requirements of PTI" 20:25:01 jeblair: I think the +1 from EmilienM is a good confirmation that we are willing to work with other projects 20:25:23 yeah, I think if they suddenly stop currently-started alignment efforts we should definitely revise our decision. 20:25:29 That's valid for every project out there 20:25:29 hi, sorry I've been afk - electrician here; and now power is being cut off :( 20:25:39 jeblair : what ttx said 20:25:47 lifeless: :( 20:25:51 angdraug: that's great, but where's the work on closing the gaps on the more complex tests? 20:26:11 flaper87: occupational risk of working from home :) Mostly a net win :) 20:26:33 jeblair: give us time, please 20:26:53 let us finish the conversion from Fuel CI to openstack gates first 20:27:09 jeblair: hypothetically, how much longer would it take for them to complete that work? 20:27:12 i'm happy to give you time. i'm being asked not to give you time. :) 20:27:27 jeblair: how so? 20:27:40 I think Fuel has been held of long enough and they've addressed most of our concerns. The missing ones are WIP, AFAICT 20:27:43 jaypipes: i'm being asked to approve inclusion now. i'm happy to delay inclusion. 20:27:48 off* 20:27:59 right now, fuel-qa uses fuel-devops to provision virtual nodes, which works directly on top of libvirt 20:28:04 jeblair: oh, sorry, misunderstood you :) 20:28:11 going from that to nodepool is a major rewrite of lots of bits 20:28:31 anyway, still a couple votes short 20:28:51 personally it feels odd to hold fuel to a bar higher than other projects about the multinode work in upstream. As someone that's done a good chunk of multinode upstream work, I don't think it's fair to hold up new teams behind having to integrate with that in current state. 20:28:52 anyone else besides jeblair with unaddressed concerns ? 20:29:08 sdague: there are still fuel projects running only noop jobs. 20:29:31 is this the 7 jobs? 20:29:36 yes 20:29:39 or is there something beyond that? 20:30:05 and 6 jobs for new repos we've created last week 20:30:17 which already have non-voting gate jobs 20:30:23 we just need to finish testing them and enable 20:30:46 that's it 20:31:01 angdraug: right, and you said a few weeks to complete that, right? 20:31:04 yes 20:31:11 russellb, mestery, annegentle, lifeless, mordred, dtroyer, markmcclain: any question left ? 20:31:15 sdague: and i'm not asking for complete work on the multinode thing, just the start of some interaction, because i think today, there's very little understanding across teams on this 20:31:22 end of year deadline gives us enough buffer time for unforeseen complications 20:31:48 it looks like this will have to wait another week as there are not enough votes 20:32:02 we should perhaps move on and continue the discussion on the review 20:32:13 right, i'll check the votes on this one at the end and see 20:32:18 ttx: honestly I'm on the fence and would personally like to see the inflight work completed 20:32:20 jeblair: I definitely agree there is very little understanding across teams, started chatting with clarkb about that today. But I think that is a broader thing, because I don't think we've made a reasonable discussion space for that as of yet 20:32:30 markmcclain: that is fair 20:32:41 it's been a lot of scatter shot, which we need to make better 20:32:45 ttx: otherwise I do think the projects fits within out mission 20:32:54 Alright, let's shelve this for a few minutes 20:33:03 #topic Other changes 20:33:09 * Limit type:service to user-facing services 20:33:13 #link https://review.openstack.org/242124 20:33:23 that one is ready, will approve now 20:33:25 what's up with monasca ? 20:33:31 next topic 20:33:34 kk 20:33:42 we should have time to cover it 20:33:48 * Provides links in the charter to the list of projects 20:33:52 #link https://review.openstack.org/241424 20:34:01 This one is technically a charter change, even if it's a minimal one... So we might want to have 2/3 approvers (9) 20:34:01 you did say "time permitting"... flaper87 stfu 20:34:16 and we have them now, approving 20:34:25 * Update deprecation policy for changes not in coordinated releases 20:34:29 #link https://review.openstack.org/242117 20:34:35 This change clarifies what the policy means for intermediary-released services like Ironic 20:34:45 Note that it doesn't affect projects which already asserted this, since those are all cycle-with-milestones currently 20:35:03 Looks like that one could use a few more iterations though 20:35:15 let's table it until next week 20:35:20 * Rename Ceilometer projects to Telemetry 20:35:25 #link https://review.openstack.org/240809 20:35:37 so, some times with things like https://review.openstack.org/242117 - it's helped with more words, and examples 20:35:53 because I feel that in the effort to condense those things, it gets more confusing 20:36:05 sdague: agreed 20:36:05 feels like deja vu back to the days of programs 20:36:13 (the ceilometer change that is) 20:36:41 russellb: yeah there is a bit of that 20:36:51 naming things is hard 20:36:54 indeed 20:37:13 I'm fine with the change though, even if it seems to assert ownership of a territory 20:37:14 grunt, gulp, bower *sigh* 20:37:22 as long as we all know that's not the case 20:37:27 seems fine ... most projects identify with their primary deliverable ... this one isn't as clear and deserves a different name 20:37:28 wfm 20:37:47 ok, approving, unless someone screams. We can always change it /again/ 20:37:55 ttx: lol 20:38:10 i think we've sailed past projects claiming territory for the most part, except maybe at the very bottom of the stack 20:38:17 Teleceilometry 20:38:27 I'll keep the last ("Rejecting other deferred project applications ?") for open discussion 20:38:34 #topic Adding Monasca to OpenStack 20:38:39 #link https://review.openstack.org/213183 20:38:44 Anyone from Monasca around ? 20:38:46 o/ 20:38:53 o/ 20:38:58 o/ 20:39:02 o/ 20:39:13 o/ 20:39:15 I saw sdague approved the test job 20:39:19 I'm good with that 20:39:35 it is experimental only, but it's a start 20:39:48 sdague: yup 20:39:57 Approving this on the same grounds I'm approving Fuel, going in the right direction 20:39:59 same thoughts as for the Fuel case 20:40:04 yeah, I'm happy with the progress since the last time I looked 20:40:08 ttx: indeed 20:40:09 flaper87: get out of my mind! 20:40:22 i'm also satisfied this is going in the right direction 20:40:50 Alright, questions? objections? 20:41:13 (8 yes, ready to approve) 20:42:07 alright, approved 20:42:13 rhochmuth: welcome :) 20:42:19 * jaypipes wonders why folks haven't voted on the Fuel proposal but did on the Monasca proposal... :( 20:42:26 rhochmuth: thank you :) 20:42:33 thanks everyone 20:42:51 #topic Open discussion 20:43:07 First, back on the Fuel review 20:43:37 still missing a couple votes. 20:43:40 statements like "this is not required by the pti" concern me. 20:43:41 As I mentioned on the tc m-l, I'll help with automating tags updates but don't expect me to do that by the end of this week 20:43:42 :D 20:43:55 * Rejecting deferred project applications 20:44:00 #link http://lists.openstack.org/pipermail/openstack-tc/2015-November/001055.html 20:44:11 jeblair: why? do you think we'll stop at exactly what PTI requires? 20:44:13 So my suggestion of assigning TC mentors to track deferred project applications was not very popular 20:44:31 i volunteered for one, but it's one i was interested in tracking regardless 20:44:35 angdraug: yes, that statement makes me worry about that. i hope not. 20:44:38 the reason I've made that statement is that I'm concerned about scope creep for acceptance requirements 20:44:50 FWIW, I liked it and I think it makes sense 20:44:51 That means the burden of "resubmitting when ready" should fall on the proposer, which I'm fine with 20:44:52 Some projects need it, others don't 20:45:03 But then we should just more clearly reject application changes, so that putting a change back up for review really means "we think we are ready now" 20:45:04 Monasca and Fuel did a great job dealing with the requirements 20:45:08 back in July, there were no objections to declaring multi-node testing a long-term goal 20:45:10 other projects need more guidance 20:45:15 So we should Rollcall-1 Compass, Kiloeyes, Kosmos and Juju applications 20:45:30 flaper87: sdague thinks it's not a great use of our time 20:45:46 angdraug: i agree, and i still won't block based on that. but i'd like to see effort and collaboration begin in that direction. 20:45:55 there were two very clear objections: PTI and collaboration with puppet-openstack 20:46:03 yeah, I'm more of a mentoring person, hence my tendency to vote for that kind of "programs" 20:46:13 not saying sdague isn't, btw. :D 20:46:19 ttx: well to be specific, I think there are a lot of priorities, and it seems odd to focus on not-yet-openstack instead of openstack projects 20:46:24 especially by policy 20:46:28 sdague: agreed. 20:46:32 individuals can do whatever they want 20:46:45 russellb helping on a not-yet-openstack project, is totally cool 20:46:58 but it shouldn't be expectation set for TC 20:47:02 jeblair: you will see that, but I'd rather not make that an additional requirement for the fuel proposal 20:47:03 seeems fair 20:47:05 angdraug: the thing i'd like to be clear is that the goal is that as much as possible is tested in the upstream project infrastructure because it is accessible to all developers and does not rely on a single company's resources. 20:47:06 I don't think we need this to be an expectation 20:47:09 sdague: sure but then how do you propose we signal when a project is ready to be reconsidered ? Should we reject the review until it's reproposed ? 20:47:18 maybe clearly outlining a way they can reach out for review of particular aspects? 20:47:20 I think this has to be a volunteering job and, it's fine to not have a mentor 20:47:22 jeblair +1000, that much is very clear 20:47:32 Fuel CI is also accessible to all developers (including its source code) 20:47:37 like "you had concerns about this piece, what do you think of our progress?" 20:47:42 i guess just the ML is fine for that kind of thing 20:47:49 I agree that migrating off Mirantis hosted infra is a worthy goal though 20:47:49 I mentioned on that thread that we need to have a better way for folks to reach out 20:47:56 or communicate that better 20:48:02 800-CALL-THE-TC 20:48:17 flaper87: +1 20:48:18 ttx: yes, that seems fine, the virtual abandoned reviews seem better to be actually abandoned. 20:48:32 Perhaps, inviting some of these projects to participate in the TC meeting whenever they need guidance 20:48:35 russellb: I'm mostly concerned with the mechanics of the submission and the experience for the submitter. Currently it sits in open reviews until something happens and it's put back on the meetin docket 20:48:41 (something unspecified) 20:48:49 yeah, good point 20:48:50 flaper87 : I'd rather do it offline, 1:1 20:49:02 abandon with a nice comment "this isn't no, never, it's just not yet" seems fine 20:49:11 ok so shoudl we abandon Compass, Kiloeyes, Kosmos and Juju applications now ? 20:49:14 dhellmann: perhaps, but that's some sort of ad-hoc mentoring, isn't it? 20:49:16 "please resubmit when you think it's time to re-evaluate progress on the concerns listed" 20:49:18 ttx, russellb : so let's abandon them with the instructions about next step 20:49:23 +1 20:49:23 I'm +1 on that 20:49:26 +1 20:49:33 +1 20:49:38 we *almost* did that with Monasca 20:49:40 +1 20:49:42 but without the abandon part 20:49:45 and we can even give a TC member the action of writing up that response when we discuss it in meeting and decide that's the response 20:49:52 flaper87 : yes, and I think that's ok. Projects that are serious about their applications will ask for help. All of the current proposers did. 20:49:53 I think it worked well for them 20:49:59 OK, I'll abandon them 20:50:09 dhellmann: yes, I was just pointing out that we've kinda adopted that already 20:50:13 russellb : yeah, though I think only ttx can actually abandon them 20:50:13 unless someone beats me to them 20:50:15 I agree it's fine 20:50:19 flaper87 : ok 20:50:32 dhellmann: ah ok 20:50:56 anyone can post a summary of what's expected of them though :) 20:51:01 how many proposals have we rejected that are missing things that are listed in the governance repo? 20:51:07 ttx: sure 20:51:17 Compass, Kiloeyes, Kosmos and Juju 20:51:21 flaper87: ^ 20:51:37 Does that mean we're not communicating the requirements properly? 20:51:46 I don't think the number is high 20:51:53 just an open question to evaluate our process 20:52:04 * flaper87 will put more thoughts on this 20:52:22 On the Fuel review, I think jeblair voiced his opinion and vote. I'm more interested in the members who haven't voted +1 or -1 yet 20:52:23 flaper87 : it was not clear early on that we wanted things to actually exist when the teams asked for official status, but I think we've fixed that 20:52:29 ttx: thanks 20:53:03 markmcclain said he was on the same line as jeblair (even if he didn't express it on the review) 20:53:04 ttx: that would be russellb dtroyer_zz markmcclain based on monasca votes 20:53:16 dhellmann: but that applies to just one of those projects, iirc. 20:53:24 and lifeless mordred 20:53:36 and annegentle 20:53:43 flaper87 : I think I saw a comment on the juju review suggesting they create their repos and start work, too. 20:53:43 mordred is in a weird TZ today, he was awake before me 20:53:46 mordred: doesn't seem to be around, lifeless mentioned power outage... 20:53:53 flaper87 : the other was kiloeyes, right? 20:53:57 dhellmann: yes 20:54:01 re Fuel, I'm just not convinced it fits OpenStack's mission… we generally have stayed away from being a distro 20:54:17 dtroyer_zz: Fuel is a deployment service, not a distro 20:54:32 kiloeyes is a monasca fork by an ibm team, and I agree with mordred's email, it's like 6 commits, it's not a thing 20:54:34 dhellmann: I'll put some thoughts on this and see if I can come up with something. It might be we're done enough but I never trust that kind of statements :D 20:55:03 flaper87 : ok. I think we have, but I agree it's worth another look. 20:55:14 dtroyer: I think we crossed that bridge a long time ago, with Puppet recipes or TripleO 20:55:17 i don't have any argument against fuel, but I don't like the idea of approving it when jeblair has reservations on infra stuff. i'd rather respect that 20:55:48 ttx: I see those a bit differently, puppet/chef/etc are more of a toolkit than an install/deploy interface 20:55:50 russellb: that is fair. Same as markmcclain 20:55:51 ttx: dtroyer_zz: ... or ansible or chef :) 20:55:51 ttx: certainly the tripleo case ... i see puppet or chef as a little different, as it's not a full deployment solution ... just some of the supporting bits IMO 20:56:01 dtroyer_zz / ttx: OSAD 20:56:12 jeblair : it's not clear to me whether your objection is "fuel has refused to do X" or "fuel has not yet done X" or "fuel seems to be indicating they may never do X" 20:56:33 angdraug: i suggested this in #openstack-infra but maybe you didn't see it -- can you start a ml thread or an infra meeting agenda item on what the delta is between what we are able to run upstream and what you need? 20:56:34 * flaper87 thinks is the second one 20:57:03 jeblair: yes, thread on ML sounds like a good start 20:57:13 bookwar: can you take that action? 20:57:30 yes, sure 20:58:02 Alright, sounds like it will be back next week 20:58:06 Anything else, anyone ? 20:58:08 angdraug bookwar let's do both ML and infra meeting 20:58:12 dhellmann: the second plus a little bit of wanting to see that there's effort into more than just the minimum. fuel chose to run their own ci for even things like pep8, so i'd like to see that they enthusastically value the public project infrastructure. :) 20:58:36 jeblair : ack, thanks for clarifying. that's a completely reasonable position 20:58:54 can you sum up the expectations for Fuel for the next round? 20:59:36 angdraug: for me, finish the migration of the low hanging fruit and start a dialog on the more complex jobs. 21:00:08 It's just harder for an established project to join than for a brand-new one 21:00:09 angdraug: i do not believe that is a significant expansion from the earlier request. 21:00:16 as I mentioned, I see the latter as a new requirement :( 21:00:18 it's weird but it's the case 21:00:49 ttx: kinda makes sense too 21:00:59 They have to go out of their way to prove they will follow community, while a new project is more easily given the benefit of doubt. 21:01:13 ttx well said 21:01:15 russellb: yes, and I expect other projects might be bitten by that in the future 21:01:25 easier to adapt to openstack processes and tools when you have no existing baggage to shuffle 21:01:26 It's a consequence of the "are you one of us" approach 21:01:41 when you come from a different group, you have to prove more 21:01:43 I think we're out of time 21:01:45 yes 21:01:49 Thanks everyone 21:01:50 dtroyer_zz: what is the difference between devstack and Fuel in your mind with regards to "supporting the OpenStack mission"? 21:01:50 that said, I agree with ttx 21:01:59 #endmeeting