16:01:00 #startmeeting Solum Team Meeting 16:01:02 Meeting started Tue Nov 26 16:01:00 2013 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:05 The meeting name has been set to 'solum_team_meeting' 16:02:12 * samkottler waves 16:02:50 #topic Roll Call 16:02:54 o/ 16:02:55 here 16:02:55 o/ 16:02:57 Tom Blankenship, Rackspace 16:02:57 o/ 16:02:57 hello everyone 16:03:01 Roshan Agrawal, Rackspace 16:03:03 * samkottler is here 16:03:07 * funzo is here 16:03:16 Tom Deckers, Cisco... new guy 16:03:16 Swapnil Kulkarni 16:03:28 Murali Allada, Rackspace 16:03:29 hey tdeckers, welcome 16:03:32 * russellb doesn't think corporate affiliations are important in this context, fwiw 16:03:33 welcome Tom 16:03:36 Jessica here 16:03:47 Paul Montgomery, Rackspace 16:03:59 * briancline also a new guy, at least for this project 16:04:06 Brent Smithurst, ActiveState 16:04:07 Devdatta Kulkarni, Rackspace 16:04:15 welcome newcomers! 16:04:53 Paul Czarkowski, Rackspace 16:04:56 hi 16:05:07 Arati Mahimane, Rackspace 16:05:11 sigh 16:05:18 Rajdeep Dua, VMware 16:05:44 #link https://wiki.openstack.org/wiki/Meetings/Solum our agenda for today 16:06:07 whoa.. lots of items 16:06:10 #Topic Announcements 16:06:23 need to move quickly to get through this monster agenda 16:06:28 1) Working Groups 16:06:34 We have arranged two working groups: 16:06:41 A) Language Pack Working Group 16:06:46 Subscribe to https://blueprints.launchpad.net/solum/+spec/lang-pack to join it. 16:06:55 (we can make a LP team for this as needed) 16:07:03 Participate in the Doodle poll to schedule the meeting series: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Language_Pack_Working_Group_Series 16:07:03 i'm a little concerned about the sizes of these groups and the impact it may make on getting something done ASAP 16:07:24 i'd almost rather just one person go off and make a strawman proposal 16:07:28 and we beat it up on the mailing list 16:07:38 russellb: we should do that too 16:07:43 instead of limiting progress to a meeting once a week 16:07:44 russellb: +1 16:08:03 I think it's importatnt to source input from the full group, but not all of us are expected to generate code 16:08:14 B) Git Integration Working Group 16:08:21 Subscribe to https://blueprints.launchpad.net/solum/+spec/git-integration to join it. 16:08:21 design by committee :) 16:08:21 Participate in the Doodle poll to schedule the meeting series: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Git_Integration_Working_Group_Series 16:08:29 for the language-pack working group i have not seen feedback via the ML, I would expect people who are interested to be responding already 16:08:36 let's try a few things and see what works best 16:08:49 #topic Review action items from prior meeting 16:08:57 aotto: Schedule breakout meetings for new working groups 16:08:57 (in progress, Doodle polls mentioned above) 16:09:07 #topic Review of Solum SFO Community Workshop 16:09:15 https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop 16:09:21 Roshan Agrawal: Report number of attendees, companies represented, format, lessons learned, and next steps. 16:09:21 For remote participants: Are there improvements we could make for next time? 16:09:34 let's wait for Roshan first 16:09:35 We had 35 attendees in person 16:09:48 and another 25 joined remotely 16:09:55 All in all, heavy participation 16:10:03 now we need code from all these people :) 16:10:20 russellb: yes sure :-) 16:10:32 for those who have not been watching the Gerrit system, we have good velocity in terms of patches 16:10:47 keep up the great participation in terms of code reviews 16:10:58 Any feedback from participants on the structure of the workshop? 16:11:10 My sense is that it went really well 16:11:22 adrian_otto, RoshanAgr : The arrangement was very nice, hangout helped a lot to be involved, the timing could be a concern for some :) but i guess it can be followed for future workshops 16:11:23 We worked thorugh several design topics 16:11:39 we got positive remarks from a bunch of you, but are really seeking ways to improve for next time, so if you have criticism, and don't want to voice it here, please catch me or Roshan on PM 16:12:24 We have etherpad notes from the workshop - we should file them/reference them for further discussions on the topics discussed 16:12:29 did the Remote attendees all feel like they were able to follow? 16:12:49 agreed on what coolsvap mentioned regarding timing 16:13:25 hangout worked well, i just had a lot of conflicts 16:13:25 by any chance was it able to be recorded? 16:13:44 briancline: probably a better use of time to just review the notes 16:13:45 We have notes: https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes 16:13:55 briancline: good suggestion, we will see about doing that next time 16:14:00 and start ML threads on anything that needs more discussion 16:14:09 In terms of pure productive output it likely was extremely valuable for driving consensus on a few core topics 16:14:11 russellb: yes 16:14:21 forcing people to yay/nay items 16:14:22 RoshanAgr: thanks 16:14:26 How frequently should we schedule these events? In-Person? Virtual? 16:14:44 briancline: welcome 16:14:48 virtual is much easier on budgets 16:14:49 no more than every 4 months 16:14:52 most of us are attending ODS on 6 month intervals 16:15:06 post ODS is potentially a good option 16:15:10 how about every 3 months 16:15:16 right in the middle of two ODS 16:15:18 every 3 is pretty aggressive 16:15:19 it lets us absorb other teams stuff and then bring it back to a targetted discussion 16:15:24 what about a combination of both, except a traveling circus? for instance an Austin office for a subsequent venue 16:15:27 i believe other teams are suggesting that 16:15:40 that is, unless most participants are in the bay area 16:15:56 I am suggesting twice a year. 16:16:08 twice/year like design summits makes sense 16:16:11 ODS + workshop + ODS + workshop 16:16:12 we should do some homework to plot the location of participants. We do know we are pretty spread out, mostly from the US 16:16:53 but should always treat the mailing list as the first class citizen, and where decisions should ultimately be made whenever possible :) 16:16:54 ok, so please think on this topic and we will follow up on ML 16:17:08 russellb: agreed 16:17:16 #topic Discuss alignment with Icehouse Release Schedule 16:17:25 Do we want to align with the icehouse milestone schedule: https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 16:17:44 adrian_otto: what does alignment mean 16:17:49 we have 4 milestones in LP, but I have not targeted them to dates 16:18:10 alignment would mean milestone 1 = i2, etc 16:18:23 so we would do a time based release schedule rather than feature based 16:18:31 in general, working along the openstack schedule makes sense, but i don't know if the existing milestones are scoped to match the schedule right now, are they? 16:18:41 this might not make sense until we have a base set of functionality first 16:18:58 adrian_otto: while starting this project might make more sense to do feature basd release for the first few releases 16:19:08 my opinion is that we should start alignment as soon as we have one working use case 16:19:19 the combination of those two statements makes sense to me 16:19:26 I would think so, to avoid another swift-like situation (it may have served well in the past but for a new project it seems anomalous) 16:19:31 adrian_otto: it may be too soon for us to go to date based schedule but as soon as we have base functionality i think that would be good. 16:19:34 as long as each iteration is aggressive, feature based seems OK for now 16:20:04 ok, anyone feel strongly that we should switch to dates before we have some basic features done? 16:20:11 RoshanAgr was the use case described on white board with 7-8 steps captured some place? 16:20:45 it is on my phone, and Krisha also has it. I or Krisha will publish it 16:20:46 I sort of do, though it seems a valid point that i1 is going to be a miss in that case 16:20:50 i dunno ... time based is tempting, makes life easier with it aligned with everything else 16:20:58 i1 does have some notable stuff 16:20:59 sallamaraju: RoshanAgr i owe a todo from ML to add more scenarios like that as well 16:21:16 RoshanAgr: I have the picture as well and can publish it 16:21:18 there's an API binary, the service is integrated with devstack, some initial API implementation is there 16:21:19 claytonc: perfect 16:21:32 * briancline intrigued 16:21:44 didn't realize it was that far along (mostly re: devstack) 16:21:49 the more i think of it, the more i like just using the main openstack schedule 16:21:54 yeah we need more people writing/reading the code 16:21:56 in that case, I actually feel more strongly now about icehouse alignment 16:22:03 ok, so I think I see consensus here that we should stay on the feature milestone system for now 16:22:08 decent velocity, but not that many people compared to how many say they are interested in this project 16:22:16 and revisit alignment with the date based system 16:22:30 i'm actually arguing the opposite 16:22:40 ok 16:22:49 don't have to do the feature freeze part 16:23:16 but alignment is good 16:23:20 wrt the aforementioned writing/reading code part, I'm glad to help, as the holidays are going to be slooowww for me this year, it seems 16:23:36 and as each openstack milestone hits, a solum milestone update email can go out talking about project status and what we accomplished 16:23:46 russellb: I see the key reason that the number of developers submitting patches is small is because there are many developers who are getting used to the way this project works. 16:23:54 * russellb nods 16:23:55 we have a lot of open design items 16:24:09 yes, that's the sole reason I haven't tangibly jumped in by now 16:24:21 and as we converge on some ideas, and devs get familiar with the way things work, whic will ramp up naturally 16:24:25 yep, need to burn through those, and hopefully identify the smallest reasonable iteration to start with 16:24:49 +1 on open design items 16:25:03 so, let's table this discussionfor now 16:25:17 ok... 16:25:22 and let's revisit it on ML to make the consensus very clear 16:25:38 and let's look at some blueprints to help advance our design situation 16:25:43 #topic Review Blueprints 16:25:58 First Milestone: https://launchpad.net/solum/+milestone/0.1 16:26:07 link doesn't work 16:26:08 this is a view of all blueprints for the first milestone 16:26:16 oh, no 16:26:22 https://launchpad.net/solum/+milestone/milestone-1 16:26:27 That is the right link 16:26:27 permission error 16:26:48 https://launchpad.net/solum 16:27:02 look at the section "Series and milestones" 16:27:18 then click on milestone-1 on that little line/dot chart 16:27:28 that should show you the blueprints in this milestone 16:27:48 does that work? 16:27:58 the link RoshanAgr posted works 16:28:12 ok, sorry for the mixup 16:28:20 Subscribe to each blueprint if you want email updates on them. 16:28:29 Ask for Assignee status if you can keep track of development on the feature and report on it weekly at our IRC meetings. You do not have to write the code yourself if you are the Assignee, only champion it. 16:28:32 adrian_otto: the blueprint for git is not specifically the one for git pull workflow. is that intentional? 16:28:43 Ability to push code to the platform via Git: I would request Assignee status for that blueprint 16:28:48 fwiw, assignee in other projects == implementor 16:28:58 kraman2: Roshan will address 16:29:12 RoshanAgr: will ping you offline 16:29:18 hold on before we jump in on those 16:29:20 kraman2: sure 16:29:24 let's start simple 16:29:41 #link https://blueprints.launchpad.net/solum/+spec/definitions Definitions and terminology used in Project Solum 16:29:52 Seek Definition Approval. Are we ready to proceed, or is more discussion needed? 16:30:16 just catching up... Application seems ambiguous. Has Application package been considered? 16:30:41 tdeckers: we can revisit that one 16:31:02 I'll just take noted for subjects to discuss on this BP if we are not ready to approve it 16:31:09 since we have a long list to look at today 16:31:14 np 16:31:14 tdeckers: let's go to the ML on that one 16:31:20 haven't had a good discussion 16:31:30 ok, will do, let's advance to the next if there are no further remarks 16:31:53 I would say strike "OS Container" and keep it generic as "Deployment Unit" 16:32:06 briancline: +1 16:32:17 +1 16:32:27 +1 16:32:41 +1 16:32:46 +1 16:32:50 +1 16:32:56 Ok, thanks. We will not seek approval, because we have more changes on this 16:32:59 I would like to see some concept of 1-1 vs 1-many on the relationships in that diagram if possible 16:33:07 will revisit later. 16:33:16 #link https://blueprints.launchpad.net/solum/+spec/app-deploy-manage (roshanagr) Solum-R1 Stories: Application Deployment/management 16:33:29 Note, this has several child blueprints, each will be individually discussed/approved. 16:33:31 R1 == milestone 1? or? 16:33:48 yes R1=milestone1 16:33:50 Seek Definition Approval. Are we ready to proceed, or is more discussion needed? 16:33:51 russellb: R1 != milestone 1 16:33:55 heh 16:33:58 what? 16:34:10 oh, because some were marked as out of scope? 16:34:21 R1 = requirement #1 16:34:26 yes 16:34:40 also , what gokrokve said 16:34:40 aha, I see 16:34:59 i think it's useful to capture requirements around the milestone 16:35:14 so if some of this is in and some out, maybe it makes sense to clarify that somehow? 16:35:30 so do we need further iteration on this as proposed, or should we approve this, and focus on the child BP's next? 16:35:35 russellb: yes agreed. We still need some requiment identifier 16:35:53 I think it should be updated to clearly identify what is in scope for the milestone 16:35:54 R1, R2 is an attempt, but I can see how that can be confusing 16:35:57 and the rest pushed off to something else 16:36:17 russellb: +1 16:36:25 this is a high level blueprint which is broken down into smaller ones. perhaps we should keep only the implementation BPs as part of the milestone. 16:36:39 perhaps. 16:36:51 Yes. We had a list of requirements to be implemented in M1. 16:36:53 the list of blueprints targeted at the milestone sort of define the milestone on their own 16:37:01 This list was captured in etherpad. 16:37:01 one question on deployment 16:37:13 kraman2: that's somethign I did discuss with Rohan, and I support that approach 16:37:22 *Roshan 16:37:30 kraman2: agreed. 16:37:32 some of this is user story stuff, and some of it identifies some design details (the CLI stuff) 16:37:34 rajdeep: ? 16:37:36 how does the persistent store get rewired from local settings to remote setting 16:37:43 on deployment 16:37:48 the story would be less detailed and just that ... I can create a thing via the CLI 16:37:53 russellb: ys, but we can move that into the CLI BP itself 16:37:54 or see the deatils of the thing 16:37:58 sure 16:38:30 rajdeep: can you expand on that question with some additional detail about your concern? 16:38:49 e.g jdbc url would change to the private ip of the container where service is running 16:39:24 developer first builds the app locally 16:39:34 and then does deployment to solum 16:39:48 solum should auto rewire to the remote persistent store 16:40:36 in that case you would need to make the configuration option flexible. One way to do that is to use a service registry. Another way might be to abstract data services behind Heat resources that are defined by Providers, and you look up the address of it at runtime. 16:40:51 Solum will support runtime variables and environment but it is up to developer to map these variables to some specific services' parameters. 16:41:24 gokrokve: yes, and environment variables is another way to handle it, which is a bit less flexible, but a common technique 16:41:30 yes we should do both auto and manual rewiring 16:41:32 giving option to the developer 16:41:48 persistance service lookup seems the way to go. Would be interesting to see how migrations of the persistence service itself would be handled though 16:42:04 ok, so not to get too far in the weeds on this right now 16:42:04 e.g. schema migrations is apps require it, etc.. 16:42:14 ok 16:42:24 It might be a requirement for "badger" or "language pack" to support auto rewiring for common services. 16:42:29 we have a few important blueprints that I'd like to get assigned today 16:42:47 I can take User authentication for incoming requests. 16:43:06 gokrokve: is that just using keystone auth token middleware? 16:43:12 ok, we will get there in a couple minutes gokrokve 16:43:12 I volunteer for: Ability to push code to the platform via Git 16:43:14 should be pretty quick/easy :) 16:43:24 our next one is: 16:43:25 #link https://blueprints.launchpad.net/solum/+spec/git-integration (assignee-needed) Ability to push code to the platform via Git 16:43:44 remember that being assigned means that you will be polled at these weekly meetings for status 16:43:47 russellb: Not really. It is an integration with keystone but we need to figure out an access model for solum resources. 16:43:55 that we expect you to keep informed about the status of allr elated dev work 16:44:15 Yes. I will update you on the status for this BP each meeting. 16:44:15 but it does not meant that you will individually write all the code 16:44:20 does the blueprint capture the first iteration of git integration? 16:44:32 * russellb thinks the primary author of the code should be the assignee :) 16:44:32 russellb: there is a git-pull BP for that 16:44:33 russellb: BP has two parts 16:44:39 i can take that one 16:44:44 kraman2: cool 16:44:47 one is git-pull, another bp is git-push 16:44:47 I'd like to jump on solum-git-pull as well 16:45:07 adrian_otto: is the expectation for an assignee writes some code 16:45:08 so this has both pull and push under it, both are part of first iteration? 16:45:13 so if you want to work on one of these (contribute code/design) just subscribe to the BP 16:45:15 RoshanAgr: i hope so 16:45:23 no, only pull is part of first itr 16:45:30 and let one of you own it who is a subject matter expert 16:45:39 ok, if just pull, looks like some dependency juggling needs to be done 16:45:40 atleast thats what we discussed suring F2F 16:46:01 or just remove the push from the dep tree 16:46:19 russellb: push is needed as well 16:46:30 there pull and push are seperate 16:46:39 right, but the way the blueprints are set up right now, it's saying both are in the first milestone 16:46:40 if we keep just pull BP on milestone 1, we should be fine 16:46:57 ok, so then git-integration wouldn't be on milestone-1 16:47:05 adrian_otto: RoshanAgr: can we make that change? 16:47:06 and just solum-git-pull 16:47:18 russellb: that is correct 16:47:22 for first itr could be as basic as a url to a tarball ( github generates these automagically ) … that would reduce the deps even further 16:47:22 russellb: a subset of that will be (it still needs to broken into child blueprints 16:47:39 ok, so do I have a volunteer to own the parent blueprint git-integration (Roshan, do you want it, or is there a better Stacker for that?) 16:47:51 adrian_otto: I can own the git flow 16:48:02 if RoshanAgr doesnt mind :) 16:48:11 ok, set yourself as assignee, or if it does not allow you I can do it for you 16:48:13 RoshanAgr asked about code expectation, i don't think that was answered 16:48:18 kraman2: I won't mind :-) 16:48:19 adrian_otto: is the expectation for an assignee writes some code 16:48:37 russellb: I missed that sorry. What was the concern? Can we repeat it? 16:48:40 aha 16:48:54 no, an assignee is not necessarily a code writer 16:48:58 why? 16:49:03 but you need to follow all the patches for that feature 16:49:14 why wouldn't you go to the person doing the work for an update? 16:49:16 so I prefer that it be owned by a developer 16:49:33 so they can review all the code that posts to that blueprint. It should at least be a reviewer. 16:49:52 this is a case where there will be more than one developer 16:50:01 if there is onyl one, this is simple, he/she owns it 16:50:05 russellb: how are other projects (nova?) structured ? 16:50:17 if there is a group contributing, then you pick a captain, essentially 16:50:19 and if there are multiple, one of the developers would own it? 16:50:27 right ... then the answer to the question is yes then right? 16:50:30 russellb: yes 16:50:36 the expectation is generally that the assignee is helping write the code at least 16:50:40 In the case of git blueprint, kraman2 has volunteered 16:50:57 yes, that makes sense for that one 16:51:00 I think he is the right owner of it since he will be closer to the code 16:51:14 * briancline also volunteered for pull 16:51:15 any other participants will be subscribers 16:51:33 and I ask that if you write *any* code for that bp that you review all patches for it. 16:51:53 +1 16:51:55 so you don't end up with duplicative contributions, or in conflict 16:52:31 for those who are new to using Gerrit+Launchpad together, the system can automatically post links to the patches in the LP whiteboard for the blueprint 16:52:44 when the Gerrit topic is listed in the whiteboard 16:53:04 so all you need to do is be a subscriber, and you will get an email every time someone posts a review against that blueprint 16:53:08 make sense? 16:53:17 you can also get email notifications from gerrit 16:53:24 for new changes, merged changes, or any updates to reviews 16:53:33 russellb: yes 16:53:41 that's more of a firehose 16:54:15 but i would expect anyone working on this full time to keep up with that, IMO 16:54:33 should always have an idea of what code is in flight 16:55:44 ok, so we had a packed agenda today, and I knew it would be hard to get through all of it, so I'll allow you to use the Agenda wiki page to know what needs to be assigned, and let's get those all assigned. See me if there are any questions, please. 16:55:56 so as a closing point, the current assignees on these should be following everything related, possibly contributing code 16:56:03 for those topics that need discussion, let's fire up ML threads for each 16:56:12 if i understood that correctly 16:56:28 briancline: i think assignees will be contributing code 16:56:40 kraman2: +1 :) 16:56:43 briancline: yes, if you own it, there is an expectation that you are down in the details 16:56:58 and that you are helping advance it 16:57:03 ok 16:57:31 and even if you are doing most of the code, and you don't want to be the owner, you will not be forced to. 16:57:34 briancline, kraman2: please feel free to add/modify to git-solum-pull bp. will be happy to discuss it afterwards 16:57:42 but one of your co-contributors will 16:57:50 i don't understand why the person doing most of the code would *not* be the owner 16:57:57 they are the owner by definition, to me 16:57:57 devkulkarni: will start a ML thread about it 16:58:12 russellb: I think that will happen naturally 16:58:26 and we can re-assign the owner when it makes sense 16:58:34 ok. 16:58:49 but I don't want contributors to get the sense that if they are not marked as the owner that they can't work on it 16:58:52 I think instead of much debating about who should own it, be a subscriber and write code :) 16:58:58 so I want to be very explicit about that 16:59:10 coolsvap_: +2 :) 16:59:20 exactly 16:59:22 so 16:59:23 #topic Open Discussion 16:59:33 sorry I never have enough time for this part of the meeting 16:59:49 I will need to do a better job of keeping the Agenda shorter 17:00:14 It will be hard for this stage of the project. 17:00:20 ML threads should help 17:00:24 indeed 17:00:35 We covered a lot. great meeting 17:00:39 thanks everyone, I'm super pumped about where we are 17:00:41 #endmeeting