16:00:44 #startmeeting Solum Team Meeting 16:00:45 kgriffs: make sure to read the logs 16:00:45 Meeting started Tue Apr 8 16:00:44 2014 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:48 The meeting name has been set to 'solum_team_meeting' 16:00:50 #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-04-08_1600_UTC Our Agenda 16:00:57 #topic Roll Call 16:01:03 Chris Alfonso 16:01:03 Adrian Otto 16:01:06 Ed Cranford on lead guitar 16:01:08 Roshan Agrawal 16:01:14 Paul Montgomery 16:01:17 tom blankenship 16:01:24 Julien Vey 16:01:25 * mspreitz is lurking 16:01:27 paulmo: Feeling any better today? 16:01:29 Pierre Padrixe 16:01:31 no 16:01:45 paulmo: sorry, I hope you are better soon 16:01:54 Georgy Okrokvertskhov 16:02:50 datsun180b: lead guitar. Ambitious. Nice. 16:03:13 welcome everyone 16:03:34 #topic Announcements 16:04:07 After our BP updates today, I think we can claim official clearance of our M1 milestone 16:04:38 we are working on some screencast and announcements to share with our wider community by ML, and on solum.io 16:04:49 so next week, I should have an official such annoucement 16:04:53 This is an important milestone for Solum ! 16:05:20 We integrated Docker this past week, so our Heat templates can spin up containers super fast. 16:05:30 roshanagr: indeed! 16:05:57 o/ 16:06:08 I'd like to focus our efforts between now and Atlanta on drawing down our bug list 16:06:13 welcome paulczar 16:06:31 I was just extending thanks for some of the work you have been wrapping up 16:06:55 adrian_otto: ditto +1 paulczar.... 16:06:58 our goal should be to shake out all our quirks and pay down tech debt. 16:07:18 so that we have a really solid release for people to play with 16:07:29 agreed! 16:07:47 in open discussion later in today's meeting I will ask about your thoughts on cutting a release 16:08:07 Do we have all bugs triaged and assigned to M1 milestone? 16:08:08 will this be part of devstack as well 16:08:38 rajdeep: good question. We will have a plugin for Devstack. 16:08:54 we also have a vagrant box with the full setup on it 16:08:55 great 16:09:09 this will be very useful for developers to try out 16:09:14 but it does not need to be part of Devstack code to be tightly integrated there 16:09:25 the contrib/devstack provides the hooks to plugin and work with devstack 16:09:28 what is the status of the reviews about getting docker driver in devstack ? 16:09:55 does it work with the master branch ? 16:10:10 julienvey: good question 16:10:12 julienvey: https://review.openstack.org/#/c/84839/ 16:10:24 let's park that one for general discussion and come back to that 16:10:24 it's got a -1 which I've responded to … but no further action 16:10:50 #topic Review Action Items 16:10:57 • adrian_otto to open a bug for https://review.openstack.org/84116 (completed by stannie) 16:11:10 stannie, do you have a link to that one handy? 16:11:15 yes: https://bugs.launchpad.net/solum/+bug/1304479 16:11:20 awesome, thanks 16:11:26 that was the only AI 16:11:36 #topic Mission Statement Review 16:11:48 #link https://etherpad.openstack.org/p/solum-mission Mission Drafts 16:12:06 I'd like to allocate about 15 minutes for us to pour in our creativity here 16:13:09 One thing that I'd like to convey in the proposed Program mission is the desire to empower cloud operators with the tools to give great hosted services to their Application Developer customers. 16:13:47 so I will jump into the etherpad now and try getting that in. 16:13:53 I wonder about this one: enable a Netflix-like ecosystem of microservices 16:15:33 mspreitz: interesting. That indicates a bit of how, and a little less of what/why 16:16:07 adrian_otto: what about "...a toolset and services..." from gokrokve's proposal 16:16:14 shouldn't enterprises and private clouds also be considered 16:16:15 an ideal program mission would answer the What question, and allow you to quickly deduce Why 16:16:36 rajdeep: good idea. I will expand #2 accordingly 16:17:36 better now? 16:17:42 ^ rajdeep 16:18:43 yes 16:18:51 The combination of 1 and 2 communicates the essence really well 16:19:00 I suppose we coudl combine them 16:19:09 can we expand on 'easy to use'? 16:19:13 I myself always have a problem with the word "Application" when it is used without any clarifying words 16:19:15 solum 16:19:19 How about we reconsider use of "compelling" 16:19:24 "application" means so many different things 16:19:31 is a unique combo or paas + devops 16:20:00 roshanagr: try substituting a few other words in there to see if alternates hit closer 16:20:47 mspreitz: indeed. I share that same concern. It's an overloaded term. Any ideas for another way to express that? 16:21:08 is one of the goals 'making application developers more productive'? if so, should that be in #1 possibly instead of 'easy to use'? 16:21:20 rajdeep: if I see the word devops in our mission statement my head will explode :P 16:21:34 tomblank: yes 16:22:06 adrian_otto:I think we mean here a pretty broad notion of application, and I know of no short way to clarify. At this point my suggestion is an additional sentence or two. 16:22:18 would more efficient be better wording than more productive ? 16:22:32 E.g., if you take Cloud Foundry today, it's notion of app is too heavy weight to make CF good for a bunch of microservices 16:22:54 mspreitz: good point 16:23:54 paulczar: sure, more efficient works for me... 16:25:32 mspreitz : how do we define micro services? 16:25:36 mspreitz: talking to microservices could imply exclusion of people who build monoliths 16:25:58 I do not think Solum should be exclusively for microservices. 16:26:09 Here is a piece on the word "application": http://martinfowler.com/bliki/ApplicationBoundary.html 16:26:25 I do not think we need one precise definition in mission statement 16:26:30 the mission is broad, right? 16:27:34 yes, the mission is broad 16:27:46 we are approaching the timebox I set for this discussion item. 16:27:59 I really like the progress we make in these focused efforts 16:28:13 should we continue, or revisit this later? 16:28:19 I like 'Developers' mentioned first 16:28:27 I'll just say this: if microservices is "how" not 'what' then the 'what' words should not lead into the too-narrow box that Cloud Foundry occupies 16:28:43 Help developers efficiently consume openstack cloud services by empowering... 16:28:52 s/services/resources/ 16:29:19 paulczar: copying that up to the etherpad 16:29:30 adrian_otto: Maybe you can set up a vote with a link with some propositions, and share the results next week ? 16:30:31 julienvey: we can. 16:30:42 Does everyone feel close? 16:31:58 think that's as much as i can add 16:32:21 Not seeing any words clarifying "application" ... but if we're out of time for now, then we are 16:32:39 I added this:  Improve the ease of use experience and productivity for Application Developers on OpenStack clouds. Empower public and private cloud operators with tools and features needed to offer hosted services for running and managing cloud applications on OpenStack. 16:32:47 let's come back to this again in open discussion 16:33:10 how does solum provide tools to cloud operators? 16:33:11 how long has it been branded Open>S datsun180b: since 2010 16:33:39 e.g cloud foundry has bosh for managing the paas deployment 16:33:42 well geez 16:34:19 rajdeep: Solum could use Heat to provide the BOSH experience 16:34:21 rajdeep: solum is an example of a tool we provide operators 16:34:26 oh i'm just used to seeing the all-lowercase logo 16:34:34 Feel free to continue work in the etherpad for the mission 16:34:37 BOSH installs cloud foundry 16:34:49 if you settle on a favorite, let me know about it here in IRC 16:35:10 and I will use that input to select a few choices for a focusing vote 16:35:17 #topic New Alternating Meeting Time 16:35:28 i guess it helps in expanding list of nodes / also upgrade the version of cloud foundry 16:35:44 on a live environment which heat might not be able to do 16:35:46 I wold like to adjust our team meeting schedule so that on alternating weeks, the meeting time is later in the day. 16:36:22 we have contributors and core reviewers in practically every timezone range 16:36:22 rajdeep: exactly … i think OOO, chef-openstack, puppet-opentack would be openstack equiv of BOSH 16:36:42 so no matter what meeting time we select, someone will be needing to be asleep, or away from work 16:37:23 to maximize our inclusion of those on the opposite side of the Earth, we could use the alternating time approach 16:37:33 so at least those impacted could attend on alternate weeks 16:38:24 a 7:00 PM US/Pacific (9:00 PM US.Central) time was our favorite the last time we considered this. 16:40:24 something like this: http://www.worldtimebuddy.com/?qm=1&lid=5386785,6,2988507,1277333&h=5386785&date=2014-4-8&sln=19-20 16:40:43 it would be the least convenient for our French contributors 16:40:51 on the alternating weeks 16:42:01 another option might be: 16:42:02 http://www.worldtimebuddy.com/?qm=1&lid=5386785,6,2988507,2174003&h=5386785&date=2014-4-8&sln=13-14 16:42:19 adrian_otto: can you add brisbane ( +10 ) to that ? 16:42:27 oh the new one does 16:42:30 it's on the link above 16:42:38 it only holds 4 16:43:12 that would be 1:30 am in India 16:44:24 so, assuming we vote on the alternate time... 16:44:45 and that we have some sensible way to weight the voting results so it's fair for those who attend regularly 16:45:15 does anyone have an objection to having a */2 week meeting that's potentially less convenient than now? 16:45:28 and keeping this timeslot? 16:45:49 (for the other */2 weeks) 16:45:56 ok for us 16:45:57 ok adrian_otto 16:46:19 ok, I am going to take an action to set up a vote on that 16:46:33 and maybe we can count core reviewers with 2 votes? 16:47:19 #action adrian_otto to propose a vote for a new meeting time for our ever-other-meeting schedule. 16:47:21 adrian_otto: +1 16:47:42 and if it turns out to be too burdensome, then we can revisit it again 16:48:37 #topic Review Blueprints: https://launchpad.net/solum/+milestone/milestone-1 16:48:48 we have three, so this should be quick 16:48:54 #link https://blueprints.launchpad.net/solum/+spec/deploy-workflow Workflow outlining deployment of a DU (asalkeld/devdatta-kulkarni) 16:49:24 tomblank 16:49:36 devdatta is out. 16:49:52 sorry - devdatta is on holiday. i'll get an update and send it out. 16:49:53 who should update us on this? 16:50:01 ok, next one... 16:50:06 #link https://blueprints.launchpad.net/solum/+spec/solum-git-pull Pull integration of Solum from an external Git repo (kraman) 16:50:12 I think we can mark this as implemented 16:50:16 (the previous one) 16:50:19 agreed 16:50:27 julienvey: the deploy-workflow? 16:50:28 yes this is complete 16:50:32 adrian_otto: yes 16:50:40 ok, I will mark it as implemented right now. 16:51:02 about git pull, it is also implemented 16:51:04 ok, I will drip that from next agenda 16:51:12 last review from aratim was merged this week 16:51:13 what about solum-git-pull 16:51:26 any remaining work on that one? 16:51:35 triggers aren't part of that bp 16:51:52 the trigger workflow is complete 16:52:03 so as far as i can tell this one's implemented too 16:52:16 that's what I thought 16:53:01 ok, next... 16:53:03 #link https://blueprints.launchpad.net/solum/+spec/logging Logging Architecture (paulmo) 16:53:24 I put this one back in because I wanted paulmo to have a chance to comment on it. 16:53:43 we indicated last week that it should be considered done/done 16:53:56 paulmo: do you agree? 16:54:30 uh, I'd probably need to look at code and such 16:54:44 (and it depends on scope) 16:54:51 We certainly aren't done with "logging" 16:54:53 #action adrian_otto to follow up with paulmo to determine if https://blueprints.launchpad.net/solum/+spec/logging should be marked as Implemented 16:55:06 paulmo: thanks. 16:55:16 #topic Open Discussion 16:55:59 for next meetings, I think we should add new items to the blueprint reviews 16:56:03 I see 3 now 16:56:06 julienvey: youa sked about https://review.openstack.org/#/c/84839/ 16:56:30 language pack in glance, plan in swift, and new version of the API (angus work) 16:56:47 adrian_otto: yes, thanks 16:57:09 julienvey: on the subject of 84839, are you satisfied, or is there more to cover here? 16:57:27 do we all use the new workflow with bugs/tag for new features ? 16:57:34 adrian_otto: it's fine. Let's hope we can get this merged 16:57:52 paulczar: how complicated is it to implement what sean propose ? 16:58:01 stannie: I am planning to use BP's but only for top level (epic) stories 16:58:06 all tasks will be bugs 16:58:08 ok 16:58:10 so we have a single task backlog 16:58:12 great 16:58:32 and we will continue to use Wiki pages as a place for supplemental detail 16:58:40 julienvey: doable … but a bit painful 16:58:49 we will try a few approaches with tagging to see what we like best. 16:59:15 do we have a list of "external bp" that we should track ? 16:59:23 e.g bp in glance for metadata 16:59:32 if I don't see any traction in the next few days I'll rewrite it as contrib/devstack in the solum repo and then we can control it ourselves until it goes somewhere 16:59:45 stannie: with might use a Wiki page for that 16:59:55 might be a convenient place to gather that stuff 17:00:08 ok 17:00:19 thakns everyone 17:00:19 stannie: great suggestion. +1 17:00:23 #endmeeting