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