22:00:05 <adrian_otto> #startmeeting Solum Team Meeting
22:00:05 <openstack> Meeting started Tue Jun 10 22:00:05 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:09 <openstack> The meeting name has been set to 'solum_team_meeting'
22:00:12 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-06-10_2200_UTC Our Agenda
22:00:19 <adrian_otto> #topic Roll Call
22:00:21 <paulmo_> Paul Montgomery
22:00:22 <adrian_otto> Adrian Otto
22:00:22 <asalkeld> o/
22:00:29 <julienvey> Julien Vey
22:00:30 <muralia> murali allada
22:00:49 <stannie> Pierre Padrixe
22:00:54 <iqbalmohomed> Hello all
22:01:15 <aratim> Arati Mahimane
22:02:33 <adrian_otto> ok, let's begin. If you have not yet recorded yourself in attendance, you may chime in at any time.
22:02:43 <adrian_otto> #topic Announcements
22:02:50 <datsun180b> sorry, i kept spelling it wrong
22:02:51 <adrian_otto> We will be tagging a release for juno-1 tonight. Thre are 9 bug/task tickets currently marked as in-progress. Anything that does not land by this evening will be retargeted to juno-2.
22:03:06 <adrian_otto> Are there any patches in particular that we should be sure to work together to merge before the release?
22:03:20 <asalkeld> don't think so
22:04:10 <adrian_otto> ok, thanks. If any thoughts come up during task review, just be sure to bird-dog anything important.
22:04:12 <adrian_otto> Any other announcements from any team members?
22:04:51 <paulmo_> Mind if I post a link for discussion at the open topic time?
22:04:52 <adrian_otto> I will share with you about some observations from DockerCon during Open Discussion
22:05:07 <adrian_otto> paulmo_: sure, you can do that now
22:05:27 <paulmo_> Solum + Workflow spec start: http://rst.ninjs.org/?n=37d5ba89876308e82d485333f43531dc   (will move it to Solum repo soon)
22:05:30 <paulmo_> Thanks!
22:05:49 <adrian_otto> ok, thanks paulmo. We will cover that in a moment.
22:05:59 <adrian_otto> #topic Review Action Items
22:06:07 <adrian_otto> julienvey to follow up with Heat contributors about Keystone chained trusted tokens, to offer our support. Include Solum Stackers in discussions.
22:06:28 <adrian_otto> any update on this one?
22:06:30 <julienvey> shardy is working on that https://review.openstack.org/#/c/97569/ https://review.openstack.org/#/c/96298/
22:06:52 <julienvey> and asalkeld is reviewing, so he might have more info than I have
22:07:02 <asalkeld> adrian_otto, shardy is about to start work on the chained trusts bp too
22:07:12 <adrian_otto> looks like that one was just +A today.
22:07:17 <asalkeld> yeah
22:07:26 <adrian_otto> ok, that's good news.
22:07:41 <asalkeld> I'll need to do some work in mistral
22:07:46 <adrian_otto> Do we feel like this is something taht needs any additional love/attention from us?
22:07:47 <asalkeld> to get this all working
22:08:05 <adrian_otto> asalkeld: tx
22:08:13 <asalkeld> there is some auth issues in mistral that need sorting out
22:08:25 <asalkeld> (I am working on it)
22:08:42 <adrian_otto> ok, so I will consider this action item completed.
22:09:00 <adrian_otto> the next one I have was actually carried over from 2 weeks back, and seems related
22:09:00 <asalkeld> #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26318.html
22:09:01 <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.
22:09:32 <asalkeld> so I believe the solution is trusts
22:09:49 <asalkeld> and we wait for chained trusts
22:09:59 <adrian_otto> ok, that seems sensible to me
22:10:08 <asalkeld> but we can work around the issues for the time being
22:10:20 <adrian_otto> do any other team members have further thoughts or concerns about this?
22:11:03 <adrian_otto> ok, so this action item is completed. Thanks asalkeld.
22:11:15 <adrian_otto> do we have all the task tickets we need for this?
22:11:20 <adrian_otto> or should more be opened?
22:11:28 <asalkeld> for what?
22:11:48 <adrian_otto> implementation of chained trusts once the feature is added upstream
22:11:55 <asalkeld> adrian_otto, I'll make bugs/bp as needed
22:12:04 <adrian_otto> t.
22:12:05 <adrian_otto> x
22:12:09 <adrian_otto> #topic Review Tasks
22:12:16 <adrian_otto> #topic https://launchpad.net/solum/+milestone/juno-1 juno-1 tasks
22:12:32 <adrian_otto> whoops
22:12:38 <adrian_otto> #topic Review Tasks
22:12:46 <adrian_otto> #link https://launchpad.net/solum/+milestone/juno-1 juno-1 tasks
22:12:50 <adrian_otto> that's better
22:13:11 <adrian_otto> so any work items in here that deserve interactive discussion today?
22:13:35 <julienvey> we can drop oauth
22:13:38 <adrian_otto> I created the juno-2 milestone in LP
22:13:42 <asalkeld> yeah good point
22:13:50 <adrian_otto> julien, ok, I will wontfix that one now
22:15:59 <adrian_otto> https://bugs.launchpad.net/solum/+bug/1316838
22:16:00 <uvirtbot> Launchpad bug 1316838 in solum "Tech Debt: Change to use keystone v3 uuid auth tokens" [Wishlist,Triaged]
22:16:21 <adrian_otto> that one may need to be updated, as we now have catalog filtering and token compression which work around the root cause
22:16:40 <asalkeld> also it's a deployment issue isn't it?
22:16:52 <julienvey> yeah, mostly a devstack config
22:17:25 <adrian_otto> but since we now get token compression from python-keystoneclient by default, it basically obviates this concern
22:17:25 <asalkeld> (or link to some docs)
22:17:51 <adrian_otto> onless anyone objects, I am going to withdraw this one
22:19:26 <asalkeld> +1
22:19:35 <adrian_otto> ok, done
22:19:44 <adrian_otto> any others catch your eye?
22:20:17 <asalkeld> we just mainly need to do the pipeline thing
22:21:11 <muralia> we should discuss the pipeline next and close on a few open questions.
22:21:15 <adrian_otto1> are you seeing me back again now?
22:21:19 <asalkeld> adrian_otto1 meet adrian_otto
22:21:22 <muralia> yes
22:21:43 <adrian_otto1> networking has been very sketchy here in San Francisco
22:22:03 <adrian_otto1> ok, le'ts move to open discussion
22:22:12 <adrian_otto1> #topic Open Discussion
22:22:15 <asalkeld> muralia, I think we really need to figure that out
22:22:16 <adrian_otto1> paulmo: you first
22:22:24 <paulmo_> http://rst.ninjs.org/?n=37d5ba89876308e82d485333f43531dc   again
22:22:31 <asalkeld> (and get stuck into it)
22:22:48 <paulmo_> I'm really trying to clarify positions and definitions right now.  Hopefully this helps.  Let's start with goals.
22:22:51 <muralia> :) I think the main question to answer is, do we expose mistral to end users or not.
22:22:55 <paulmo_> Does everyone agree with the goals stated?
22:23:13 <asalkeld> paulmo_, I haven't had time to read fully
22:23:25 <julienvey> asalkeld: same here
22:23:35 <paulmo_> There are just 4 short goals... I think this is key to cover before diving into details.
22:23:47 <paulmo_> •Solum must support a pluggable workflow engine
22:23:48 <paulmo_> •Create a version 2 Solum REST API and database scheme required to support workflow engines
22:23:48 <paulmo_> •Use Mistral as the first plugin workflow engine
22:23:48 <paulmo_> •Must prevent nonsensical or infinitely looping workflows
22:23:50 <datsun180b> having only just read the goals they look all right
22:23:55 <stannie> didn't read the whole docs, discovered it when the meeting started
22:23:56 <asalkeld> so I think mistral is the integration point of workflows
22:24:25 <asalkeld> so -1 to the first one if that means we have to abstract mistral
22:24:31 <julienvey> yeah
22:24:36 <julienvey> +1 to the -1
22:24:39 <paulmo_> Ok, so 1 is controversial.  What about the rest?
22:24:40 <muralia> we need to get the spec repo up so this can be hosted there and everyone can comment
22:25:04 <datsun180b> i'm trying to think of a case when a looping workflow would actually be desired
22:25:09 <julienvey> "Use Mistral as the first plugin workflow engine" this is not a goal, it's an implementation detail
22:25:19 <asalkeld> the last one is really mistral's job
22:25:29 <paulmo_> Good point Julien, I was just trying to put down on "paper" a decision that I think we've made.
22:25:35 <asalkeld> (to figure out that it is non-sensical
22:25:36 <asalkeld> )
22:25:52 <paulmo_> asalkeld: That is fine, I didn't say what would perform that action.  Mistral makes sense to me.
22:26:10 <asalkeld> sure
22:26:29 <adrian_otto> is a v2 of the API needed?
22:26:34 <asalkeld> no
22:26:38 <aratim> Even if we do not support a pluggable workflow engine, I think we should not expose mistral to the user
22:26:42 <asalkeld> (logical v2)
22:26:45 <paulmo_> Ok, so the main point of discussion seems to be around weather Solum directly exposes a Mistral REST API and Mistral DSL to end users directly.  Right?
22:26:58 <asalkeld> yip
22:27:12 <muralia> yes
22:27:19 <asalkeld> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036673.html
22:27:49 <asalkeld> there some points why I approached it the way I did
22:27:58 <paulmo_> Perhaps we should work on pro/con lists for each option... would that help?
22:28:07 <asalkeld> sure
22:28:18 <asalkeld> I don't want to road block development
22:28:25 <asalkeld> one question:
22:28:35 <paulmo_> Well, theoretically you can have Mistral running and access it directly now right?
22:28:36 <asalkeld> would doing this iterively be a problem
22:28:55 <asalkeld> paulmo_, sure
22:29:13 <asalkeld> so we could start with little/no wrapping
22:29:14 <paulmo_> I don't think it would be an issue as long as we know where we are going as an end/ideal goal.
22:29:32 <julienvey> paulmo_: this is not really iterative =P
22:29:34 <aratim> yea, I think we can use mistral directly first and later build a wrapper around it
22:29:36 <adrian_otto> there is a difference between using mistral to implement the default workflow, and exposing Mistral specifics through a Solum API
22:29:52 <asalkeld> totally
22:29:56 <adrian_otto> I think providing a link to the mistral service endpoint is enough
22:30:08 <asalkeld> ?
22:30:16 <adrian_otto> we have nothing to add
22:30:26 <asalkeld> sure we do
22:30:27 <paulmo_> So adrian favors Option A it sounds like?
22:30:30 <muralia> I would prefer not exposing the mistral dsl to end users as there are many things the end user should not be concerned with
22:31:10 <muralia> a simplified pipeloine config could look as simple as this
22:31:12 <muralia> tasks:
22:31:12 <muralia> unit_test:
22:31:12 <muralia> cmd: ./run_tests.sh
22:31:12 <muralia> create_image:
22:31:12 <muralia> function_test:
22:31:12 <muralia> cmd: (cd functional_tests ; ./run_tests.sh )
22:31:12 <muralia> deploy:
22:31:21 <asalkeld> well I think we are really split on the approach
22:31:50 <paulmo_> asalkeld: Unfortunately I agree.  I'm not sure how to convince one side or another to switch. :)
22:31:51 <asalkeld> but again, we could start simply and abstract more later if we feel it does work well?
22:32:25 <paulmo_> I think it would help to have a bit of a longer roadmap to keep everyone's work queues busy.  Just my opinion though.
22:32:52 <asalkeld> paulmo_, that assumes you want to go there
22:33:00 <julienvey> not very "agile"
22:33:01 <muralia> changing the way a user defines the CI/CD workflow many times over a period of a year will really hurt adoption in my opinion.
22:33:05 <stannie> +1 asalkeld I'd rather have an iterative approach
22:33:30 <adrian_otto> do we share a vision of having a very simple UX for the general case?
22:33:43 <adrian_otto> or are we divided on that point as well?
22:33:43 <asalkeld> UI yes, totally
22:33:54 <stannie> also the Option A looks very hard for a User but there will a UI to make it easier right ?
22:33:56 <asalkeld> but the api should not be dumb
22:34:16 <asalkeld> (IMO)
22:34:16 <muralia> +1 on simple for the general case
22:34:22 <paulmo_> stannie: If it is CLI, there isn't much UI to help but there is some..
22:34:49 <asalkeld> paulmo_, you wouldn't use a cli to check the status of jenkins
22:35:00 <stannie> indeed...
22:35:09 <asalkeld> (you go to  a web page to see the status of your jobs)
22:35:16 <asalkeld> link to logs etc...
22:35:31 <adrian_otto> My current point of view (willing to be persuaded  otherwise) is that we can let Mistral lead the workflow DSL work, and provide them with requirements. We offer access to that for power users. Our general users can just use UI to do the common tasks, such that it's only the exception that you are seeking out a DSL to adjust workflow steps.
22:35:48 <adrian_otto> do we agree on that?
22:36:00 <asalkeld> totally
22:36:09 <stannie> exactly adrian_otto
22:36:21 <julienvey> also, from option A, steps 1 and 2 may not be required by the users, if they use a default workflow provided by solum
22:36:24 <muralia> ok, I agree with that.
22:36:38 <aratim> +1
22:36:43 <muralia> julienvey: yes
22:36:44 <stannie> yep julienvey, it's only for Custom Workflow I guess
22:37:05 <paulmo_> So no CLI ability to do anything with workflows?  No REST API ability to do anything with workflows?
22:37:31 <adrian_otto> paulmo_: CLI + Web UI for that would be useful
22:37:32 <paulmo_> (solum CLI and REST that is)
22:37:42 <adrian_otto> I see no reason to duplicate mistral APIs or DSL
22:37:51 <julienvey> +1
22:37:54 <stannie> we didn't say no CLI, but no duplication
22:37:56 <adrian_otto> if we have a UI that is reasonably useful
22:37:59 <stannie> +1 adrian_otto
22:38:02 <asalkeld> +1
22:38:05 <ravips> +1
22:38:19 <adrian_otto> ok, so seems like we are alights on a DRY approach
22:38:24 <adrian_otto> aligned
22:38:40 <paulmo_> I'm not sure one way or another without more details to be honest.
22:38:47 <adrian_otto> and that simplification efforts should be in our tools rather than in our API
22:39:00 <asalkeld> this does assume a heave dependence on mistral
22:39:05 <asalkeld> heavy
22:39:17 <asalkeld> so we will need to contribute there
22:39:23 <paulmo_> I thought a top goal was a pluggable workflow engine?
22:39:29 <adrian_otto> because the truth is that anyone preferring to use API's to do CI customization is a power user, and should have hte full depth of capability available in the workflow system
22:39:44 <adrian_otto> paulmo_: well, almost…
22:39:58 <julienvey> mistral engine can be changed if i'm right
22:39:59 <asalkeld> paulmo_, I think we can use mistral to fire off jenkins
22:40:00 * paulmo_ is more confused as this discussion progresses...
22:40:08 <adrian_otto> we don't have to implement it as engines, but we need to have clean and simple integration points where other tools can easily integrate
22:40:12 <asalkeld> and yes you can change the engine too
22:40:19 <adrian_otto> and a way to easily noop the default workflow
22:40:44 <adrian_otto> that could be a first attempt, and we could then fortify that into a more pluggable system as we see use cases for that
22:41:04 <adrian_otto> I'd really like our solution to tha problem to be informed by input from seeing how customers use it
22:41:22 <asalkeld> adrian_otto, I also think doing less is better initially as we have to integrate with other tools
22:41:27 <adrian_otto> and what preferences they express about what the ideal setup would be
22:42:03 <adrian_otto> I met a few new potential users this week
22:42:24 <asalkeld> it's not easy to find an abstraction that works without really trying to integrate (like with zuul)
22:42:25 <adrian_otto> and these are *not* 12-factor apps
22:42:59 <adrian_otto> and I see more of a desire to start over on CI rather than "plug my jenkins into Solum"
22:43:15 <adrian_otto> I was not expecting that, although I still have a pretty small sample set.
22:43:21 <asalkeld> ok
22:43:34 <asalkeld> I have to go soon - take kids to school
22:43:55 <adrian_otto> paulmo: do you have enough input on this to work a revision?
22:44:22 <paulmo_> Not at all.  It sounds like I'm either A) Done, just expose Mistral REST directly or B) ???
22:44:27 <adrian_otto> thanks asalkeld. I'll give some insights on Dockercon when we wrap up this subject.
22:45:44 * asalkeld heads off
22:46:21 <adrian_otto> paulmo_: ok, so Murali and I are concerned about an "exposure" of the Mistral services
22:46:32 <paulmo_> So am I
22:46:44 <adrian_otto> we want them to be available to those who need them
22:46:58 <adrian_otto> and for the default experience to be a simple Solum UI that controls what happens in Mistral
22:47:22 <paulmo_> UI = web and CLI?
22:47:28 <adrian_otto> whether that be web, or cli, or both, we can certainly explore together
22:47:40 <adrian_otto> even if it were web only, that might be sufficient
22:47:48 <adrian_otto> at least for a first attempt
22:48:20 <adrian_otto> it's just a better tool for that sort of a job
22:48:54 <muralia> so do we need a pass through api in solum to talk to Mistral?
22:49:05 <adrian_otto> I could imagine a CLI that does something like "solum pipeline /some/resource disable unit test" or whatever
22:49:06 <julienvey> no
22:49:07 <paulmo_> There is no need to do so.
22:49:29 <adrian_otto> but I prefer to defer that until after we ahve a web UI we like
22:51:24 <adrian_otto> I'm not sure we are actually in any disagreement, but uncertain what the approach is, and what actions come first, second, third, etc, right?
22:51:49 <adrian_otto> or do we in fact have a divergence in what the implementation plan should be?
22:52:13 <paulmo_> I'm going to have to think about this some... this is a complete change in direction from where I thought we were going.
22:52:42 <adrian_otto> ok.
22:52:50 <julienvey> paulmo_: it's the direction asalkeld took in his patches
22:53:16 <paulmo_> Right, and there was a lot of disagreement with that.
22:53:45 <adrian_otto> ok, let's put this on the agenda to follow up on next week.
22:53:47 <julienvey> yeah, but the main idea was here, right ? even if there were disagreements
22:54:20 <adrian_otto> let's continue a dialogue to sort through this so we all feel unified on the next steps.
22:54:32 <julienvey> I think we just decided to keep this direction for now, and delay to see if we need to change it
22:56:21 <adrian_otto> ok, time to switch topics for the last few minutes?
22:56:37 <julienvey> yeah, DockerCon ? :)
22:56:48 <adrian_otto> there has been a ton of talk at DockerCon this week about a whole fleet of new tools about orchestration with Docker containers
22:57:08 <adrian_otto> there are a *lot* of new tools surfacing for this.
22:57:19 <datsun180b> and 1.0 was released, that's worth mentioning
22:57:24 <adrian_otto> on the order of like 8 or 9 new things
22:57:34 <adrian_otto> yes, libswarmd was announded
22:58:06 <adrian_otto> which is worth talking about an OpenStack backend for
22:58:08 <devkulkarni> orchestration as in replacements for Heat?
22:58:16 <adrian_otto> so I will put that on the agenda for the containers team
22:58:54 <adrian_otto> devkulkarni: alternatives, or things to be used in combination with, yes
22:59:11 <devkulkarni> cool.
22:59:21 <adrian_otto> I'll stay in #solum a bit this afternoon to point you at a few.
22:59:56 <devkulkarni> that will be helpful
23:00:10 <adrian_otto> time for us to wrap up for today. The DockerCon conference is *packed* with lots of very excited users who are super interested in the space we are working in.
23:00:20 <adrian_otto> thanks everyone
23:00:25 <adrian_otto> #endmeeting