16:00:13 #startmeeting Solum Team Meeting 16:00:16 Meeting started Tue Aug 26 16:00:13 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:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:19 The meeting name has been set to 'solum_team_meeting' 16:00:24 #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-08-26_2200_UTC Our Agenda 16:00:32 #topic Roll Call 16:00:35 Adrian Otto 16:00:38 Ed Cranford 16:00:39 Ravi Sankar Penta 16:00:43 Devdatta Kulkarni 16:00:44 Gilbert Pilz 16:00:44 Murali Allada 16:01:10 Pierre Padrixe 16:01:20 Roshan Agrawal 16:01:43 james li 16:02:42 welcome everyone. Let's begin 16:02:50 #topic Announcements 16:02:54 I will be on ETO from Aug 29th to Sep 12th, so will miss the next 2 meetings 16:02:56 Hi 16:03:06 ravips: enjoy your time off!! 16:03:15 have fun! 16:03:18 I'll count that as Announcement #1 16:03:26 have fun ravips 16:03:32 thanks :) 16:03:46 Announcement #2 is: 16:03:48 Our team has expressed an intent to pursue incubation for Solum. 16:03:55 One of the criteria for exiting incubation is showing production usage of the software from a project team. 16:04:03 Rackspace is now using Solum in a production capacity in the delivery of one of it's managed services. 16:04:12 ok 16:04:12 I look forward to announcing other production uses of Solum as I learn about them. 16:04:42 thanks to all our contributors for helping to make this possible 16:05:08 Announcement #3 is: 16:05:10 Release 2014.2.1 (+python.solumclient 1.2.1) cut. 16:05:21 #link http://tarballs.openstack.org/solum/solum-2014.2.1.tar.gz Solum 2014.2.1 Release Tarball 16:05:27 #link http://tarballs.openstack.org/solum/solum-2014.2.1.tar.gz Solum 2014.2.1 Release Tarball 16:05:35 woot! 16:05:42 I still have some administrative shoveling to do in Launchpad 16:05:53 that's a good verb for that 16:06:20 but *applause* for another release for both solum and python-solumclient that include a lot of our blood sweat and tears 16:06:29 the bug fixlists are impressive 16:06:46 Announcement #4 is: 16:06:58 #link http://openstacksv.com/ Openstack Silicon Valley 2014-09-16 16:07:14 this is an OpenStack event happening in Northern California next month 16:07:30 I will be attending. It happens to fall on a Tuesday, so it will conflict with our team meeting 16:08:04 I'd like to plan to take one of two actions: 1) Cancel out 9/16 team meeting -or- 2) Select a pro-tem chair to run it while I am out 16:08:09 what are your preferences? 16:08:29 keep the meeting so that there is continuity 16:08:36 i say keep the pattern, #2 16:08:41 option-2 preferred 16:08:42 +1 16:08:48 +1 16:08:52 ok, in that case, I will take volunteers to chair 16:08:57 #2 16:09:11 I can do it 16:09:20 devkulkarni: thanks. 16:09:22 i've got prior experience! i'll even file the minutes in the right directory this time 16:09:25 any objections? 16:09:46 datsun180b: cool. I will pick your brain then :) 16:10:07 ok, so devkulkarni can be the chair, and if he does not appear on time, then datsun180b will assume the role for him. 16:10:08 dev's got this 16:10:18 sounds good 16:10:26 #agreed devkulkarni will chair our team meeting on 2014-09-16 16:10:40 Announcement #5 is: 16:10:51 All Bug/Task tickets have been triaged. Please check to see if you have any marked INCOMPLETE. 16:11:08 #link https://bugs.launchpad.net/solum/+bugs Our Bug List for Solum 16:11:44 so now is the time to scan the backlog of bugs and tasks, and to get me your input for what should be included in juno-3. I have some guidance from you already. 16:12:06 it's not too late to make a case for including anything you are willing to allocate engineering resources towards. 16:12:30 is there a link for juno-3 that you can share with all? 16:12:48 devkulkarni: not yet. That is one of the shoveling items I need to do 16:13:17 okay. 16:13:30 ok, so that concludes our announcements. (that was a bunch!) 16:13:38 #topic Review Action Items 16:13:40 while we are discussing juno, could we curate juno-2 16:13:42 (none) 16:13:44 so what has been written by roshan in the wiki/ml is not the final roadmap for juno-3 right ? 16:14:05 stannie: not final, but that is my guideline, yes 16:14:08 ok 16:14:18 stannnie: that is meant to be a basis for discussionm not final 16:14:20 if you have strong feelings about adjusting anything, let's talk 16:14:41 we have room for that in Open Discussion today 16:14:47 #topic Blueprint/Task Review 16:15:00 #link https://bugs.launchpad.net/solum/+bug/1358462 Java+Tomcat Language Pack 16:15:02 Launchpad bug 1358462 in solum "Create Java+Tomcat language pack to run Java web applications" [Undecided,Incomplete] 16:15:07 Should we develop a Java language pack? Are existing Build Packs sufficient? 16:15:41 adrian_otto: so we need some investigation about whether CF Javabuildpack would work as is in Solum or not 16:15:45 the reason I am raising this for discussion is because similar work appears to be happening in other open source projects that we may be able to leverage. 16:15:55 here is a link for that: 16:16:06 #link http://blog.cloudfoundry.org/2013/09/06/introducing-the-cloud-foundry-java-buildpack/ CF Java BuildPack 16:16:14 Java is a popular language so should support that our of box in Solum. 16:16:22 my understanding is that at least one also exists for Heroku 16:16:34 roshanagr: agreed. 16:16:44 so we already support Java runtime via cedarish stack 16:16:45 We do need to work out if we want to build our own docker image for it, or leverage CF build pack 16:16:53 yeah, I agree if there is an existing buildpack we can leverage thta 16:16:57 my question is whether we accomplish that by leveraging prior art, or making our own equivalent(s) 16:17:02 it would be uber-cool if I could run the VitaMinder example on both nCAMP and Solum 16:17:22 I also recognize that OpenShift has good support for JBOSS 16:17:30 gpilz: what all things do you need for that app to run? jdk version/maven/tomcat ? 16:17:33 so it might make sense to explore that too 16:17:40 leveraging prior art (say CF build pack) is worth exploring 16:17:42 adrian_otto: sure 16:18:02 recognizing that a JBOSS runtime and a Tomcat runtime are rather different. 16:18:06 how do we think of TomCat 16:18:16 openshift cartridges is curently on v2 (yaml format) and v3 format will support dockerfile 16:18:49 I think Java Tomcat 7 would be nice 16:19:13 roshanagr: sure.. I guess one problem with picking a specific tool and specific version 16:19:31 is there is a high probability that we will become outdated soon.. 16:19:40 +1 Tomcat 7 - known quantity 16:20:15 what we should aim at is doing something that we are currently doing for Python/Ruby.. have a 'requirements.txt' kind of thing in the repo and then use it to build the runtime with the required tools 16:20:25 the root of my question really comes down to whether we want the support/maintenance commitment that comes with developing an LP for a given language 16:20:30 the only thing that would not really change is jdk version (which will be somewhat stable) 16:20:37 should that be carried by the open source project, or the cloud operators? 16:21:09 open source project like ours will be always short handed trying to support 16:21:10 seems like a core set of LPs should be carried by the project 16:21:15 all the lps that people may want 16:21:26 we should provide reference LPs 16:21:31 projects in the CI/CD space leave hands off of this, and projects in the PaaS space seem to take this on. 16:21:33 with ability to create custom LPs 16:21:41 by the opensource project is fine but we have to make sure it's up to date with the latest security fixes (always some troubles with java :/) 16:21:44 adrian_otto: to your point, are you suggesting we add support for "custom language packs" and democratise what does into the language pack 16:22:11 roshanagr: we already have support for custom language pack 16:22:17 I want us to make a concious decision to enter the world of language specific LP's 16:22:23 (the API part still needs some work) 16:22:32 or a deliberate decision not to 16:22:53 devkulkarni: good to know ! 16:23:07 I suggest we provide some reference packs (Java 8 with Tomcat 7, for ex) 16:23:18 and then provide the custom language pack API 16:23:34 which would enable consumers of a particular instance of Solum to create their own LPs 16:23:43 and register them in their own Glance 16:23:50 to be used in their plan files 16:23:53 devkulkarni: one possible drawback to that approach is that we may be incorrectly perceived as an XYZ language only solution 16:24:11 in CF what is cool is that you can fork the LP source and then extend the LP with your specific changes 16:24:21 just like Heroku was before they produced reference Build Packs for a variety of languages 16:24:38 adrian_otto: valid point 16:24:38 in fact that was DotCloud's point of differentiation 16:25:08 so one way to get around that will be to not tie the LPs that we provide with the Solum codebase itself 16:25:17 yes 16:25:35 the language specific LP's could be isolated from Solum in that way 16:25:49 to exhibit an arms-length relationship 16:25:53 right 16:26:08 adrian+otto: I like your suggested approach 16:26:10 also to emphasize that the provided LPs are just for example 16:26:11 adrian: does anyone really think anyone does language-specific PaaS anymore? 16:26:20 and it would lend itself to delegating control to other groups for maintenance of them 16:26:33 so the Ruby experts can own one, and the Java experts can own another, etc. 16:26:52 are we saying separate repo that will have reference implementations? 16:27:09 gpilz: you would be surprised how misguided most of the public is when given limited information 16:27:19 gpilz: actually yes.. I have heard folks going to particular PaaS because that PaaS has the best support for Python 16:27:42 ravips: yes, that's an option for us 16:27:45 ravips: yes 16:27:58 another approach might be to place them in contrib for now 16:28:07 and label them very clearly as references 16:28:20 yep. that's where we currently have the Dockerfiles for Chef and Go 16:28:49 okay 16:29:26 ravips: mind adding some links to that bug about OpenShift cartridges? 16:29:47 whenever you get a chance 16:29:49 ok, so maybe what we can do is start with a contrib approach 16:30:25 and revisit this again once we have had some more time to consider the ramifications of including or moving that code to other projects 16:30:26 #link http://openshift.github.io/documentation/openshift-pep-010-docker-cartridges.html 16:30:42 thanks ravips 16:30:49 anyone object to starting with this compromise? 16:30:53 adrian_otto: sounds good to me 16:31:14 I like that 16:31:20 +1 16:31:30 +1 16:31:34 roshanagr: ? 16:31:37 +1 16:31:39 +1 16:31:42 like it 16:31:45 +1 16:31:48 ok, good, one moment for the #agreed 16:32:49 #agreed Language specific language packs may be added to our contrib directory, labeled clearly as reference implementations, and shall be evaluated for movement to dedicated projects if/when they are used for production purposes and require ongoing maintenance. 16:33:23 ok, that satisfied my interest in this. I hope you all like that too. 16:33:35 +1 16:33:41 ok, so we are still in bug/BP/task review 16:34:02 I want to draw core reviewer attention to one review in particular… 16:34:12 https://review.openstack.org/111846 16:34:33 #link https://review.openstack.org/111846 Add barbican/mistral devstack integration for functionaltests 16:35:03 I suggest we get any final feedback in for this work, and proceed to merging once it's acceptable 16:35:08 ahead of other priorities 16:35:13 looks like it's already got 2 approves, it's zuul is just hammered right now 16:35:19 there is other work that is depending on it 16:35:26 ok, good, that happened this morning then 16:35:34 that Toggle CI button is nice 16:35:48 thanks ravips for getting that in 16:35:57 +1 thanks ravips 16:36:01 thanks you all for your reviews 16:36:05 that review is also carrying a bugfix from image handler 16:36:18 ok, are there other work items that need team discussion or attention? 16:36:32 ravips's other patch (private git repo) 16:36:38 yeah that's a big one 16:37:02 we all should try to get it in before ravips leaves for vacation (he has already gone through many rebases) 16:37:22 agreed 16:37:40 #link https://review.openstack.org/109468 Plan create/show will display artifact public ssh keys if present 16:37:44 is that the one you meant? 16:38:08 #link https://review.openstack.org/#/c/105605/ 16:38:11 that one 16:38:22 ravips: Jenkins is complaining on it 16:38:33 this should get fixed when the first one gets merged 16:38:38 likely it's that image states ordering bug 16:38:57 yes, this one is dependent on previous pull request 16:39:30 the previous one being the one with barbican client? 16:39:35 yes 16:39:40 ok 16:39:47 http://logs.openstack.org/05/105605/12/check/gate-solum-devstack-dsvm/a39ff5b/console.html.gz devstack setup failed, looks like upstream deps 16:39:48 I don't see anything in the dependencies section for 105605 16:40:51 adrian_otto: how to add dependecies to PR? 16:41:14 cross-project, i don't think you can 16:41:14 * ravips still learning gerrit tool 16:41:54 ravips: I have not done it after the fact… the way I have done it is by checking out the parent branch, and then modifying it. and submitting it as a separate review 16:42:02 then it happens automatically 16:42:16 ravips: do you mean dependencies to a patch ? you have to submit a review with multiple commits 16:42:22 within the same project, dependency ordering is git patch ordering 16:42:24 but it's not important since the other chance is in the merge queue already 16:42:33 ah, ok I will try that next time 16:42:36 I'll order a recheck on 105605 once that merges 16:42:40 right.. we don't need it now 16:42:40 so don't worry about it 16:42:52 okay 16:42:56 er commit ordering anyway 16:43:10 you just have to make sure you've different change-ids in your patch 16:43:33 ok, understood..thx 16:43:47 ok, any other things we should bird dog? 16:43:58 you can watch your meters fill up at http://status.openstack.org/zuul/ just filter on "solum" and expand the job boxes 16:44:26 ok, let's proceed to Open Discussion then 16:44:33 #topic Open Discussion 16:44:45 Paris — do we have a slot for Solum? 16:45:19 not yet. 16:45:38 My submissions for Summit sessions (main conference) for Solum were all rejected (4 of them) 16:45:47 boo 16:45:52 :( 16:45:56 the only one accepted was my multi-cloud containers talk 16:45:58 do they give feedback reviews? 16:46:14 once the call for submisions for OpenSource at OpenStack opens, we can apply for that. 16:46:34 I am confident that we will get that again like we did in Atlanta 16:46:35 and these are not part of the main conference? 16:46:49 that is part of the main conference, but it is not considered a Session 16:46:58 it's not part of the Design Summit though 16:47:25 and we can still apply to have Design Summit sessions to discuss our various project integration concerns 16:47:31 I see.. we should soon start articulating what next things we would want to discuss while at Paris 16:47:43 that usually opens for submissions and voting about a month before the event 16:48:54 ok 16:49:37 on another tiopic, Solum team members should be aware of this 16:49:51 #link #link https://review.openstack.org/114044 OpenStack Containers Service Spec Proposal 16:50:32 this is an effort within the OpenStack Compute project to add a new API service for containers to work in harmony with Nova 16:50:36 cool. thanks for sharing 16:50:57 since we all use containers a lot, it would be nice to have your input on that proposal 16:51:04 would this API be part of nova or separate from it? 16:51:23 devkulkarni: it would be a separate API that treats Nova as an upstream 16:51:53 is this proposal in review or it got accepted by nova team? 16:52:12 it has been agreed to in concept by the Nova team, and we are iterating on it now 16:52:25 okay 16:53:05 that review is not intended to merge into nova-specs, because it will have it's own repo soon. 16:53:20 it's there temporarily for collaboration purposes 16:54:24 whoops its != it's (sloppy grammar, Adrian) 16:55:09 * adrian_otto five minute bell 16:57:00 ok, anything else for today? 16:57:56 thanks everyone for attending. I'll see you here again next week. Our next meeting is on 2014-09-02 at 2200 UTC. 16:58:03 #endmeeting