16:00:27 <adrian_otto> #startmeeting Solum Team Meeting
16:00:28 <openstack> Meeting started Tue Jun  3 16:00:27 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:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:32 <openstack> The meeting name has been set to 'solum_team_meeting'
16:00:35 <adrian_otto> https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-06-03_1600_UTC Our Agenta
16:00:43 <adrian_otto> #topic Roll Call
16:00:45 <adrian_otto> Adrian Otto
16:00:46 <paulmo> Paul Montgomery
16:00:48 <funzo> Chris Alfonso
16:00:53 <julienvey> Julien Vey
16:00:59 <tomblank> tom blankenship
16:01:08 <devkulkarni> Devdatta Kulkarni
16:01:18 <stannie> Pierre Padrixe
16:01:45 <ravips> Ravi Sankar
16:01:54 <muralia> murali allada
16:01:55 <datsun180b> Ed Cranford
16:02:42 <datsun180b> cz was double-booked and won't make this meeting today
16:02:47 <adrian_otto> welcome everyone
16:02:53 <adrian_otto> thanks datsun180b
16:02:59 <iqbalmohomed> Hello all
16:03:04 <adrian_otto> I am happy to have your original nick back!
16:03:16 <adrian_otto> hello iqbalmohomed
16:04:01 <adrian_otto> ok, let's begin with announcements. Anyone else who has not chimed in may feel free to chat us at any time to be recorded in attendance.
16:04:17 <adrian_otto> #topic Announcements
16:04:33 <adrian_otto> ok, first of all, we extend our gratitude to Anita Kuno who agreed to serve as our election official
16:05:27 <adrian_otto> you may be pleased that in accordance with our ratified election rules, no further action is required for an election this cycle, as no new candidates for the PTL position were declared.
16:05:42 <adrian_otto> I will serve as your PTL for this cycle.
16:06:21 <julienvey> congrats adrian_otto
16:06:27 <adrian_otto> I will re-open candidacy when the Juno cycle comes to a close.
16:06:46 <tomblank> adrian_otto: congrats and thanks for performing this role for the project!
16:07:09 <adrian_otto> thanks everyone for your support. I am very proud of the work we do here, and am humbled to be a part of it.
16:07:22 <adrian_otto> next up, action items.
16:07:29 <adrian_otto> #topic Review Action Items
16:07:38 <adrian_otto> asalkeld follow up with keystone team by ML, and IRC (as needed) to explore options for multi-service trust tokens, OAuth, or chaining, and finding the right fit for Solum.
16:07:46 <adrian_otto> I did see an email thread about this.
16:07:51 <julienvey> yes, http://lists.openstack.org/pipermail/openstack-dev/2014-June/036490.html
16:08:10 <julienvey> it seems we will have to go with chained trusts in keystone
16:08:16 <julienvey> but it is not implemented yet
16:08:18 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036490.html ML Discussion about Trust Tokens
16:08:27 <adrian_otto> thanks julienvey for the link
16:08:47 <adrian_otto> ok, I think I saw a review in the queue for something about OAuth
16:08:56 <julienvey> yes, I abandonned that
16:09:06 <adrian_otto> I'm pretty sure I down-voted that awaiting an outcome from this discussion.
16:09:11 <adrian_otto> ok, thanks julienvey
16:09:39 <julienvey> I think steve from the heat is working with the keystone guys to have chained trusts between services
16:09:41 <adrian_otto> do we have an expected timeframe for chained trusts? Are we able to contribute that, or is it happening regardless?
16:10:11 <julienvey> I will ask angus or steve if there is a blueprint or a bug open about that
16:10:14 <adrian_otto> ok, julienvey are you willing to reach out to him a few times this week to see if there is anything we can do to help?
16:10:20 <julienvey> and if someone is working on that
16:10:30 <julienvey> adrian_otto: sure
16:10:40 <paulmo> I'm pretty interested in these discussions as well.
16:10:40 <adrian_otto> would you accept that as an action item? I see this as a high priority matter for us.
16:10:53 <julienvey> yes
16:11:32 <adrian_otto> #action julienvey to follow up with Heat contributors about Keystone chained trusted tokens, to offer our support. Include Solum Stackers in discussions.
16:11:38 <adrian_otto> ok, awesome, thanks for that.
16:12:04 <adrian_otto> next we have a bunch of topics relating to our top areas of development focus
16:12:23 <adrian_otto> I'd like us to timebox each of these so we have time to at least touch on each.
16:13:02 <adrian_otto> we do not need implementation plan perfection today, but at the very least subgroups of us who are interested, or who we know we can include to drive forward progress on each.
16:13:08 <adrian_otto> here we go...
16:13:24 <adrian_otto> #topic Mistral Integration Discussion (target 10 min discussion)
16:13:36 <adrian_otto> devkulkarni: this was from you
16:13:47 <adrian_otto> we have three links to share:
16:13:50 <devkulkarni> this is progressing along. datsun180b and asalkeld made headways into this
16:14:03 <adrian_otto> actually two
16:14:04 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/pipeline Pipeline Blueprint
16:14:12 <adrian_otto> #link https://bugs.launchpad.net/solum/+bug/1322748 Initial Mistral Feature Task
16:14:18 <adrian_otto> feel free to add other references
16:14:39 <devkulkarni> asalkeld has series of patches integrating mistral and pipeline resources
16:14:53 <devkulkarni> datsun180b will be able to provide more updates
16:14:59 <adrian_otto> ok, what key issues are open that we can offer guidance about?
16:15:26 <devkulkarni> so one key issue is whether to expose the mistral dsl to app developers
16:15:38 <adrian_otto> datsun180b: anything potentially controversial?
16:15:40 <datsun180b> oh the majority of what i accomplished is just getting mistral into our vagrant env
16:15:45 <devkulkarni> my impression is mistral dsl is still too level and we should not expose that to the app developers
16:15:55 <adrian_otto> devkulkarni: yes, the dsl is a good one to cover.
16:15:57 <devkulkarni> thoughts?
16:16:12 <adrian_otto> if I may summarize that one for the others here today
16:16:25 <devkulkarni> please do adrian_otto. that will be helpful
16:16:26 <aratim> +1 devkulkarni we need a simpler DSL to be exposed to the end user
16:16:27 <julienvey> devkulkarni: you think solum should act as a dsl on top of mistral's dsl ?
16:16:29 <muralia> I think we should not expose the mistral dsl to end users.
16:16:31 <paulmo> Don't expose Mistral DSL to users directly.  It would make switching out workflows really difficult later unless we accept Mistral DSL as the language for Solum workflow forever.
16:16:32 <adrian_otto> we intend to use Mistral as the backend our first implementation of Pipelines
16:16:53 <adrian_otto> it has a DSL, but we think it might be best not to expose that directly, in the interest of keeping the user experience very simple
16:17:01 <iqbalmohomed> Not exposing the DSL also lets people use a different workflow engine
16:17:15 <adrian_otto> we will link through to the mistral resources, so if someone is so inclined as to interact with the mistral service, they can customize those workflows there.
16:17:22 <paulmo> +1 iqbalmohomed
16:17:22 <adrian_otto> iqbalmohomed: exactly.
16:17:34 <ravips> +1 iqbalmohomed
16:17:42 <devkulkarni> julienvey: thoughts?
16:17:51 <adrian_otto> but the overall intent here is to make something useful for the general case without complicating the UX
16:18:04 <julienvey> having a dsl over the mistral dsl would require a lot more work on our side
16:18:14 <julienvey> in the long term, it's good
16:18:35 <julienvey> but we could start with angus' way of dealing with it
16:18:44 <julienvey> having a workbook url in the pipeline
16:19:17 <devkulkarni> so I am thinking that the dsl that we come up with is more about describing the pipeline
16:19:33 <paulmo> http://workflowpatterns.com/evaluations/standard/index.php might be useful if we want to partially adopt a standard.
16:19:34 <devkulkarni> it can refer to existing workbooks
16:20:02 <devkulkarni> that is huge listing paulmo.
16:20:06 <julienvey> devkulkarni: good idea
16:20:10 <devkulkarni> gut reaction is NO :)
16:20:18 <julienvey> such as heat templates can reference another heat template
16:20:28 <devkulkarni> yep
16:20:53 <stannie> yep I also like it
16:21:19 <devkulkarni> do we want to get an agreed on this or think it over a bit and revisit next time again?
16:21:30 <adrian_otto> I think there is a way for us to allow for workflows to be tweaked without making a comprehensive DSL
16:22:05 <adrian_otto> so to the extent that is practical, I suggest that as our direction, and we can continue to revisit this as we learn more.
16:22:10 <adrian_otto> sound fair?
16:22:29 <muralia> +1
16:22:38 <adrian_otto> and there would be no need to adopt the Mistral DSL until we had such a discussion
16:22:59 <devkulkarni> agree
16:23:01 <adrian_otto> ok, any more thoughts on this before we advance to the next tpic?
16:23:18 <adrian_otto> next...
16:23:23 <adrian_otto> #topic Custom Language Pack Discussion
16:23:31 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/auto-select-lang-pack
16:23:45 <adrian_otto> •	#link https://blueprints.launchpad.net/solum/+spec/custom-language-packs Custom Language Pack Blueprint
16:23:50 <devkulkarni> So noorul, adrian_otto have been brainstorming about what do we mean by custom lang packs
16:24:48 <devkulkarni> in my mind there are three kinds of lang packs — 1) provided by operator 2) lang packs/build packs belonging to other PaaS systems that we can support in Solum 3) lang packs that an app developer wants to create with custom libraries (e.g. chef testing tools)
16:25:15 <julienvey> devkulkarni: what's the difference between 1 and 2 ?
16:25:18 <devkulkarni> I want to hear what you all think about this topic?
16:25:30 <adrian_otto> We have at least two options for how we define the LP itself. 1) The LP is just an image in glance, done. 2) The LP may leverage an existing image, but add a git-repo to use as an external build-pack (approach consistent with Heroku and Cloud Foundry)
16:25:37 <julienvey> would cedarish fit into 1 or 2 ?
16:25:38 <adrian_otto> the two are not mutually exclusive
16:25:47 <devkulkarni> operator may provide some base lang packs which may or may not be compatible with other systems
16:25:49 <adrian_otto> cedarish would be #2 in my list
16:25:50 <paulmo> It seems 2 would go into bucket 1 or 3?
16:25:54 <devkulkarni> I think cedarish is 2
16:26:20 <julienvey> I think 2 can fit into 1
16:26:30 <adrian_otto> yes
16:26:36 <julienvey> cedarish is a "multi-language" LP
16:27:03 <devkulkarni> sure
16:27:13 <adrian_otto> so perhaps we start out with the #1 definition type, and then plan to expand that to add git-repo plugin capability to allow Solum users to extend it.
16:27:34 <adrian_otto> and operators can decide whether to include the images that contain the hooks for that extensibility
16:27:46 <julienvey> hooks are a good idea
16:27:49 <devkulkarni> adrian_otto: your definition of LP is not complete in the sense that #1 will be required no matter what
16:27:57 <adrian_otto> ok, any alternate points of view to consider here?
16:28:15 <devkulkarni> #1 is what we actually have to do for any LP to be supported via Solum
16:28:26 <devkulkarni> so that is not really a defining characteristic of a LP imo
16:28:34 <adrian_otto> devkulkarni: #1 is required. The question is whether to have #2 as well.
16:28:47 <devkulkarni> exactly
16:28:53 <adrian_otto> we agree 100%.
16:29:14 <devkulkarni> and the discussion at least to me is what are conceptually options available for #2
16:29:30 <adrian_otto> so I suppose I cold ahve framed the options as (1), or (1+2)
16:29:45 <devkulkarni> the proposed git repo hook approach — that would cover app developers specifying their required libs etc.
16:30:05 <iqbalmohomed> would that be similar to heroku's buildpacks?
16:30:09 <devkulkarni> would that also cover mechanisms in solum to support LPs/build packs from other PaaSes
16:30:21 <adrian_otto> the remote repo does a bit more as well, allowing the actual build execution logic to be adjusted.
16:30:23 <devkulkarni> or that could be a separate discussion
16:30:30 <adrian_otto> because alternate scripts could be provided.
16:30:42 <iqbalmohomed> this is via git execution hooks?
16:30:52 <julienvey> i think the example for (2) is adding the .net capability to cedarish. Am I right ?
16:30:53 <adrian_otto> so I don't hear any argument against using both approaches
16:31:08 <adrian_otto> julienvey: yes, that's a perfect example
16:31:20 <adrian_otto> I'd like to be able to allow a user to add that without a code patch to solum :-)
16:31:55 <tomblank> adrian_otto: +1 on using both approaches
16:32:12 <julienvey> yes, and hooks (in solum) to add capabalities would be an elegant way of dealing with it, imo
16:32:34 <devkulkarni> ok, hold on, lets reiterate what the two approaches are.
16:32:47 <devkulkarni> I see only only approach — git hooks
16:32:50 <devkulkarni> what is the other approach?
16:33:03 <iqbalmohomed> images in glance?
16:33:04 <devkulkarni> saving LP in glance is not an approach
16:33:15 <devkulkarni> that is required no matter what
16:33:26 <julienvey> devkulkarni: I don't understand what you mean by git hooks
16:33:37 <devkulkarni> we are talking about customizing language packs
16:33:52 <devkulkarni> we need approaches to do that .. the end result will go in glance no matter what
16:34:01 <julienvey> sure
16:34:26 <adrian_otto> the extensibility point will be a way to indicate that a build should consult the content in an external git repo that contains a build pack (compatible with Heroku and CF)
16:34:34 <devkulkarni> one approach that is coming up, as suggested by adrian_otto, is to use custom repo with git hooks (paraphrasing — could be wrong)
16:34:38 <adrian_otto> that could be a parameter, or metadata, etc.
16:34:54 <adrian_otto> it's not exactly a hook
16:35:03 <devkulkarni> thanks for clarification adrian_otto
16:35:08 <adrian_otto> just an external reference of where to get plugin code to adapt the build processing
16:35:37 <adrian_otto> ok, I think that was the confusion point
16:35:42 <rajdeep> i was thinking since CF and Heroku build packs are already there with an ecosystem
16:35:54 <rajdeep> wouldn't it make sense to base our definition on those
16:35:59 <rajdeep> rather than trying to build a new one
16:36:13 <devkulkarni> rajdeep: but they are not same, or are they?
16:36:20 <adrian_otto> I think it's time to record this in a task ticket, possibly linked to a wiki that can exhibit a simple block diagram to express the concept.
16:36:26 <rajdeep> they are mostly
16:36:35 <rajdeep> Cf is based on heroku build packs
16:36:51 <devkulkarni> what about OpenShift cartridges?
16:36:59 <adrian_otto> we also have a task that would allow compatibility with Openshift Catridges too
16:37:06 <adrian_otto> that's already on the wishlist
16:37:12 <rajdeep> infact CF team introduced them later as it was the best way to introduce a new platform
16:37:19 <adrian_otto> but let's walk before we run.
16:37:25 <aratim> how will this approach help the user to create his own language pack?
16:38:09 <devkulkarni> so that is other other category (#3) that I had in mind
16:38:18 <adrian_otto> aratim: as an end user I can post my custom build scripts in a git repo, and pick an LP entry that uses an image that will take my repo as a parameter/metadata and download it (as needed) and use it to run the build
16:38:19 <devkulkarni> which I think will be addressed by the custom repo approach
16:38:23 <devkulkarni> suggested by adrian_otto
16:39:08 <devkulkarni> yeah, that should work
16:39:10 <adrian_otto> ok, let's wrap up on this one and move to the next
16:39:14 <aratim> adrian_otto: yeah makes sense
16:39:34 <adrian_otto> devkulkarni: are you willing to take an action item to work with me on this to clearly document the approach and how it addresses each use case?
16:39:42 <devkulkarni> sure adrian_otto
16:39:50 <devkulkarni> lets do it
16:40:18 <adrian_otto> #action devkulkarni to work with adrian_otto to document the LP devleopment approach in BP+task+wiki to clearly outline our approach, and how it solves each use case.
16:40:43 <adrian_otto> and we will take input from anyone who is willing to review this, and add remarks
16:40:55 <adrian_otto> next, we have...
16:40:58 <adrian_otto> #topic Source to Image Pipeline Discussion
16:41:20 <devkulkarni> muralia has the latest on the pipeline -> plan discussion
16:41:36 <adrian_otto> We touched on this last week, but did not have time to explore nova-docker enhancements
16:41:48 <muralia> there is a google doc with some approaches. I'm going ot move these comments to the blueprint.
16:41:54 <muralia> https://docs.google.com/document/d/1a0yjxKWbwnY7g9NZtYALEZdm1g8Uf4fixDZLAgRBZCU/edit?pli=1#
16:42:27 <adrian_otto> muralia: I have the Solum Spec repo further down in the agenda
16:42:37 <muralia> ok.
16:42:46 <devkulkarni> okay, so about nova docker improvements..
16:42:53 <adrian_otto> once we open that, let's put the GoogleDoc content into RST and post it there for review.
16:42:53 <devkulkarni> we touched upon it last time.
16:43:16 <devkulkarni> the questions that I had (which we touched upon last time), was what are the exact things needed from us for that
16:44:29 <adrian_otto> that=nova-docker?
16:44:36 <devkulkarni> yes
16:44:41 <adrian_otto> glance integration
16:44:45 <devkulkarni> nova docker driver improvements
16:44:50 <adrian_otto> needs a multi-tenant solution
16:45:18 <adrian_otto> so rather than interfacing through docker to docker-registry to glance, we can just integrate directly with glance
16:45:36 <adrian_otto> and that approach works as a first iteration workaround
16:45:50 <devkulkarni> yeah, that should be helpful
16:45:55 <adrian_otto> then we can explore the future of docker-registry with the #nova-docker team
16:46:24 <adrian_otto> we did discuss that subject in Atlanta, and it appears to have non-technical aspects to motivating the stakeholders
16:46:56 <adrian_otto> this is something that the #openstack-containers team can deal with.
16:47:07 <devkulkarni> cool.. I guess my questions were more from the Juno-1 feature list (this is listed in Juno-1)
16:47:36 <devkulkarni> do you think nova docker driver improvements should be in Juno-1 or could they be moved out?
16:47:53 <adrian_otto> yes, bypassing nova-docker's use of docker-registry will suit our near term needs
16:48:12 <adrian_otto> and fixing docker-registry can be deferred as needed.
16:48:25 <adrian_otto> Anyone disagree?
16:48:50 <tomblank> should we collect our requirements in a single place/document, prioritze them, identify any must have features for Solum juno release, etc?
16:48:50 <devkulkarni> I guess we need time to think :)
16:48:55 <adrian_otto> ok, let's advance to our last couple of topics. These should be short.
16:49:03 <adrian_otto> #topic Review Tasks
16:49:09 <julienvey> I don't see why this is in our roadmap, it's a dependency we have on nov-docker, like we have on heat or mistral
16:49:15 <adrian_otto> I am doing some housekeeping on this:
16:49:33 <adrian_otto> #link https://launchpad.net/solum/+milestone/2014.1.2
16:49:45 <adrian_otto> I plan to tag this release today or tomorrow
16:49:55 <devkulkarni> julienvey: same thoughts here
16:49:59 <adrian_otto> I am moving everything that's not fix released to juno
16:50:25 <adrian_otto> and pulling everything in juno that is fix-released into 2014.1.2
16:50:42 <adrian_otto> so expect to see that shuffling in our tasks and BPs
16:50:54 <adrian_otto> any concerns with this?
16:51:07 <adrian_otto> I'd like to also lock down our demo to using the tagged release
16:51:14 <adrian_otto> so it's not a moving target
16:51:27 <devkulkarni> +1 to locking down demo to a tagged release
16:51:35 <paulmo> Yeah, +1 to that as well
16:51:36 <adrian_otto> I can tag releases as often as we need to in order to make changes to the demo setup
16:52:09 <adrian_otto> #agreed we will adjust our demo environment to use the upcoming 2014.1.2 release, and update to newer releases as needed.
16:52:17 <adrian_otto> ok, last agenda item
16:52:23 <adrian_otto> (next to last)
16:52:29 <adrian_otto> #topic Solum Spec Repo
16:53:06 <adrian_otto> I am planning to start a new code repository that will hold RST files of our specifications. The porpose of this is to allow for review of our design plans in the same way we do code reviews
16:53:17 <adrian_otto> the same reviewers will be attached to this repo
16:53:43 <devkulkarni> I think this will be helpful.. at least instead of googledocs
16:53:54 <adrian_otto> muralia will place our design work there, and we can more easily source input and have debate on items where we disagree
16:53:55 <ravips> that will be very useful
16:54:10 <muralia> +1
16:54:11 <adrian_otto> ok, so I will give you a heads up on the ML once that merges
16:54:15 <paulmo> +1 to this idea; btw, http://rst.ninjs.org/ might be useful for editors and such
16:54:15 <tomblank> is there a way to timebox the review period?
16:54:33 <adrian_otto> we can try that out, and switch to something else later if we don't find it useful
16:54:39 <devkulkarni> is there a need to timebox review period?
16:54:43 <adrian_otto> the Keystone team has used this approach successfully
16:55:00 <adrian_otto> devkulkarni: we can do that as needed
16:55:15 <adrian_otto> that's something we can certainly negotiate on an ML thread per design
16:55:16 <tomblank> devkulkarni: sometimes, I think it would be useful.
16:55:30 <tomblank> adrian_otto:  +1
16:55:33 <adrian_otto> I agree that having a deadline on something can help us focus on key issues
16:55:38 <julienvey> will we have to post all our design there or only high-level features ?
16:55:42 <adrian_otto> not every design needs a deadline
16:55:56 <adrian_otto> but ones that are critical to our Juno milestones should
16:56:16 <adrian_otto> julienvey: we can use our discretion
16:56:18 <tomblank> adrian_otto:  again, agree...
16:56:26 <adrian_otto> let's use it to see if it helps
16:56:38 <paulmo> I also like the timebox idea in that we can define a minimum review time to give folks in various time zones a fair chance.  2 days minimum I would think.
16:56:44 <tomblank> and we can adjust as needed..
16:56:46 <devkulkarni> btw, kgriffs warned about the design process getting heavy handed .. take a look at this email on marconi
16:57:12 <devkulkarni> *his
16:57:36 <adrian_otto> thanks devkulkarni. We can take that as an opportunity to learn from our peers.
16:57:49 <julienvey> devkulkarni: do you have a link ?
16:58:00 <tomblank> paulmo: +1
16:58:07 <adrian_otto> I will also offer myself as a release valve if any of our contributors are not comfortable with any design proceedings, please see me about it so I can work to address those concerns for you.
16:58:09 <devkulkarni> will send it to you julienvey (don't have it handy)
16:58:22 <devkulkarni> it was sent couple of days back
16:58:24 <adrian_otto> #topic Open Discussion
16:58:29 <adrian_otto> 2 mins remaining.
16:59:38 <rajdeep> have we done customer validation of features being built for solum
16:59:46 <adrian_otto> thanks everyone for attending today. Next week we should have a shorter agenda, so not quite as rushed.
17:00:08 <adrian_otto> rajdeep: we would love more!
17:00:13 <adrian_otto> #endmeeting