21:01:13 #startmeeting Solum Team Meeting 21:01:20 Meeting started Tue Aug 4 21:01:13 2015 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:23 The meeting name has been set to 'solum_team_meeting' 21:01:49 #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-08-04_2100_UTC Our Agenda 21:01:56 #topic Roll Call 21:01:58 Adrian Otto 21:02:01 Gilbert Pilz 21:02:03 Devdatta Kulkarni 21:03:02 hello gpilz, and devkulkarni 21:03:08 hi adrian_otto 21:03:08 hello 21:03:09 ./ 21:03:15 hello dimtruck 21:03:17 james li 21:03:20 good afternoon! 21:03:27 hello james_li_ 21:03:53 hello adrian_otto 21:04:08 Ed Cranford 21:04:49 hello datsun180b 21:04:50 #topic Announcements 21:05:05 none prepared. Any announcements form team members? 21:05:18 s/form/from/ 21:05:57 #topic Review Action Items 21:05:59 (none) 21:06:16 #topic Blueprint/Task Review and Discussion 21:06:35 (devkulkarni) Update on namespace migration -- Patch is approved (https://review.openstack.org/#/c/201287/). Will be merged at next gerrit downtime. 21:06:49 so update on this action item 21:06:57 pretty much summarized above 21:07:04 the patch has been approved 21:07:11 nice 21:07:17 but the actual migration from stackforge to openstack 21:07:27 will happen whenever there is next scheduled gerrit downtime 21:07:43 there are apparently a few manual steps that need to be done before the patch is merged 21:07:49 the infra team takes care of that 21:07:58 from our side, there is nothing more to be done 21:08:07 we just wait now 21:08:16 that is all on this topic 21:08:22 that's great news 21:08:23 (devkulkarni) Update on Vagrant setup -- Was failing due to issues in nova-docker. Is working now. Vagrant env pinned for now. 21:08:35 ok, so on this topic.. 21:08:47 thanks for the namespace work devkulkarni 21:09:06 my pleasure adrian_otto datsun180b 21:09:13 so on vagrant.. 21:09:24 from last couple of weeks our vagrant environment had been failing 21:09:26 #link https://review.openstack.org/207588 Fixing issues being encountered in devstack run 21:09:43 turns out that there are at least 6 things that need to be fixed in nova-docker 21:09:53 I have submitted a patch which adrian_otto has linked above 21:10:05 please take a moment to review it whenever you get a chance 21:10:13 in the mean while 21:10:33 I have changed our Vagrantfile in solum-vagrant to pin to my fork of nova-docker 21:10:35 glad you could distill it into those few pain points 21:10:44 datsun180b helped merge that patch 21:10:49 thanks for that datsun180b 21:10:49 this might be a good time to think about Magnum as a replacement 21:11:01 nova-docker is not being actively maintained 21:11:23 interesting 21:11:23 adrian_otto: yeah, i remember seeing some emails on the dev list 21:11:53 I thought that dims and ewindisch were still going to help move it along 21:12:23 adrian_otto: could you help us chalk up a plan of how magnum can be used instead of nova-docker? 21:12:49 both dims and ewindisch have other priorities now 21:13:03 sure, I can outline that 21:13:06 hmm.. I see. 21:13:17 this probably makes sense as a blueprint or spec, or both 21:13:25 agreed 21:13:55 for now, we can continue using our vagrant environment 21:13:57 but essentially we would adjust the heat template to use a Magnum resource rather than the current OS::Server resource 21:14:10 ah I see 21:14:13 makes sense 21:14:23 create a bay, and then put containers on that bay. 21:14:42 and the bay creation is handled by heat as well? 21:14:57 or the bay has to be created before (out-of-band) 21:14:58 Magnum already has scalable bays, so this could also be used for apps that want to run with a scaled app tier. 21:15:25 yes, when you create a bay, Magnum uses Heat to create the nova instances needed for that 21:15:25 interesting 21:15:49 co conceptually you have this "bay" which acts like a scalable "server" 21:16:07 that you can put containers on. If you use the Swarm bay type, then it has a Docker API 21:16:51 so the magnum resource in heat is for bay creation + container placement 21:16:55 bays are composed of 1 or more nova instances 21:17:03 and that number can be scaled on the fy 21:17:06 *fly 21:17:13 interesting 21:17:54 I need to read up on the magnum resource in heat. any good pointers that you can suggest for this adrian_otto? 21:18:07 good question. Let me ask. 21:18:18 that should be in our docs, but it's not there yet. 21:19:20 muraliaa you should propose solum-magnum integration spec ;) 21:19:28 :) +1 21:19:29 s/muraliaa/muralia1/ 21:19:37 +1 21:19:49 muralia1: I'm happy to help you with that 21:19:56 looking at that project, it's the next logical step for us 21:20:21 seems like his internet gave out 21:20:24 dimtruck: how much of understanding/insights you have gotten into magnum? 21:20:34 just initial foray 21:20:43 probably < 1 week of actually looking at code 21:20:57 but everything around it looks like a logical progression of solum -> heat -> magnum 21:21:03 imo 21:21:19 so yest. you were mentioning that the work that james_li did for securing our worker could potentially be done by magnum 21:21:24 yup! 21:21:38 if that is the case then the picture is little different (and a bit convoluted imo) 21:21:39 plus scaling 21:21:46 the picture that emerges is 21:21:47 plus linking 21:22:00 we won't have to worry about any of that i don't think 21:22:07 solum -> magnum (to build the DU) -> solum -> heat -> magnum 21:22:34 see if it is only the deployment which we offload to magnum 21:22:36 well, you wouldn't have magnum build the du imo 21:22:44 right 21:22:51 you'd still build everything and just offload deployment 21:22:55 right, that's what you said 21:23:29 in that case I don't agree with your point of yest. that the work that james_li has done in making our DU builds robust and secure would not be required 21:23:33 we will still need that 21:23:59 dimtruck: ok, I think we are on the same page 21:24:24 ahhh, yes - in CI his work is still important 21:24:33 the CD part can be offloaded 21:24:42 good catch 21:24:48 dimtruck, muralia1: it will be awesome to have that spec/blueprint with the help of adrian_otto 21:25:42 ok, we can chat with him after the meeting 21:25:54 cool 21:25:55 since muralia1 is internet-less 21:26:03 :) 21:26:37 #topic Open Discussion 21:26:58 have update about our gates 21:27:00 i submitted a rebased patch for operator 21:27:06 you go first devkulkarni 21:27:10 dimtruck: awesome! 21:27:11 ok 21:27:25 so our gates were failing because of changes in barbican 21:27:36 they changed the name of their configuration file 21:27:58 the fix was to change our devstack/lib/solum 21:28:09 the fix has been merged thanks to datsun180b and muralia1 21:28:16 so gates are clear now 21:28:26 dimtruck: you can go 21:28:31 i spoke briefly with john v and barbican should still parse the old file if need be, but our problems were in expecting the old file during our own devstack scripts 21:28:37 cool! 21:28:48 datsun180b: oh ! 21:29:09 actually there is one more thing on this 21:29:28 so the problem wasn't immediately with barbican, but just how we were using it. their methods changed and we didn't keep up 21:29:45 so in our devstack setup there was some special code that we had for starting and stopping barbican. it was put in place by ravips when he was working on that stuff. 21:30:14 interesting 21:30:20 so that code needs to be checked for (a) whether we need it or not anymore (b) if we do need it if it is correct or not 21:30:46 that piece of code was also causing our gates to fail 21:30:48 dollars to donuts we can trust the standard stop and start mechanism by now 21:30:57 after the configuration file name was fixed 21:31:40 so for the time being I have commented that code as we are not using barbican. I have created a bug to track this issue 21:31:57 datsun180b: fair enough 21:32:04 we need to verify that 21:32:24 I wanted to unblock our gate so have not checked it 21:32:48 dimtruck: now you can go :) 21:32:52 so i uploaded patch 3 of operator guide. Please review and let me know your thoughts :) 21:33:01 dimtruck: will do 21:33:03 whooot! 21:33:05 https://review.openstack.org/#/c/204312/ 21:33:09 has gerrit given you a +1 yet? 21:33:18 nope :) 21:33:19 devkulkarni: not yet 21:33:30 thanks for putting this together dimtruck 21:33:43 what tool did you use to create that architecture diagram? 21:33:46 i'm queued up 21:33:49 gliffy 21:33:51 looks clean 21:34:02 it's cool because you can export/import json files 21:34:15 and it supports open source projects 21:34:20 what do you mean? 21:34:39 i mean it's ok to use for open source projects without buying a license 21:34:40 images are created/saved as json? 21:34:49 oh, you can save the image as json 21:34:57 and then upload it to gliffy and it renders the json 21:35:08 so it can be versioned really well as json 21:35:23 wow! should be very useful 21:35:25 in fact, i should have probably uploaded the json to our guide now that i think about it 21:35:28 ugh 21:35:38 yeah, that will be helpful 21:38:03 adrian_otto: I guess we are done for today. You can end the meeting. 21:38:22 agreed 21:38:53 p.s. i just pushed the json file 21:39:08 saw that 21:39:14 https://review.openstack.org/#/c/204312/4/doc/source/configure_and_run/solum_architecture.gliffy 21:39:23 yeah..very interesting 21:39:52 reminds me of the postscript language 21:40:03 oh geez 21:40:11 python -mjson.tool that willya 21:40:32 did they just make an svg<->json mapping or what 21:40:50 looks like.. 21:41:07 datsun180b weren't you working on something similar in your spare time? 21:41:35 well i learned to just write svgs anyway 21:41:57 and animate them with js, since they're xml they have a DOM that can be navigated and manipulated 21:42:53 interesting. yeah, if its a DOM it can be manipulated via js 22:00:13 #endmeeting