21:03:28 <devkulkarni> #startmeeting Solum Team Meeting
21:03:28 <openstack> Meeting started Tue Feb  3 21:03:28 2015 UTC and is due to finish in 60 minutes.  The chair is devkulkarni. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:31 <openstack> The meeting name has been set to 'solum_team_meeting'
21:03:46 <adrian_otto> devkulkarni
21:03:50 <devkulkarni> #topic roll call
21:03:56 <devkulkarni> hi adrian_otto
21:04:05 <adrian_otto> Adrian Otto
21:04:08 <datsun180b> ed cranford
21:04:08 <roshanagr_> Roshan Agrawal
21:04:10 <gpilz> Gilbert Pilz
21:04:11 <james_li> james li
21:04:14 <phiche> Philip Cheong
21:04:18 <ravips|mtg> Ravi Sankar
21:04:21 <muralia> murali allada
21:04:29 <devkulkarni> hey everyone..
21:04:32 <mkam> Melissa Kam
21:04:59 <devkulkarni> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-02-03_2100_UTC agenda for today
21:05:20 <adrian_otto> it is next week that I am away, not today.
21:05:24 <devkulkarni> right
21:05:32 <devkulkarni> and we were wondering where you were :)
21:05:37 <devkulkarni> it was past 3.00pm
21:06:03 <devkulkarni> #topic Announcements
21:06:15 <devkulkarni> are there any announcements from the team members?
21:08:08 <devkulkarni> #topic Review Action Items
21:08:19 <devkulkarni> adrian_otto to open a bug ticket to allow for pinning mistral to a version that is known to pass gate.
21:08:36 <adrian_otto> https://bugs.launchpad.net/solum/+bug/1417767
21:09:25 <devkulkarni> thanks adrian_otto
21:10:25 <devkulkarni> were there any other action items that the team members remember?
21:10:35 <adrian_otto> that was the only one.
21:10:53 <devkulkarni> ok
21:11:09 <devkulkarni> #topic Blueprint/Task Review
21:12:00 <devkulkarni> are there specific tasks/blueprints that the team members want to bring up for discussion?
21:12:32 <devkulkarni> btw, thanks to the entire team our review queue has become lot thin https://review.openstack.org/#/q/status:open+solum,n,z
21:13:37 <adrian_otto> https://review.openstack.org/148023 is in merge conflict
21:13:45 <adrian_otto> will a rebase solve that?
21:14:00 <devkulkarni> I think that can be abandoned
21:14:14 <devkulkarni> that change is already merged as part of a different reivew
21:14:17 <adrian_otto> ok, I will set it accordingly.
21:14:41 <devkulkarni> sounds good
21:15:16 <devkulkarni> are there any other reviews/tasks?
21:15:31 <devkulkarni> I would have liked to discuss the plan to go from bash to python
21:15:38 <devkulkarni> but I don't see akshayc around today
21:15:54 <devkulkarni> ravips: have you had a chance to touch base with akshayc on this?
21:15:55 <adrian_otto> dimtruck: can you make some time to look at https://review.openstack.org/140468 again?
21:16:06 <dimtruck> adrian_otto: i will do so
21:16:07 <dimtruck> yes sir
21:16:10 <adrian_otto> thanks
21:16:11 <dimtruck> sorry i dropped the ball on taht one
21:16:27 <dimtruck> i'll get that fixed and through in the next 24 hours
21:17:03 <adrian_otto> np
21:17:16 <ravips> devkulkarni: not yet, i will check with him
21:17:26 <devkulkarni> ravips: thanks!!
21:17:41 <devkulkarni> I will also reach out to him if I catch him on solum
21:18:30 <devkulkarni> any other blueprint/tasks we want to discuss?
21:19:14 <devkulkarni> ok.. moving on to open discussion
21:19:20 <devkulkarni> #topic open discussion
21:19:23 <adrian_otto> o/
21:20:22 <adrian_otto> this week the CAMP Technical Committee met, and I discussed what we have learned regarding resource terminology (plan, assembly) in favor of more generic terms (app_template, app)
21:20:44 <adrian_otto> I have been invited to raise an issue against the spec to get the terminology changed.
21:20:55 <muralia> nice.
21:21:01 <adrian_otto> THere is enough support among the TC to get that done quickly
21:21:31 <adrian_otto> I suggest that we form a small working group to meet a couple of times to be sure that the proposal is compatible with our thinking
21:21:39 <adrian_otto> would any of you like to participate?
21:22:08 <roshanagr1> I would
21:22:08 <gpilz> i would
21:22:11 <gpilz> hehehe
21:22:24 <muralia> me too
21:22:28 <adrian_otto> Assuming that issue is accepted, the likely outcome will be that CAMP 1.1 would remain as-is as a committee spec.
21:22:50 <adrian_otto> and a modified version would succeed it as CAMP 1.2, which would later be pursued to become an OASIS standard.
21:23:19 <adrian_otto> the scope of this change is not to start over with the spec, but to adapt the terminology to be more closely aligned with end user expectations
21:23:38 <adrian_otto> ok, I will circulate a Doodle to find a couple of times to meet and align on this topic
21:24:18 <adrian_otto> I will email it to the openstack-dev list with the [Solum] topic tag
21:25:06 <gpilz> i should point out that people are also more than welcome to participate on the CAMP TC calls themselves
21:25:23 <adrian_otto> thanks, that's it on this topic for now unless roshanagr1 muralia gpilz or others have more thoughts on it to cover today.
21:25:28 <gpilz> we haven't publicly eviscerated a new-comer in …. gosh, it must be months now
21:25:45 <datsun180b> i prefer my insides stay inside thank you
21:25:52 <adrian_otto> gpilz: we have a new member from NetApp, remember?
21:26:05 <gpilz> i'll get the oven on
21:26:41 <adrian_otto> so for those who come to the Solum working group on CAMP, I'll provide information about OASIS meeting attendance, if that interests you
21:28:03 <adrian_otto> any other topics to cover today?
21:28:11 <roshanagr1> adrian_otto: would it be correct to characterize it as a "Solum working group on CAMP" - or just some folks participating in a CAMP discussion
21:28:30 <ravips> what will be our strategy for integrating jenkins ci in solum? is it going to be another option for pipeline (mistral replacement)? or first class entity where you can specify use jenkins as my ci for my app or plugin model where app can use jenkins via hooks?
21:28:37 <adrian_otto> working groups in OpenStack are not formalized, so there is really no distinction
21:29:13 <datsun180b> ravips: you could write a different solum-worker handler to use jenkins to do the work
21:30:05 <datsun180b> shell.py is called so because it uses shell commands in that environment. instead you might open an http client and send requests to your jenkins endpoint to trigger work
21:30:21 <datsun180b> but that's off the cuff, i'm sure i've glossed over 95% of the important details
21:30:31 <devkulkarni> ravips: when stannie was driving that spec, we had discussed two options. first was, Jenkins calls into Solum to deploy and Solum uses Jenkins to do builds. I think the first option was easier per stannie's investigations
21:30:39 <adrian_otto> datsun180b: that's a good suggestion, I think.
21:30:54 <adrian_otto> ravips: tell us about the reason for your question
21:31:20 <adrian_otto> we initially indicated that we wanted a choice of workflow options
21:31:39 <adrian_otto> we identified Mistral and Jenkins as two implements for that
21:31:46 <ravips> adrian_otto: it was there in the roadmap so wondering the design choice we took
21:32:03 <devkulkarni> ravips: we have not made any design decisions on that front yet
21:32:11 <adrian_otto> my question is should that remain in the roadmap? Will our users care about configurable workflows, or not?
21:32:33 <ravips> devkulkarni: can you point me to the stannie initial spec on jenkins
21:32:33 <devkulkarni> good point
21:32:43 <roshanagr1> Question on jenkins integration with Solum - is there someone who is passionate and still cares about the feature
21:33:28 <devkulkarni> ravips: quickly looking through our blueprint list, I got this: https://blueprints.launchpad.net/solum/+spec/solum-build-farm
21:33:40 <devkulkarni> will send you the spec review soon
21:33:43 <adrian_otto> #link http://git.openstack.org/cgit/stackforge/solum-specs/tree/specs/juno/pipeline.rst Pipeline Spec
21:34:23 <devkulkarni> ravips: https://review.openstack.org/#/c/100539/
21:35:23 <devkulkarni> roshanagr1: providing hooks in Jenkins to be able to call into Solum for deployments could be useful
21:35:31 <roshanagr1> adrian_otto: are you asking if jenkins integration should still remain on the roadmap? If so, I am asking the same question - should it
21:35:40 <adrian_otto> yes
21:35:48 <adrian_otto> yes - that is my question
21:36:13 <adrian_otto> If pipelines exist, you can configure those to kick off any other workflow service
21:36:15 <ravips> we are already using mistral for workflow(pipelines), jenkins ci story is mainly to support external existing jenkins in solum?
21:36:29 <roshanagr1> adrian_otto: cool. Devkulkulkarni - are there immediate drivers for the team investing in this feature
21:36:48 <adrian_otto> ravips: I don't think any code would be needed in Solum to support Jenkins with Pipelines
21:36:50 <roshanagr1> if not, is the effort investment somewhere more urgent
21:36:51 <devkulkarni> roshanagr1: frankly, don't know
21:37:21 <adrian_otto> all you would need is a Mistral workflow that calls Jenkins
21:37:37 <adrian_otto> that's input to solum, not code in Solum.
21:38:12 <roshanagr1> devkulkarni: ok, I am taking an action item to streamline the roadmap for Solum, and then socialize it with the team
21:38:14 <devkulkarni> have anyone been exercising Solum's mistral/pipeline code? how complete/workable that piece currently is?
21:38:20 <adrian_otto> we could make equivalents for other tools too (drone.io, Circle CI, etc.)
21:38:49 <phiche> i like that suggestion adrian_otto
21:39:05 <adrian_otto> devkulkarni: I'm not aware of any users of that feature, but we also have not documented it very well either, so that's not a surprise
21:39:19 <ravips> devkulkarni: i tried pipeline functionality a month back and ran into heat issues
21:39:27 <adrian_otto> phiche: tx
21:39:38 <devkulkarni> ravips: oh okay.
21:40:45 <devkulkarni> one of these days we need to think about how to plan converging assembly_handler and pipeline_handler
21:41:01 <datsun180b> i think that will be done by creating app_handler
21:41:46 <adrian_otto> I'd like to see a spec proposal for that
21:41:59 <datsun180b> following oasis' tete-a-tete i imagine we'll have a much stronger set of requirements for what an app is
21:42:38 <adrian_otto> that raises the topic of whether such a thing is designed to have an opinionated (hard coded) workflow, or a configurable one that comes with a sensible default. Thoughts on this?
21:43:06 <devkulkarni> if the spec can be quickly drafted I am okay. but datsun180b might be quicker with the code I guess :)
21:43:25 <datsun180b> my understanding is a finite set of workflows to which any user can build and contribute their own
21:43:27 <devkulkarni> configurable workflows are definitely desirable
21:43:43 <devkulkarni> users might need: build only, build+deploy, deploy only
21:44:05 <datsun180b> or they might need to define a prebuild step, or a report step
21:44:17 <devkulkarni> +1 datsun180b
21:44:21 <datsun180b> and then build workflows to reflect those things
21:44:52 <adrian_otto> so if we have a user with an existing Jenkins based CI that they want to continue using, and they want Solum to initiate that…
21:45:03 <datsun180b> "any user" may need to be restricted to "deployers/operators"
21:45:15 <adrian_otto> we would suggest that be done with the pre-build step/hook?
21:45:42 <ravips> adrian_otto: +1 yeah, instead of creating jenkins LP handler..adding sample mistral dsl for using jenkins, drone or other CI tools from mistral pipeline will definitely help beginners to get on board with solum pipeline feature
21:46:56 <adrian_otto> ravips: what if we wanted to break the dependency on Mistral
21:47:24 <adrian_otto> and just have a hook that's a shell script that has a context of environment variables at runtime
21:47:41 * datsun180b fires crossbow at "shell script"
21:47:58 <adrian_otto> that script could kick off whatever, including Mistral, or anything.
21:48:25 <adrian_otto> s/shell script/user defined command/
21:48:43 <adrian_otto> so if someone wanted to use a script, they could, or invoke any command they want
21:49:01 <ravips> adrian_otto: i thought we are already on board with mistral for pipelines, if not we may focus on good pipeline implementation and can hook other tools from the pipeline
21:49:03 <adrian_otto> (implement a webhook with curl, whatever)
21:49:06 <devkulkarni> isn't that dsl already in place in the form of the plan file?
21:49:46 <adrian_otto> ravips: supporting Mistral might not be worth it if nobody wants to use configurable pipelines
21:50:41 <datsun180b> we might make it our business to focus on mistral if we find it meets and exceeds all our wildest configurable workflow dreams
21:50:52 <phiche> sounds like we're missing input from actual users re: configurable pipelines
21:50:52 <datsun180b> and from what i understands, it almost might maybe
21:51:11 <datsun180b> ^understands^understand
21:51:21 <adrian_otto> datsun180b: It does what we need for that
21:51:42 <ravips> adrian_otto: i assumed one size doesn't fit all and need some tweaks/customizations and that will be provided by pipeline feature
21:51:43 <adrian_otto> my own intuition indicated this was something that users would value.
21:51:48 <adrian_otto> but I am second guessing that
21:52:20 <datsun180b> if there's a use case we can certainly build to it
21:52:25 <adrian_otto> ravips: that was my thinking too
21:52:27 <datsun180b> what use is a tool nobody uses
21:53:16 <gpilz> it could look cool
21:53:51 <datsun180b> five minute warning by my reckoning
21:53:55 <phiche> adrian_otto, you mentioned some time ago that it might be possible to get a heat template that would deploy solum?
21:54:27 <adrian_otto> phiche: that's posible.
21:54:35 <adrian_otto> the trick is actually deploying OpenStack
21:54:49 <phiche> If it's possible to get that, I would be happy to give my input regarding workflows and configuration options
21:54:50 <adrian_otto> so if you already have a working OpenStack, then adding SOlum to that is rather easy
21:55:01 <phiche> we already have icehouse running
21:55:12 <phiche> we have a public cloud
21:55:36 <ravips> phiche: that will be very helpful
21:55:56 <adrian_otto> then we should look at that.
21:56:22 <phiche> I would be happy to test it out
21:56:38 <adrian_otto> ok, I will make a wishlist task for that now.
21:57:10 <phiche> I work primarily implementing CI/CD pipelines for customers, so I have some perspective on these things
21:57:48 <devkulkarni> phiche: cool.. would be great if you can share some findings from that.
21:58:02 <adrian_otto> https://bugs.launchpad.net/solum/+bug/1417782
21:58:08 <phiche> would be happy to
21:58:23 <roshanagr1> phiche: I am interested in hearing that as well
21:58:25 <devkulkarni> thanks adrian_otto
21:58:27 <adrian_otto> phiche: I suggest subscribing to that bug
21:58:34 <adrian_otto> time to wrap up
21:58:55 <devkulkarni> ok.. ending the meeting
21:59:03 <adrian_otto> Our next meeting is 2015-02-17 at 2200 UTC
21:59:09 <adrian_otto> devkulkarni will chair.
21:59:22 <devkulkarni> thanks everyone.. sorry about the confusion today adrian_otto
21:59:29 <devkulkarni> #endmeeting