21:01:46 <adrian_otto> #startmeeting Solum Team Meeting
21:01:48 <openstack> Meeting started Tue Jan 27 21:01:46 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:51 <openstack> The meeting name has been set to 'solum_team_meeting'
21:02:15 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-01-27_2100_UTC Our Agenda
21:02:19 <adrian_otto> #topic Roll Call
21:02:27 <adrian_otto> Adrian Otto
21:02:32 <muralia> murali allada
21:02:33 <mkam> Melissa Kam
21:02:35 <datsun180b> Ed Cranford
21:02:39 <devkulkarni> devdatta kulkarni
21:02:43 <roshanagr1> Roshan Agrawal
21:02:48 <gpilz> Gilbert Pilz
21:02:49 <james_li> james li
21:03:23 <adrian_otto> it's good to see all of you!
21:04:10 <datsun180b> full house today?
21:05:13 <adrian_otto> I think we have a quorum
21:05:20 <adrian_otto> #topic Announcements
21:05:27 <dimtruck> Dimitry Ushakov
21:05:36 <adrian_otto> welcome dimtruck
21:05:46 <akshayc> Akshay Chhajed
21:05:55 <dimtruck> thanks!
21:05:58 <adrian_otto> adrian_otto away on 2015-02-17 for family vacation. I will be travelling. Should we skip our team meeting that day, or assign a pro-tem chair?
21:06:25 <dimtruck> i volunteer devkulkarni so that we can keep going :)
21:06:29 <datsun180b> second
21:06:30 <devkulkarni> sounds good to me
21:06:35 <adrian_otto> hah, ok
21:07:07 <adrian_otto> #agreed we will meet on 2015-02017 with @devkulkarni as our chair during adrian_otto's planned absense
21:07:27 <adrian_otto> #topic Review Action Items
21:07:48 <adrian_otto> so, with respect to Mistral, it turns out that there is a tagged release that we might be able to pin to:
21:07:58 <akshayc> ohh ok….
21:08:05 <adrian_otto> #link http://tarballs.openstack.org/mistral/mistral-2015.1.0b1.tar.gz Most Recent Mistral Release
21:08:47 <adrian_otto> we could download that bundle from that URL, and have confidence that our mistral functionality will remain working regardless of changes int he mistral codebase
21:09:08 <adrian_otto> can anyone think of any reason why this would not solve our concern?
21:09:27 <adrian_otto> If not, I can open a bug ticket for this, and consider this action item resolved.
21:09:34 <datsun180b> sounds good to me
21:09:35 <akshayc> we will have to change our build
21:09:44 <akshayc> generally we clone from repo
21:09:57 <adrian_otto> yes, that would need to be adjusted
21:10:09 <akshayc> moving to newer version would have to manual too
21:10:10 <adrian_otto> so it instead uses the content of this tarball
21:10:16 <adrian_otto> yes
21:10:44 <adrian_otto> and if we find that users of Solum like using the Pipeline resource to do custom workflows, then it makes sense to see about leveraging newer features
21:11:19 <akshayc> ok
21:11:55 <adrian_otto> another approach might be to use the nightly tarball from http://tarballs.openstack.org/mistral/mistral-2015.1.0b1.tar.gz by default, and have a way to easily change that to another one if that becomes problematic.
21:12:03 <adrian_otto> but that can be discussed in the bug ticket
21:12:40 <akshayc> we could try that…. but good to have a known stable…..
21:12:54 <akshayc> in that case we could use the earlier tarball
21:13:00 <adrian_otto> #action adrian_otto to open a bug ticket to allow for pinning mistral to a version that is known to pass gate.
21:13:34 <adrian_otto> #topic Same-host check for plans
21:13:44 <adrian_otto> Excerpt from #solum from datson180b: 1. if we only want same-host plans, why not just switch to a name-or-uuid scheme for plans 2. if we accept planfiles from elsewhere (how can we refer to plans that don't live in our db?) then why bother registering the plans ahead of time at all since the first thing to be done is to parse that planfile into a plan. The way i see it either that same-host check needs to go or
21:13:56 <datsun180b> wahey that's me
21:14:17 <adrian_otto> sorry for the incorrect spelling of datsun180b
21:14:22 <datsun180b> nbd
21:14:30 <adrian_otto> gpilz: I am interested in your input on this topic
21:14:45 <gpilz> why can't we support both?
21:15:30 <gpilz> so you can create an assembly from either a local plan or a remote plan
21:15:34 <adrian_otto> I think that the name of a plan obviously needs to be in our Solum database, but the URI for fetching it should be allowed from elsewhere if the site configuration allows for it
21:15:45 <gpilz> if local you can use a (local) URI or, as a shortcut, just the UUID
21:15:49 <datsun180b> so once it's fetched, where's it live?
21:15:52 <adrian_otto> we should not have a hard coded prohibition of remotely hosted plan resources.
21:15:56 <datsun180b> #link https://bugs.launchpad.net/solum/+bug/1401272
21:15:59 <datsun180b> btw
21:16:15 <gpilz> locally
21:16:18 <gpilz> you make a copy
21:16:30 <gpilz> hmmmm
21:16:39 <datsun180b> that's what POST http://solum/plans/ is for
21:16:40 <adrian_otto> #link https://bugs.launchpad.net/solum/+bug/1401272 Assembly creation with plan uuid
21:17:04 <adrian_otto> that will need to be resolved, and allow creation by uuid prior to solving the remote plan question
21:17:21 <datsun180b> i don't think anyone will complain about being able to create assemblies in one step though so there's that
21:17:39 <datsun180b> technically we only do creating by uuid at present anyway
21:17:47 <datsun180b> we just require that the uuid look like a uri
21:18:03 <gpilz> I'm sort of torn between what is logically possible and what is generally practical (wish Alex H were here)
21:18:04 <adrian_otto> but yes, in general you fetch the plan, extract the relevant bits, and store them in solum as a plan resource
21:18:12 <akshayc> we will also need some way of versioning, if we have a remote plan….
21:18:25 <akshayc> some update which may not work
21:18:33 <datsun180b> plans are required to bear a version key at the top level
21:18:48 <gpilz> we need to be careful to distinguish between plan *files* and plan *resources*
21:18:54 <datsun180b> gpilz: +1000
21:19:01 <adrian_otto> agreed!
21:19:02 <datsun180b> i think that's where the confusion starts
21:19:09 <adrian_otto> plan files should eb allowed remotely
21:19:15 <adrian_otto> plan resources are local.
21:19:20 <gpilz> fetching a plan *file* from a remote location should be no different than POSTing the contents of the plan file in the message body
21:19:25 <gpilz> adrian +1
21:19:26 <adrian_otto> +1
21:19:31 <datsun180b> i'm looking to add an update function to plans so they can be piecemeal changed as needs change
21:19:52 <datsun180b> soon (tm)
21:20:16 <adrian_otto> datsun180b: an ideal architecture for that is to have a history structure so you can walk through previous versions as well
21:20:25 <datsun180b> sure
21:20:31 <adrian_otto> that could be implemented on an SCM for simplicity of implementation
21:20:34 <gpilz> datsun180b - I recommend HTTP PATCH with a JSON Patch payload
21:20:40 <gpilz> i've got that working in my latest update
21:20:44 <datsun180b> nice
21:20:52 <adrian_otto> but you'd need a resource for history of those artifacts, as well as a pointer to the current one
21:20:59 <datsun180b> the alternate would be PUT i'd think
21:21:21 <adrian_otto> that way references to entities created from a previous version can continue to reference what they were derived from
21:21:34 <gpilz> PUT processing is, in my opinion, much harder to implement
21:22:20 <akshayc> would references like com.openstack/solum:latest or localhost/solum:latest work?
21:22:26 <akshayc> similar to docker?
21:22:39 <akshayc> _similar_
21:22:52 <adrian_otto> that's called a weak relation
21:22:54 <datsun180b> so it sounds like the same-host requirement for plans should go, and in doing so we should actually _parse_ the contents of the provided document as a planfile
21:23:03 <adrian_otto> and that's generally a bad idea
21:23:31 <akshayc> ok….
21:23:32 <adrian_otto> I'd much rather have explicit references in an application model.
21:23:55 <adrian_otto> you can use weak relations for things like the launch environment for an app when you know it will not matter
21:24:09 <adrian_otto> but not in a REST model for expressing the metadata about an app
21:24:14 <akshayc> ok….
21:24:52 <adrian_otto> ok, so it seems we have enough alignment on this to carry this discussion on in the contest of bug comments
21:25:05 <adrian_otto> should we move along, or is there more to cover on this topic?
21:25:15 <datsun180b> i think that bug should ascend to a feature
21:25:15 <adrian_otto> s/contest/context/
21:25:42 <adrian_otto> yes, it will be a task marked as Importance = wishlist
21:26:02 <adrian_otto> and thus will not be considered a defect.
21:26:11 <datsun180b> sounds good to me
21:26:33 <adrian_otto> thanks for raising the flag on this one, datsun180b
21:26:52 <datsun180b> credit goes mainly to mkam, glad we could get it into the sunshine
21:27:06 <adrian_otto> thanks mkam!
21:27:14 <adrian_otto> #topic Plan to get Ravi's Bash-to-Python code in mainline tree
21:27:22 <adrian_otto> Current status is available in the comments of https://bugs.launchpad.net/solum/+bug/1302552
21:27:24 <mkam> :)
21:27:28 <adrian_otto> thoughts/remarks on this?
21:27:35 <devkulkarni> so recently ravips and I had a chat about this..
21:27:55 <devkulkarni> the latest on this is that — the code is kind of there.. but it needs to be rebased and tested
21:28:09 <devkulkarni> ravips does not have enough time to continue this at the moment.
21:28:13 <devkulkarni> this is valuable work
21:28:16 <datsun180b> agreed
21:28:30 <adrian_otto> the referenced reviews are abandoned due to inactivity
21:28:32 <devkulkarni> so we need some volunteer(s) to move this work forward
21:28:36 <devkulkarni> right
21:28:37 <datsun180b> the sooner we can pull those scripts into native code the better
21:28:53 <muralia> +1
21:29:07 <devkulkarni> just wanted to bring it for today's discussion to see if any of
21:29:08 <adrian_otto> does anyone have a few cycles to apply to this pursuit?
21:29:11 <datsun180b> do we need to break it into smaller and lower-hanging steps that can be done incrementally?
21:29:22 <devkulkarni> our new contributors want to help us on these patches
21:29:31 <muralia> I can probably jump in and help in 2 weeks
21:29:34 <datsun180b> because "completely refactor and translate the business end of our project's hammer" is daunting
21:29:35 <akshayc> i will give it a shot
21:29:42 <devkulkarni> datsun180b: ravips has outlined steps that need to be completed
21:29:46 <adrian_otto> akshayc: excellent!
21:29:56 <devkulkarni> akshay: great
21:30:01 <datsun180b> cool then
21:30:11 <devkulkarni> feel free to ping me to chat about the current state of the work on the patches
21:30:22 <devkulkarni> also please feel free to reach out to ravips
21:30:24 <datsun180b> you know you can ask us anything in #solum, we'll do everything we can to help you
21:30:29 <akshayc> i will take a look
21:30:35 <adrian_otto> akshayc, please visit https://bugs.launchpad.net/solum/+bug/1302552 and claim it as yours
21:30:35 <devkulkarni> thanks akshayc!
21:30:36 <akshayc> ya, sure
21:30:40 <akshayc> np ;)
21:30:47 <adrian_otto> and if there is guidance we can offer, you, please let us know
21:31:04 <akshayc> yep… i will reach out
21:31:09 <adrian_otto> perfect.
21:31:10 <akshayc> devkulkarni: ok
21:31:19 <adrian_otto> #topic Blueprint/Task Review
21:31:37 <adrian_otto> are there tasks or features that can benefit from team discussion today?
21:31:43 <gpilz> https://review.openstack.org/#/c/147652/
21:31:50 <datsun180b> apparently there's a fire underneath you needs putting out
21:32:00 <gpilz> I don't understand what state this is in
21:32:15 <adrian_otto> that review is actionable
21:32:32 <adrian_otto> is there any reason we would not want to merge that right now?
21:32:33 <datsun180b> oh you can ignore raxpaasci, he's confused and is being attended to presently
21:32:51 * adrian_otto shows raxpaasci the back of his hand
21:32:59 <datsun180b> +2+A'd
21:33:02 <gpilz> there is no reason that i know of why this shouldn't be merged
21:33:20 <adrian_otto> ok, merge is pending, thanks datsun180b
21:33:37 <gpilz> awesome
21:33:38 <adrian_otto> gpilz: LMK if that gets stuck for any reason, and I can help bird dog it through
21:33:40 <datsun180b> now to watch it brave The Gauntlet
21:33:53 <adrian_otto> any other work items for discussion today?
21:34:19 <adrian_otto> #topic Open Discussion
21:34:29 <adrian_otto> I wanted to thank all of you for voting in our election
21:34:50 <adrian_otto> our mission of amending the bylaws was accomplished.
21:34:56 <datsun180b> cool
21:35:18 <adrian_otto> we also have a new raft of directors on the OpenStack BoD
21:35:55 <adrian_otto> so I'm inspired to see how effective they will be now that we have unclogged a bylaws log jam
21:36:46 <adrian_otto> The OpenStack Summit in Vancouver is coming up in a few months
21:37:02 <akshayc> do stackforge projects come directly under openstack umbrella now?
21:37:07 <adrian_otto> so if there is any chance you will attend, you may want to begin planning for that
21:37:22 <adrian_otto> akshayc: good question
21:37:32 <datsun180b> oh that's right, we're almost out of january again
21:37:38 <adrian_otto> projects like this one are expected to become part of the openstack project namespace
21:37:52 <adrian_otto> but there is no expectation of making it part of the integrated release tag
21:38:09 <akshayc> ok….
21:38:26 <adrian_otto> the details of those discussions remain ongoing, as joint work between the OpenStack Technical Committee (TC) and the BoD
21:38:58 <adrian_otto> there are technical concerns, and trademark concerns to rationalize with the new governance process
21:39:17 <akshayc> ok….
21:40:03 <adrian_otto> the direction is not under dispute, only some details
21:40:27 <adrian_otto> if you care about the trademark ramifications, you are encouraged to join the DefCore subcommittee of the BoD. Anyone can participate.
21:40:57 <akshayc> are we (solum) planning something for the summit?
21:40:58 <adrian_otto> if you care about the technical implications, you are encouraged to join the TC governance meetings to share your views
21:41:23 <adrian_otto> akshayc: yes. I am planning to co-present with at least one other of the core group
21:41:53 <adrian_otto> we will be showing new functionality we have added in the last release cycle, and will invite participation from interested developers
21:42:14 <akshayc> ok….
21:42:39 <adrian_otto> I expect we will be in the Design Summit be matter of fact, and we may also be in the main Summit with a session as well
21:42:49 <adrian_otto> if not, then we can release an updated video
21:43:21 <akshayc> hmmm ok…..
21:44:47 <adrian_otto> akshayc: is there a chance you may be using Solum in a production capacity before the Summit?
21:45:45 <adrian_otto> if so, it might be worth proposing a session about your selection of Solum, how you use it, and what other options you considered. Chances are there are others in the OpenStack community who could benefit from what you learned in your evaluation process.
21:46:29 <adrian_otto> I can't remember if there is a Case Studies track, but that would be a good place for a talk like that.
21:46:33 <akshayc> no…. i am individual contributor …. no affiliciations for now
21:46:50 <adrian_otto> ok
21:47:52 <akshayc> case studies would be something good to have
21:48:17 <datsun180b> definitely
21:49:19 <adrian_otto> ok, anything more before we wrap up today?
21:50:25 <datsun180b> call it
21:50:37 <adrian_otto> thanks everyone for attending. Our next team meeting will be 2015-02-03 at 2100 UTC.
21:50:46 <adrian_otto> #endmeeting