16:01:30 <adrian_otto> #startmeeting Solum Team Meeting
16:01:31 <openstack> Meeting started Tue Jul  1 16:01:30 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:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:35 <openstack> The meeting name has been set to 'solum_team_meeting'
16:01:47 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-07-01_1600_UTC Our Agenda
16:01:51 <adrian_otto> #topic Roll Call
16:01:53 <paulmo> Paul Montgomery
16:01:54 <roshanagr> Roshan Agrawal
16:01:56 <adrian_otto> Adrian Otto
16:01:57 <tomblank1> tom blankenship
16:01:57 <datsun180b> Ed Cranford
16:01:57 <noorul> Noorul Islam
16:01:58 <aratim> Arati Mahimane
16:02:00 <muralia> Murali Allada
16:02:02 <ravips> Ravi Sankar Penta
16:02:03 <james_li> james li
16:02:12 <julienvey> Julien Vey
16:02:35 <devkulkarni> Devdatta Kulkarni
16:02:47 <adrian_otto> welcome everyone!
16:03:09 <adrian_otto> #topic Announcements
16:03:10 <datsun180b> we're a big enough team that we'd have a hard time fitting into the same A-Team van now
16:03:13 <stannie42> Pierre Padrixe
16:03:21 <adrian_otto> ;-)
16:03:28 <adrian_otto> It's summer.
16:03:32 <adrian_otto> adrian_otto will be on vacation, and will miss the 2014-07-15 and 2014-07-22 team meetings. Tom Blankenship (tomblank1) has agreed to act as interim chair for those meetings.
16:04:02 <adrian_otto> I will be working a little while I'm away, so if something important is happening, email me.
16:04:30 <roshanagr> good vacations, Adrian
16:04:32 <adrian_otto> The exact dates are July 11-24.
16:04:56 <datsun180b> sounds like fun
16:05:07 <adrian_otto> other announcements from team members?
16:05:26 <adrian_otto> I ahve one more
16:05:41 <adrian_otto> we now have a calander feed for team meetings
16:05:48 <adrian_otto> an ical calendar
16:06:23 <adrian_otto> if you want "normal" calendar invites, for notices about cancellations, etc, let me know by PM that you want to be invited to the meetings
16:06:33 <adrian_otto> otherwise, you are welcome to subscribe to the feed.
16:06:44 <adrian_otto> I will send a link to the feed URL to the ML, because I don't have it handy.
16:06:52 <adrian_otto> other announcements?
16:07:03 <adrian_otto> ok, let's dive in.
16:07:09 <adrian_otto> Review Action Items
16:07:12 <adrian_otto> #topic Review Action Items
16:07:20 <adrian_otto> devkulkarni to work with adrian_otto to document the LP development approach in BP+task+wiki to clearly outline our approach, and how it solves each use case. (COMPLETE)
16:07:30 <adrian_otto> we have a spec in review for this now
16:07:39 <adrian_otto> devkulkarni: do you have a link for that handy?
16:07:44 <devkulkarni> https://review.openstack.org/#/c/103689/
16:07:59 <roshanagr> I have a question on the custom language pack approach
16:08:13 <adrian_otto> #link https://review.openstack.org/#/c/103689/ Custom Language Pack Spec
16:08:30 <devkulkarni> roshanagr: listening
16:08:32 <adrian_otto> roshanagr: proceed
16:08:34 <roshanagr> will it support source code to build specification, for example if an app develper wants to write custom language pack for C++
16:08:53 <devkulkarni> roshanagr: yes, it will.
16:09:05 <devkulkarni> app developer would provide a Dockerfile with g++ installation instructions
16:09:22 <roshanagr> devkulkarni: good. just wanted to confirm.
16:09:24 <datsun180b> haha, i still have a word in my highlights
16:09:48 <roshanagr> the spec needs to call it out though
16:09:48 <adrian_otto> ok, I need to glance to confirm if we had other action items
16:10:11 <devkulkarni> do it swiftly ;)
16:10:15 <adrian_otto> nope, that one was the only one
16:10:40 <adrian_otto> #topic Review Tasks
16:10:49 <adrian_otto> #link https://launchpad.net/solum/+milestone/juno-2 Juno Development Tasks
16:11:02 <adrian_otto> Private git repo integration (ravips)
16:11:14 <adrian_otto> •	#link https://blueprints.launchpad.net/solum/+spec/support-private-github-repos Private Repo Blueprint
16:11:14 <adrian_otto> •	#link https://bugs.launchpad.net/solum/+bug/1319604 Private Repo Feature Task
16:11:16 <uvirtbot> Launchpad bug 1319604 in solum "Improvement: Add support for private GitHub repos" [Wishlist,Triaged]
16:11:25 <adrian_otto> ravips: could you update us on this?
16:11:46 <ravips> sure, I have implemented the task last week..need to do some more testing
16:12:00 <ravips> I will submit code or review sometime today or tomorrow
16:12:02 <adrian_otto> do you have a WIP review?
16:12:22 <adrian_otto> ok, so one ask from the team, we would like visibility into code that you are working on
16:12:30 <adrian_otto> even if it's not merge quality yet
16:12:41 <adrian_otto> you can mark it as workflow-2
16:12:44 <ravips> I don't have yet but I can create one now
16:12:48 <adrian_otto> and put WIP in the subject
16:13:06 <adrian_otto> and we can get some perspective into your current work, and potentially help you with steering
16:13:34 <adrian_otto> that way we get better clarity early, and potentially less rework if the approach is questioned by the team
16:13:44 <adrian_otto> or if maybe you need any guidance that we may be able to help with
16:13:46 <adrian_otto> ok, thanks.
16:13:56 <adrian_otto> Other questions on this from the team?
16:14:01 <ravips> yes, I agree..will create WIP for review
16:14:50 <adrian_otto> thanks ravips
16:15:33 <adrian_otto> Are there other work tasks that team members would like to request updates for? I will cover the high level topic of Pipelines in a moment when we get to BP review (I will switch the order of this in the agenda for future meetings)
16:16:01 <devkulkarni> any updates on chained trusts?
16:16:15 <adrian_otto> Chained trusts (julienvey, asalkeld)
16:16:20 <noorul> Is there a hard rule that a spec should be approved before submitting code?
16:16:25 <PaulCzar_> sorry I’m late!  team standup stuff
16:16:41 <adrian_otto> noorul: you can submit WIP code against a spec review.
16:17:10 <devkulkarni> noorul: I don't think we should put a hard rule for spec approval before submitting code. It will slow down our development..
16:17:12 <adrian_otto> but if a spec is still under discussion, we should not merge associated code without consensus on the design
16:17:17 <julienvey> they discussed chained trust in heat team meeting today
16:17:37 <julienvey> they have the same issues with Heat -> Ceilometer
16:17:44 <julienvey> So they are actively working on it
16:18:00 <adrian_otto> julienvey: is there anything that Solum team can do to help?
16:18:21 <julienvey> angus is already helping them
16:18:45 <adrian_otto> julienvey: ok, thanks for the update.
16:19:11 <adrian_otto> julienvey: one question… do you feel that we are close to completion there, or is there a lot of work remaining?
16:19:43 <adrian_otto> asalkeld indicated last week that he thought it was close. I just wanted to see if that's still our perception.
16:20:09 <julienvey> it seems there is still some work :(
16:20:31 <adrian_otto> and that's work in Keystone, right?
16:20:34 <julienvey> but angus might know more than I do
16:20:46 <julienvey> both keystone and heat
16:20:59 <adrian_otto> ok
16:21:12 <julienvey> https://review.openstack.org/#/c/99908/
16:21:35 <devkulkarni> julienvey: thanks for the link
16:22:19 <adrian_otto> #link https://review.openstack.org/99908 Spec for trusts redelegation
16:22:25 <noorul> adrian_otto: What is the reason for abandoning https://review.openstack.org/#/c/101019/ ?
16:22:34 <adrian_otto> I encourage Solum reviewers to take a look at that, and provide input
16:23:29 <adrian_otto> noorul: the 101019 was a duplicate of one that julienvey posted
16:23:43 <adrian_otto> I should have put the link to it in my abandon message, sorry.
16:24:12 <noorul> more over the bp should be updated
16:24:28 <adrian_otto> I can do that right now
16:25:28 <adrian_otto> ok, BP updated.
16:26:12 <noorul> adrian_otto: Thank you!
16:26:22 <adrian_otto> #tpic Blueprint Discussion
16:26:28 <adrian_otto> #topic Blueprint Discussion
16:26:31 <julienvey> the reason was given in a previous comment
16:26:39 <adrian_otto> Subject: Pipelines
16:27:18 <adrian_otto> So, as our reviewers have notice, we have a log jam in our review queue
16:27:30 <adrian_otto> lots of code that relies on mistral, but none of our gate tests pass.
16:27:39 <adrian_otto> I want to explain why this is happening, and how we will solve it
16:27:58 <adrian_otto> we are listed in openstack/requirements/projects.txt
16:28:12 <adrian_otto> This means that we use the same requirements as OpenStack
16:28:45 <adrian_otto> the reason for this is so Solum can be installed on the same servers as OpenStack, and conflicting requirements form pypi will not cause us to break OpenStack
16:29:26 <adrian_otto> the way this protection works is that openstack mirrors the content in pypi that is listed in openstack/requirements/global-requirements.txt
16:29:52 <adrian_otto> if the library is not in the list, you can not use it, and can not pass gate… as long as your project is listed in projects.txt
16:30:13 <adrian_otto> so, I submitted a review asking for python-mistralclient to be added to that list.
16:30:28 <adrian_otto> that ended up with a -2
16:30:53 <adrian_otto> I also proposed reviews for changing the way the mirroring works for stackforge projects.
16:31:21 <adrian_otto> I ended up abandoning those reviews in favor of adding python-mistralclient to global-requirements.txt
16:31:42 <adrian_otto> following this so far? The good news is coming in a moment.
16:31:53 <devkulkarni> :) .. what is it?
16:32:25 <PaulCzar_> holding my breath with anticipation!
16:32:28 <adrian_otto> Monty Taylor (morgred) contacted me yesterday and explained a plan to enhance openstack-ci for stackforge projects
16:32:39 <adrian_otto> they worked on it over the weekend
16:33:09 <adrian_otto> it would allow us to stay in projects.txt, and we would not need to submit anything for review to use it from pypi
16:33:23 <adrian_otto> we could add anything we want to our own projects.txt and use it
16:33:49 <devkulkarni> so this is similar in spirit to stackforge-requirements.txt that you had proposed?
16:33:50 <adrian_otto> the solution works by mirroring *all* of pypi.python.org on pypi.openstack.org
16:34:01 <adrian_otto> devkulkarni: yes, it's the functional equivalent of that
16:34:19 <datsun180b> _any_thing on pypi.python you say
16:34:20 <adrian_otto> there is a downside that I would like you all to think about
16:34:51 <adrian_otto> I will do my best to explain my concern, and ask you for your creativity to address it
16:34:57 <noorul> I remember doing this https://review.openstack.org/#/c/80980/
16:35:13 <adrian_otto> the reason for locking OpenStack projects to a fixed list of requirements is so they all work together
16:35:38 <adrian_otto> Say openstack projects use requirements A-D
16:35:45 <adrian_otto> and we ask for requirement E
16:35:53 <adrian_otto> and that loads requirements F-H
16:36:08 <adrian_otto> and an *incompatible* version of requirement A
16:36:50 <adrian_otto> so that Openstack breaks when it starts because requirement A has broken it
16:37:04 <adrian_otto> what options can we think of to mitigate this risk?
16:37:18 <adrian_otto> My initial thinking here is that we should find a way to test for that
16:38:11 <PaulCzar_> adrian_otto: functional test gates would test that by default simply because devstack will fail … right ?
16:38:19 <adrian_otto> but is there a better solution? Maybe something that compares the global-requirements.txt and our requirements.txt and the state of what the pypi tool loaded compared to those?
16:38:32 <adrian_otto> PaulCzar_: yes, for bits of OpenStack that we use
16:38:45 <adrian_otto> but let's say for example that we do not use Cielometer, but we break it
16:38:56 <adrian_otto> how can we avoid that situation?
16:39:13 <julienvey> let's just be carefull with the new requirements we approve for merge
16:39:37 <devkulkarni> actually that brings another issue.. lets say we use something which is not approved yet by openstack-infra
16:39:52 <datsun180b> we might figure out a way to build a venv that pulls in all the requirements, and then compares freeze to make sure all the OS requirements are still met
16:39:53 <devkulkarni> when it comes to incubation we would have to rewrite our stuff
16:39:58 <PaulCzar_> but isn’t that handled by having all the important stuff in global requirements from oslo ?   install global-requirements first, then try to install our requirements …  fail if can’t.    that’s probably doable in tox with a virtualenv
16:40:08 <devkulkarni> or do we that time try to get our libraries into global-requirements?
16:40:14 <datsun180b> just in case there's a conflict up the chain
16:40:49 <adrian_otto> PaulCzar_:  I learned something about pypi yesterday
16:41:12 <adrian_otto> let's say that global requirements call for foo >= 1.2
16:41:33 <adrian_otto> and we require bar => 1.0, which in turn requires foo >= 1.3
16:41:42 <adrian_otto> and foo 1.3 works for us, but not for openstack
16:41:53 <adrian_otto> pypi would allow that.
16:42:16 <adrian_otto> it does not necessarily insist that you have the most recent version of something
16:42:34 <datsun180b> so long as you're between the goalposts
16:42:41 <adrian_otto> and if the gate job hosts have a copy of foo 1.2 on them, then openstack gate jobs will not bother to load 1.3
16:42:47 <devkulkarni> seems like correct behavior on pypi's part
16:43:17 <PaulCzar_> adrian_otto: I see similar issues all the time with rubygems.  it’s up to the individual projects to be specific enough about their versions that that can’t happen
16:43:20 <adrian_otto> so I'd like you all to think on this a bit
16:43:27 <adrian_otto> I'm tempted to just accept the risk and move on
16:43:31 <paulmo> Could we parse the full dependency tree and identify version conflicts at the start of the gate?
16:43:37 <PaulCzar_> i.e.  global-requirements *should* say  foo >= 1.2, foo < 1.3
16:43:40 <datsun180b> risk is worth being able to use mistralclient
16:43:45 <adrian_otto> but if any of you think of a clever way to deal with this… awesome
16:43:56 <adrian_otto> PaulCzar_: exactly
16:43:58 <datsun180b> we can administer our own wrist-slaps when we break our gate or env
16:44:05 <adrian_otto> it's the unknown incompatibility situation
16:44:38 <datsun180b> well it's not our fault if bar's requirement is foo==1.2 and not foo>=1.2 like they claim
16:44:59 <adrian_otto> idea… what if we had a post-merge CI job that wold run a full integration test of OpenStack on the built host after setting up our own requirements?
16:45:00 <PaulCzar_> datsun180b: doesn’t matter who’s fault …we just want to keep shit working
16:45:24 <datsun180b> fair enough
16:45:29 <noorul> Maybe mistral should also move to be part of projects.txt
16:45:51 <PaulCzar_> adrian_otto: sounds reasonable …  basically do a full tempest run post-merge ?
16:45:56 <adrian_otto> noorul: that would not solve the current concern, but it would be wise for them to do.
16:45:59 <devkulkarni> why post-merge?
16:46:13 <adrian_otto> post merge because we don't want it to slow us down
16:46:26 <noorul> adrian_otto: in that csae we can rely on their pypi package
16:46:26 <PaulCzar_> devkulkarni: takes a long time!   doesn’t need to be addressed immediately,  as long as its before a release is cut
16:46:27 <adrian_otto> that full integration test might take a really long time, and is not giving us direct value
16:46:44 <adrian_otto> PaulCzar_: ++
16:46:45 <noorul> adrian_otto: we can assume that it will definitely run well on openstack
16:47:21 <adrian_otto> ok, we have a few more agenda items to touch on
16:47:28 <adrian_otto> so please continue to think on this
16:47:34 <devkulkarni> how will it still tell us if we are breaking projects that we don't have tempest tests for?
16:47:39 <devkulkarni> okay
16:47:54 <adrian_otto> (ed-cranford/datsun180b): Spec repo: put mock request/responses at top of document
16:48:10 <datsun180b> oh that
16:48:43 <datsun180b> i've been working on a spec of my own and after writing a short novella i realized all that prose was for nothing without some hard examples to start thinking about
16:49:12 <datsun180b> so i wanted to suggest some kind of Proposed Request/Response section and put it pretty far north in the spec
16:49:24 <adrian_otto> datsun180b: should we update the spec template to put a placeholder for examples
16:49:32 <datsun180b> that's what I'm suggesting
16:49:49 <adrian_otto> fine with me. Other thoughts?
16:49:55 <datsun180b> obviously we already can put them in the document in a relevant section, and not every spec will need it
16:50:17 <datsun180b> maybe lock down a specific format to denote that the proposal is essentially a diff
16:50:29 <datsun180b> for example, adding a field to an extant response
16:51:07 <datsun180b> can't think of anything clearer than +/- prefixes like diff again
16:51:20 <adrian_otto> you could include a link to a WIP that you intentionally abandon
16:51:45 <datsun180b> the gate wards would never go for that
16:52:18 <adrian_otto> let's experiment with it a bit to get some practical examples of where this worked well
16:52:32 <adrian_otto> so maybe you try it out in yours
16:52:58 <adrian_otto> and submit a review against the template for a placeholder for that, using your spec as an example justifying the change.
16:52:59 <datsun180b> re some recent dev list talk, it might also help as a litmus test for "maybe you don't need a spec for that after all"
16:53:09 <datsun180b> i can do that
16:53:16 <adrian_otto> right
16:53:23 <devkulkarni> about not requiring spec for everything..
16:53:32 <devkulkarni> there is an ongoing discussion on the ML about it
16:53:32 <adrian_otto> if you can fully convey the concept in a crisp diff, then a spec may be overkill
16:53:55 <adrian_otto> but if what you want to do requires explanation beyond what fits nicely in a patch… then a spec makes sense.
16:54:00 <datsun180b> basically what i'm trying to do is weasel out of having to understand these reviews before i rubberstamp them all +1 /s
16:54:23 <adrian_otto> I will pretend I did not see that
16:54:39 <devkulkarni> me too!!
16:54:40 <noorul> adrian_otto: +1
16:54:41 <datsun180b> slash-s is sarcasm
16:54:50 <devkulkarni> :)
16:54:51 <adrian_otto> aha
16:55:08 <adrian_otto> thanks datsun180b. Anything further on this topic?
16:55:25 <datsun180b> no, thanks. my motivation is clarity through brevity in our specs
16:55:33 <adrian_otto> #topic Open Discussion
16:55:59 <noorul> julienvey: Do you think build fram should be discussed?
16:56:21 <julienvey> noorul: I don't have much to say since last week
16:56:40 <julienvey> some specs in review
16:56:46 <paulmo> Just noting that I created a Mistral DSL and Heat template parser which can pull in all required user input necessary to run a Mistral Execution.  I'll put a WIP in the horizon plugin repo shortly.  Might be handy for the control plane as well.
16:56:50 <noorul> Oops I have to read those logs
16:57:17 <PaulCzar_> I’ve put in a bit of thought on becoming friendlier for new users ( in any persona ) and started to throw together a spec for it  - https://review.openstack.org/#/c/103937/2/specs/juno/new_users.rst
16:57:42 <PaulCzar_> some of the stuff I’ve suggested might be contraversial like having a Vagrantfile and Dockerfile in the main solum repo
16:58:16 <PaulCzar_> it’s marked WIP right now,  but I’d like to open discussion over some of it
16:58:18 <devkulkarni> Btw that reminds me of something we had discussed before.. wasn't there supposed to be a contributors.txt or something?
16:58:48 <julienvey> PaulCzar_: I can't access https://github.com/rackerlabs/cookbook-openstack-solum
16:58:52 <noorul> devkulkarni: and consensus was to to not have one
16:59:09 <devkulkarni> noorul: oh okay. did not remember what was the decision
16:59:16 <devkulkarni> same here PaulCzar_
16:59:44 <datsun180b> that's because it's not -solum it's -paas
17:00:02 <datsun180b> https://github.com/rackerlabs/cookbook-openstack-paas how now
17:00:04 <PaulCzar_> yeah -paas …
17:00:08 <devkulkarni> #link https://github.com/rackerlabs/cookbook-openstack-paas
17:00:21 <adrian_otto> thanks everyone
17:00:25 <adrian_otto> catch you next week
17:00:29 <adrian_otto> #endmeeting