20:03:05 <ttx> #startmeeting tc
20:03:06 <openstack> Meeting started Tue Apr 14 20:03:05 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:10 <annegentle> \o/ on tippie toes
20:03:10 <openstack> The meeting name has been set to 'tc'
20:03:14 <ttx> Our agenda for today:
20:03:19 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:36 <ttx> #topic Asking permission to dedicate the Kilo release to the memory of Chris Yeoh
20:03:46 <ttx> So... In the release announcement I was personally planning to dedicate the Kilo release to the memory of Chris (something like "I'd like to dedicate...")
20:03:56 <ttx> But if the Technical Committee agrees, we can formally dedicate this release (and therefore use "the Kilo release is dedicated to..." in announcement *and* release notes)
20:04:00 <mikal> I would like to see this happen
20:04:01 <ttx> How does that sound ?
20:04:06 <markmcclain> +1
20:04:06 <sdague> ttx: +1
20:04:07 <anteaya> ++
20:04:09 <russellb> +1
20:04:17 <dhellmann> +2
20:04:21 <mordred> o/
20:04:24 <mordred> ++
20:04:27 <annegentle> sounds great
20:04:30 <thingee> +1
20:04:32 <david-lyle> +1
20:04:45 * jhesketh likes this as an onlooker
20:04:49 * dansmith does too
20:04:56 <sdague> ttx: probably worth a roll call vote just to make it official and in the minutes
20:04:58 <ttx> That will probably let the Foundation staff prepare somethign on the website too
20:05:01 <ttx> ok, startvoting
20:05:03 * rockyg likes it though I can't vote
20:05:20 <jeblair> ttx: ++
20:05:27 <annegentle> +1
20:05:34 <ttx> #startvote Should the Kilo release be dedicated to the memory of Chris Yeoh? Yes, No, Abstain
20:05:35 <openstack> Begin voting on: Should the Kilo release be dedicated to the memory of Chris Yeoh? Valid vote options are Yes, No, Abstain.
20:05:36 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:05:38 <russellb> #vote yes
20:05:40 <mordred> #vote yes
20:05:41 <mikal> #vote yes
20:05:42 <dhellmann> #vote yes
20:05:44 <markmcclain> #vote yes
20:05:44 <sdague> #vote Yes
20:05:45 <jeblair> #vote yes
20:05:46 <annegentle> #vote Yes
20:05:46 <jgriffith> #vote yes
20:05:47 <ttx> #vote Yes
20:05:58 * ttx hopes the vote system is case-sensitive
20:06:03 <ttx> insensitive I mean
20:06:07 <mordred> #vote Yes
20:06:10 <sdague> we'll find out in an minute
20:06:13 <devananda> #vote yes
20:06:26 <ttx> ok 30 more seconds
20:07:02 <ttx> #endvote
20:07:03 <openstack> Voted on "Should the Kilo release be dedicated to the memory of Chris Yeoh?" Results are
20:07:04 <openstack> Yes (11): ttx, devananda, annegentle, jeblair, russellb, sdague, jgriffith, mikal, mordred, dhellmann, markmcclain
20:07:14 <ttx> awesome, the vote bot is with us
20:07:19 <mordred> woot
20:07:22 <sdague> \o/
20:07:24 <jgriffith> yay vote-bot
20:07:26 <devananda> nice
20:07:41 <ttx> Awesome, thanks everyone
20:07:45 <ttx> #topic Adding Mistral Workflow Service to OpenStack
20:07:55 <ttx> #link https://review.openstack.org/170225
20:08:07 <ttx> I think... it fits the requirements.
20:08:13 <ttx> My only gripe was about the fragility due to a low bus factor, but that is certainly better described as a team tag (team:bus-factor ?)
20:08:23 <ttx> Thoughts ?
20:08:29 <sdague> I like bus-factor as a tag :)
20:08:38 * jgriffith is sitting this one out as he doesn't quite get the project
20:08:49 <russellb> yeah, i had been meaning to define something around team size ... haven't gotten to it yet
20:08:59 <sdague> so, wasn't there also some recent ML thread about the fact that this and murano can't coexist on the same box
20:09:07 <sdague> even though they are supposed to use each other?
20:09:13 <mikal> Can we avoid the term bus-factor?
20:09:21 <rakhmerov> hi everyone. I'm a PTL of Mistral and you can ask me questions if you have
20:09:22 <russellb> yes
20:09:22 * anteaya wonders why we need a yaml based language when we have yaml
20:09:32 <ttx> jgriffith: I'd describe it as a basic openstack client programming language
20:09:37 <ttx> combined with a cron
20:09:50 <jgriffith> ttx: so I should clarify... I'm struggling to see the point :)
20:10:00 <jgriffith> ttx: errr... value
20:10:05 <mordred> so - I'm +1
20:10:10 <mordred> because there are people who like it
20:10:13 <mordred> and it doesn't hurt anything
20:10:19 <ttx> mordred: right
20:10:20 <mordred> and I don't see any reason to deny it entry
20:10:20 <devananda> is this (just) a service to run taskflow-as-a-service ?
20:10:24 <sdague> jgriffith: so, same, but I'd still be +1, because apparently someone wants it
20:10:31 <jgriffith> mordred: haha... yeah, I forget the low bar :)
20:10:34 <russellb> i just posted the team diversity info to the review if anyone is interested
20:10:40 <mordred> jgriffith: I'm just trying to remind everyone :)
20:10:41 <devananda> russellb: thanks, looking
20:10:44 <dhellmann> how is this different from heat's similar template thing?
20:10:45 * jgriffith refrains from smart a$$ comments
20:10:53 <rakhmerov> devananda, no, it's not taskflow-as-a-service
20:11:06 <mordred> dhellmann: does it matter? we want to encourage competition I hear
20:11:09 <zaneb> anteaya: because YAML doesn't describe how to run workflow, therefore you'll always need some way of interpreting the YAML
20:11:13 <dhellmann> mordred: no, I'm just curious
20:11:15 <mordred> kk
20:11:17 <ttx> I think the Amazonomorphy for it would be Amazon SWF
20:11:30 <ttx> But then they have so many services :)
20:11:36 <russellb> it's complementary to Heat IMO
20:12:03 <russellb> Heat might trigger a workflow defined in Mistral in response to some condition it's watching
20:12:13 <dhellmann> ah, cool
20:12:17 <ttx> Yes, I spent some time looking into it and it feels complementary
20:12:19 <mordred> I have heard people say the thing russellb said
20:12:25 <zaneb> russellb++
20:12:39 <zaneb> and also vice-versa
20:12:47 <russellb> indeed
20:13:10 <mikal> So, what's a sample use case?
20:13:10 <ttx> They also are unquestionably an OpenStack project
20:13:11 <zaneb> so, e.g. Ceilometer alarm triggers a workflow, part of which may be hitting the autoscaling trigger in Heat
20:13:15 <mikal> That might make this clearer for people\
20:13:36 <ttx> mikal: they have plenty of use cases described on their wiki page
20:14:24 <ttx> https://wiki.openstack.org/wiki/Mistral
20:14:39 <jeblair> sdague: it seems like they plan on fixing that during liberty cycle
20:14:47 <zaneb> mikal: one I've heard a lot is: define a workflow that creates a Heat stack, uses the server in it to build an image, upload the image to Glance, then delete the stack again to free resources
20:14:54 <sdague> jeblair: yeh, I'm +1, but I thought it was worth recording
20:15:05 <jeblair> sdague: hopefully they'll adopt g-r...?
20:15:17 <annegentle> mikal: running payroll change jobs quarterly or at bonus time in your OpenStack cloud
20:15:35 <mikal> annegentle: so, that's what I thought it was, but the wiki page doesn't seem to include those soprts of examples?
20:15:42 <dhellmann> jeblair: do we actually have adopting g-r as a requirement now?
20:15:44 <mikal> annegentle: I was actually thiking video transcode for example
20:15:47 <ttx> I see some value in it, and more importantly I don't see any drawback to having it
20:15:58 <jgriffith> Ok... fair enough I suppose
20:16:06 <zaneb> the way I always put it is: Heat models nouns, Mistral models verbs. Both are important, and complementary :)
20:16:09 <jeblair> dhellmann: i don't think we do, but it seems like maybe they might want to
20:16:12 <dhellmann> mikal: https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron
20:16:15 <ttx> Getting some network lag, so please proceed if I suddenly disappear
20:16:21 <dhellmann> jeblair: yeah
20:16:22 <devananda> dhellmann: I don't think it's a requirement to be in the tent, but it probably is from a release perspective
20:16:38 * dhellmann waits for someone to propose a tag...
20:17:02 <jeblair> dhellmann: "Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"  that's the only thing mentioned as a requirement
20:17:14 <ttx> We have 8 YES at this point
20:17:18 <dhellmann> jeblair: yeah, and I think that's really about the GPL, not g-r
20:17:22 <jeblair> dhellmann: i think reading that to mean g-r would be an... expansive... reading of it... :)
20:17:36 <devananda> ttx: 9
20:17:37 <ttx> I'll let the discussion continue for a bit but it already has enough for acceptance
20:17:37 <sdague> dhellmann: honestly, it was mostly just a coordination issue between mistral and murano
20:17:57 <dhellmann> sdague: yeah
20:18:01 <sdague> dhellmann: yes, it's about (A)GPL
20:18:01 <sdague> because we ran into that rstlib issue
20:18:13 <sdague> really late in grizzly
20:19:02 <mordred> that was so much fun
20:19:21 <ttx> really really late
20:19:44 <annegentle> I think we need to acknowledge that increased integration actually hurts.
20:20:01 <rakhmerov> as far as Murano and Mistral compatibility, it's being solved now and will be solved in 1-2 days
20:20:06 <mordred> woot
20:20:19 <ttx> OK, time to close it, unless someone has a definitive argument that (s)he thinks can sway voters completely
20:20:22 <markmcclain> rakhmerov: cool
20:20:41 <dhellmann> rakhmerov: ++
20:20:45 <sdague> ttx: moar rubber stamp!
20:20:50 <ttx> approved
20:20:54 <ttx> jgriffith: more than "doesn't hurt" the philosophy is "it's already an openstack project"
20:21:07 <rakhmerov> thanks!
20:21:49 <jgriffith> ttx: point taken
20:21:54 <ttx> rakhmerov: welcome
20:21:54 <ttx> #topic More Defcore process discussion
20:22:35 <zehicle_> o/
20:22:39 <zehicle_> #link http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst
20:22:47 * rockyg waves from behind zehicle
20:23:33 <zehicle_> mainly here to collect feedback and answer questions
20:23:44 <ttx> #link http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst
20:23:56 <ttx> Last week we postponed the discussion until everyone had a chance to look into the proposed process
20:23:56 <russellb> "A3. PTLs Recommend Changes to Designated Sections"
20:23:56 <ttx> Personally I thought it was disconnected from the bylaws requirements (to build on top of the "tc-approved release")
20:23:57 <ttx> And therefore I proposed the addition of wording to cover that, and it got merged:
20:23:57 <ttx> #link https://review.openstack.org/172417
20:23:57 <ttx> I don't have objections left
20:23:57 <ttx> But you may have
20:23:57 <ttx> zehicle: you around?
20:23:57 <hogepodge> ttx I'm here, and can try to answer any questions.
20:23:57 <ttx> wow, we seem to have weird lag with the bot too
20:23:57 <hogepodge> I'm secretary to the committee, but obvs not on the board (and it's a board committee)
20:24:06 <russellb> I don't think the tech community should have to be responsible for defining that
20:24:07 <zehicle_> ttx, yes
20:24:14 <russellb> that's what we spent lots of time going through last cycle
20:24:20 <russellb> and declined to define
20:24:45 <dhellmann> zehicle_: looking at the timing, I wonder if we'll have tests for all of the capabilities 3 months before the summit (in time to start the preliminary draft) -- I honestly don't know if we're stable enough at that point. How did that work out this cycle?
20:25:00 <ttx> zehicle: don't we essentially rather recommend changes to Capabilities than Designated Sections ?
20:25:10 <ttx> (we as PTLs)
20:25:19 <zehicle_> the goal for DefCore is to be trailing.  not having tests would be a reason to exclude it from consideration
20:25:30 <russellb> basically, I think the TC and/or PTLs should be outside of this as much as possible
20:25:33 <zehicle_> the point is to pick up things that are stable and adopted
20:25:39 <russellb> with the only exception being defining the TC approved release
20:25:48 <jgriffith> Crazy idea... runs the tempest tests same as in gate... done
20:25:55 <ttx> russellb: the way I understand it was inside a project, designated sections can be updated with PTLs opinion
20:26:07 <zehicle_> russellb, that's fine and we've tried to make it like that.  still would like to have you either approve or agree to wave from sidelines
20:26:08 <dhellmann> zehicle_: so no new features of kilo would be included until a later release?
20:26:12 <sdague> dhellmann: the tests today are a pretty small subset of what's in tempest, so I think it's fine. Honestly if something's not getting tested 3 months before release, it's probably not a feature you want to stamp for trademark
20:26:13 <ttx> different from TC listing projects from above
20:26:20 <zehicle_> dhellmann, yes, by definition
20:26:27 <dhellmann> zehicle_: ok, thanks
20:26:29 <russellb> i don't think we should have to agree or approve to using a subset of the code
20:26:54 <russellb> would it be better to submit a patch with my justification in commit message?
20:26:54 <zehicle_> dhellmann, in fact, we intentionally took out the release timing from the process.  it's date specs now
20:27:05 <rockyg> sdague: ++
20:27:11 <dhellmann> russellb: that's the PTLs, right? not the TC?
20:27:12 <zehicle_> russellb, patches strongly encouraged.
20:27:26 <zehicle_> but want to be available to answer questions interactively too
20:27:29 <russellb> dhellmann: "we" as the technical community / technical leadership more generally
20:27:43 <zehicle_> since we want to conclude discussions before we meet f2f in vancouver
20:27:47 <dhellmann> zehicle_: makes sense, I was thinking we were trying to handle features for release X on this schedule, but it's really at most X-1
20:28:03 <zehicle_> dhellmann, yes.
20:28:06 <rockyg> dhellmann: yes
20:28:07 <mordred> sdague: ++
20:28:20 <annegentle> zehicle_: there was a dependency question I had, let me see if I can articulate
20:28:24 <dhellmann> zehicle_: that might be clarified elsewhere, but if not maybe add a note?
20:28:49 <zehicle_> the basic idea is to collect changes & new stuff 3 mos leading up to summits and then have user/vendor review for 3 months after
20:29:24 <dhellmann> zehicle_: I guess I was thrown off by the schedule being based on the summit, but I'll admit to reading this for the first time about an hour ago
20:29:26 <sdague> remember the trigger point here isn't the leading edge either, it's not like having more features in newer openstack takes away your trademark
20:29:26 <annegentle> zehicle_: (mikal too probably knows)
20:29:28 <rockyg> new stuff = stuff that isn't currently in Defcore that lots of folks are using
20:29:45 <zehicle_> annegentle, we found places where we had to choose an order of presentation - either way left you having to read ahead to get an asnwer
20:29:45 <annegentle> zehicle_: if nova tests don't use image v2 api but it's a requirement of defcore, where do I find those tests to test that?
20:29:55 <anteaya> zehicle_: might sound silly, but I'd like a defintion of the terms used in the Lead By table at the top, particularly Community
20:30:28 <zehicle_> anteaya, we do have a lexicon in the repo
20:31:03 <devananda> zehicle_: so in ~August, you would start looking at what was released in Kilo and, if certain features already had wide adoption, possibly propose those changes to the community in November
20:31:23 <anteaya> zehicle_: I don't see an entry for Community: http://git.openstack.org/cgit/openstack/defcore/tree/lexicon.rst though perhaps that is where it should go
20:31:30 <zehicle_> devananda, we'd look at the project as a whole.  new features would be included in that
20:31:32 <devananda> zehicle_: sorry, that should have ended with a ?
20:31:49 <devananda> zehicle_: ok, gotcha
20:31:49 <zehicle_> anteaya, please add!
20:31:53 <mikal> annegentle: I think there is an assumption that defcore will provide tempest tests where they are missing
20:31:55 <rockyg> annegentle: the tests are all listed in a json file, and categorized, so you look for the image v2 category
20:31:58 <anteaya> zehicle_: I don't know what should go there
20:32:01 <mikal> annegentle: that's certainly what they've said to me in the past
20:32:06 <annegentle> mikal: ok
20:32:07 * ttx can testify the process to get changes in is rather straightforward :)
20:32:08 <vishy> o/
20:32:10 <vishy> sorry i’m late
20:32:19 <zehicle_> mikal, no - defcore does not provide tests.  we're limited to what;s there
20:32:32 <zehicle_> we are currently discussion how to take tempests that are outside of tempest too
20:32:33 <russellb> yeah, i'll just post my feedback as a patch, i think that'll be easier
20:32:47 <zehicle_> that's likely a hot topic post Vancouver
20:32:48 <mikal> zehicle_: you have told me in the past that defcore would increase the level of tempest coverage. How can this be true if no tests are added?
20:32:54 <zehicle_> russellb, +1
20:33:02 <zaneb> zehicle_: yeah, that's going to be important
20:33:05 <rockyg> mikal: so if there are no image v2 tests, then that feature would be excluded from the current defcore definition
20:33:06 <hogepodge> mikal add tests to tempest or elsewhere
20:33:11 <zehicle_> mikal, we are creating _incentives_ to increase tests
20:33:15 <devananda> zehicle_: this may be somewhat off topic, so feel free to table it if that's the case: how does moving tempest coverage into each projects' repo affect all this?
20:33:27 <zehicle_> we are not a technical group that can create tests - that's the community
20:33:30 <mikal> So, what happens when nova removes a tempest test because the devs no longer care for it?
20:33:34 <mikal> But its used in defcore?
20:33:42 <devananda> mikal: right. that's what I was about to ask
20:33:44 <annegentle> rockyg: I think it's that the compute test can't know what glance api it's using
20:33:45 <hogepodge> mikal: I've done that with keystone so we can add identity to the defcore capablities.
20:33:56 <zehicle_> devananda, we've been watching that and it's part of our discussion.  the process is worded so that TEMPEST is not required
20:34:16 <devananda> mikal, zehicle_: with the move to putting the test in each project's tree, we're delegating the responsibility to keep track of what tests defcore relies on to more people
20:34:20 <zehicle_> in fact, the board approves at the capability level.
20:34:38 <zehicle_> devananda, perhaps.
20:34:39 <mikal> So this happened the other day right?
20:34:42 <devananda> which also means more people who may not be tracking exactly what tests they shouldn't change / delete
20:34:54 <mikal> The EC2 people wanted to remove a test as being silly, and we just had a quick chat on the dev list about it
20:35:02 <dhellmann> mikal, devananda : if the tests are uniquely identified, we could possibly have a test that compares those ids with the defcore set and complains if the test is removed
20:35:03 <mikal> We'd now have to check with the board before we did anything like that?
20:35:07 <mikal> Just in case its used by defcore?
20:35:15 <zehicle_> devananda, true but there are more people consuming the tests against the guideline, so we're likely to find conflicts quickly
20:35:33 <zehicle_> mikal, no - that's covered in the process.
20:35:35 <dhellmann> zehicle_: I'll bet you a beer we can delete them faster than you'll spot them
20:35:49 <anteaya> zehicle_: #link https://review.openstack.org/#/c/173510/1 best I have right now
20:35:51 * devananda thinks dhellmann will win that
20:35:54 <zehicle_> dhellmann, I'll buy you a beer if you can add them fater
20:35:55 <rockyg> annegentle: if there is a problem with the defined tests, the vendors/community can contest them with their reasons why
20:36:00 <dhellmann> zehicle_: :-)
20:36:24 <dhellmann> rockyg: the problem is that after the test is removed, it's too late to say "no, no, put that back!"
20:36:38 <dhellmann> whatever code that test was checking might have changed in a way that the test would no longer pass
20:36:46 <zehicle_> dhellmann, if you remove it, then it's for a reason.  we'll code
20:36:51 <zehicle_> grrr.  we'll cope
20:37:01 <annegentle> hogepodge: is this the test list? https://review.openstack.org/#/c/167620/1/2015.03/2015.03.required.txt
20:37:08 <sdague> honestly, the tests that were added to the defcore list were limitted for a reason, as they really are the least likely to hit this as well
20:37:14 <rockyg> dhellmann: not if the test was already identified.  Since Defcore is trailing, and the test has been identified, it has at a minimum, a SHA that will always find it
20:37:16 <dhellmann> zehicle_: sure. I think the real question is, how can we minimize friction on both sides of the question, though
20:37:20 <sdague> I think this is an edge condition that 1 test per cycle might hit
20:37:24 <sdague> at the most
20:37:32 <sdague> and, even that's kind of doubtful
20:37:35 <devananda> zehicle_: is it reasonable to ask defcore team to provide a patch to the tests themselves that indicates they are used for defcore?
20:37:43 <hogepodge> annegentle: that's a filtered list of required tests based on the defcore list. It's meant to be fed directly to tempest to help run the tests.
20:37:50 <dhellmann> sdague: it sounds like we've already had a case though, with the ec2 stuff mikal mentioned
20:38:01 <sdague> dhellmann: ec2 wasn't in the defcore list
20:38:05 <zehicle_> these are issues that will get resolved over time - anything that uses REAL TEST will have age issue.  I'd rather have real tests
20:38:12 <dhellmann> sdague: ok, then I'm confused by mikal's comment
20:38:13 <ttx> ok, we need to timebox this
20:38:14 <sdague> it in no way triggered anything anyone is worried about
20:38:25 <rockyg> devananda: defcore is attaching labels to tests identified by defcore
20:38:26 <annegentle> hogepodge: ok thanks
20:38:35 <devananda> rockyg: perfect. then I think it's fine
20:38:38 <sdague> also, hogepodge is hanging out in #openstack-qa all the time and chatting with mtreinish a lot
20:38:42 <ttx> If you have concerns with the wording, propose patches. If you have concerns about the process, maybe raise a thread on the defcore list
20:38:44 <zehicle_> devananda, we're putting them into a json file.  I'm sure there's a way to automate the xref.
20:38:55 <mikal> dhellmann: it was just an example
20:38:58 <mtreinish> uh oh, my name popped up in a tc meeting
20:39:04 <dhellmann> mikal: ok, I read too much into it
20:39:12 <sdague> there is lots of communication there now, so I am pretty confident it will be figured out reasonably
20:39:22 <mikal> So, I'm actually not fussed
20:39:34 <ttx> sdague: yes, they seem to make a lot of progress lately
20:39:43 <mikal> If the agreement is that defcore will work out what to do when we change a tempest test to not meet their needs any more, then I am happy
20:39:44 <zehicle_> the process is more broad than the tests - happy to keep going on tests specifically; however, I wanted to make sure that the doc as a whole is considered
20:39:45 <devananda> zehicle_: it sounds like rockyg is already on that. a test label (decorator) in the projects is the best way, IMO, to communicate to developers that "this test is relied upon by defcore"
20:39:54 <mikal> Because when / if they complain in the future, I can point back here
20:40:02 <ttx> mikal: heh
20:40:19 <zehicle_> devananda, not objecting.  not owning at this point either
20:40:44 <hogepodge> mikal: we have a procedure for flagging tests in the current list, so we have a process for handling problems in flight.
20:40:54 <devananda> zehicle_: as for the rest of that process doc, I haven't sat with it enough to digest the whole thing, but nothing else has jumped out at me yet
20:40:59 <ttx> PSA: 5 more minutes and we'll move on
20:41:07 <zehicle_> mikal, if tempest met our needs today then I'd be a peace.  it's not so your changes will hopefully improve things
20:41:11 <hogepodge> mikal: like a test changes name, or breaks, for example.
20:41:23 <zehicle_> either way, we are already tracking moving tests out of tempest and discussing
20:41:26 <mtreinish> mikal: also, that's part of the removal procedure for tempest, if it's important to defcore or someone else we don't remove it
20:41:37 <mtreinish> https://wiki.openstack.org/wiki/QA/Tempest-test-removal
20:41:41 <rockyg> devananda: what hogpodge says.  He's got the reviews for this stuff.  I'll try and find the label one for you...
20:42:26 <sdague> yeh, I honestly think the nuts and bolts have actually been pretty well sorted by hogepodge and mtreinish. And if there is a big explody somewhere, which I highly doubt, we can deal with it as an exception.
20:42:36 <zehicle_> we're talking on one point (tests) - please make sure that you read the doc as a larger whole too.
20:42:54 <ttx> sdague: ++
20:43:08 <annegentle> zehicle_: I'll be honest. I feel like it's another case of "commons" work that no one wants to own but everyone wants "the community" to do. There's also hand-waving after A6 -- how do missing get added?
20:43:11 <dhellmann> sdague, mtreinish : sounds good -- I didn't realize you'd already been working on this.
20:43:28 <devananda> zehicle_: any thoughts on the process when defcore + TC does not include any representative of a project to which the trademark is applied?
20:43:32 <devananda> I dont think that's happened yet
20:43:37 <devananda> but wondering if folks have thought about it
20:43:44 <devananda> *direct representative
20:43:48 <ttx> devananda: the TC is not part of the process beyong the tc-approved release
20:43:56 <russellb> +1
20:43:57 <ttx> everythign else mentions PTL, no ?
20:44:00 <zehicle_> annegentle, I think the "communitiy" has a pretty strong, "we write and demand tests" mantra.
20:44:16 <annegentle> zehicle_: I've read, re-read, gave input on the PTL portion and appreciate you adding. Just have to give that additional bit of process input.
20:44:18 <zehicle_> annegentle, but I'm inclined to agree we need to watch out for commons will do it
20:44:23 <annegentle> zehicle_: we do have to try and see.
20:44:47 <zehicle_> annegentle, my hope is that DefCore gives vendors incentive to add tests.
20:44:54 <ttx> OK, we need to move on...
20:44:59 <ttx> Thanks zehicle!
20:45:08 <zehicle_> thanks everyone.  happy to answer questions on the DefCore list or 1x1 too
20:45:28 <ttx> #topic Avoid "policy" in Congress description
20:45:36 <ttx> #link https://review.openstack.org/169480
20:45:43 <ttx> Looks like we need to bikeshed a bit to make progress there
20:45:50 <ttx> But we don't have that much time left in meeting to play
20:45:59 <ttx> jeblair, annegentle: could you discuss offline and come up with something that pleases you both ?
20:46:22 <ttx> As long as it doesn't use policy I'm fine with it.
20:46:28 <ttx> or "project"
20:46:34 <ttx> or "core"
20:46:36 <annegentle> heh
20:46:43 <sdague> or middleware
20:46:48 <jeblair> ttx: sure
20:46:58 <jeblair> i don't actually care, just wanted to have something to bikeshed on
20:47:04 <jeblair> i'll roll the dice again and see what comes up :)
20:47:16 * rockyg thinks they should avoid community as well;)
20:47:20 <annegentle> sure - jeblair I just want a shorter service name so it can be written in a doc
20:47:28 <ttx> #topic Cross-project track at the Design Summit
20:47:35 <ttx> We have a number of proposals at:
20:47:40 <ttx> #link https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit?usp=sharing
20:48:03 <ttx> I'll include dhellmann and annegentle who volunteered from the TC as editors on that doc. Everyone else can add comments
20:48:11 <devananda> ttx: is this spreadsheet the appropriate place to make such proposals?
20:48:20 <ttx> no, that' sthe result sheet.
20:48:20 <jeblair> ttx: i can't seem to edit that
20:48:30 <ttx> The way to add is through the foirm
20:48:31 <ttx> form
20:48:32 <dhellmann> #link submit a session proposal http://goo.gl/forms/S69HM6XEeb
20:48:48 <russellb> ha @ nova and neutron "hug it out"
20:48:53 <ttx> All links were posted to ML and https://wiki.openstack.org/wiki/Design_Summit/Planning
20:49:20 <mikal> russellb: heh, that's not going to take 50 minutes
20:49:23 <ttx> the link dhellmann posted is to add an entry, and anyone can
20:49:29 * mestery is ready to hug
20:49:34 <sdague> yeh, I need to add a couple here
20:49:35 <annegentle> heh extended hugs session
20:49:36 <ttx> The question at this point is more.. what is missing
20:49:37 <russellb> mikal: unless it was also used as the place to have the "next steps" conversation
20:49:46 <sdague> We really need to have a Service Catalog Standards conversation
20:49:46 <annegentle> docs are in, that's all I care about (kidding)
20:49:49 <ttx> There will be a discussion at the meeting next about it
20:49:49 * mikal will hug mestery, but it wont help
20:49:50 <annegentle> sdague: yes
20:49:53 <mestery> lol
20:50:20 <mordred> mikal: I will throw chickens at you two while you hug
20:50:25 <mordred> sdague: ++
20:50:27 <sdague> the js one I'm not sure fits for cross project
20:50:30 <russellb> mestery: mikal planning to have a session in nova or neutron track on next steps?
20:50:32 <ttx> At this point the goal is to collect as many ideas as possible, we'll merge and select them later (probably end of month)
20:50:33 <mordred> sdague: YES TO SERVICE CATALOG STANDARDS
20:50:33 <mikal> russellb: so I feel that the L Nova PTL does need to sit down with mestery and come up with a plan for what to do about this at the summit
20:50:42 <mikal> russellb: but I think that can't be done until next week
20:50:50 <mestery> mikal: ++
20:50:53 <russellb> k
20:51:09 <russellb> i like what we did a couple cycles ago, the gap analysis action plan
20:51:24 <ttx> mikal/russellb/mestery: there is one time slot where neutron doesn't have anything and nova has a slot, ftr
20:51:26 <russellb> sounds like it's time to have another detailed action plan like that
20:51:35 <devananda> mikal: we should also talk about nova + ironic (and other clustered hypervisors). do you feel that's better in the nova track, though?
20:51:38 <mikal> Well, I think we need to include actual operators more this time, I think that's where we missed last time
20:51:39 <russellb> the last one got us much closer
20:51:41 <mestery> ttx; I'm hoping to use taht one as the track :)
20:51:52 <mestery> mikal: ++
20:51:57 <mikal> devananda: I think that's a nova track thing
20:52:02 <devananda> mikal: ack
20:52:05 <sdague> ttx: can you get the Cloud Service Federation people to explain more? That is terribly vague to me
20:52:08 <mordred> mikal, devananda: I'd like to lurk/heckle that one
20:52:25 <dhellmann> devananda, mikal : yeah, in the past we've said that cross-project needs to mean more than 2 projects
20:52:26 <ttx> sdague: I stopped readin at "supply chain"
20:52:26 <mikal> mordred: you're welcome to
20:52:28 <mordred> sdague: its about Federating your Cloud Service
20:52:35 <mordred> mikal: awesome!
20:52:48 <sdague> mordred: so... stackforge/os-policy-core-middleware is it?
20:53:09 <dougwig> sdague:  /core/maintainer/
20:53:09 <devananda> dhellmann: so physical network support will involve ironic + nova + neutron. I'll toss that one on the form
20:53:12 <dhellmann> sdague: stackforge/python-os-policy-core-middleware
20:53:39 <mordred> sdague: stackforge/python-os-policy-core-middleware-tenant
20:53:44 <dhellmann> devananda: ok. That might still just fall under team-specific integration, vs. "how should openstack approach problems generally"
20:53:55 <ttx> sdague: could you add a comment on that cell saying it's vague ? I'll reach out to them
20:54:04 <sdague> ttx: I don't have edit perms
20:54:13 <ttx> You have comment perms trough
20:54:16 <ttx> though
20:54:21 <dhellmann> sdague: added as a comment
20:54:24 <sdague> ah, ok
20:54:26 <ttx> or at least you should have
20:54:28 <dhellmann> oops, s/added/add it/
20:54:29 <devananda> sdague: I'd love to see a session on "how all the projects should be testing in the big tent" - though honestly, that probably should be a presentation, not a discussion :)
20:54:43 <anteaya> does anyone want to have a session on how hard it is to deploy openstack for small deployments?
20:54:57 <ttx> sdague: I'm fine with adding you as editor if you pledge your firstborn and some of your time at the end of the month to the cause
20:54:58 <dhellmann> anteaya: that sounds like an ops summit session?
20:55:15 <russellb> or fuel, or tripleo, or ...
20:55:22 <anteaya> really?
20:55:40 <sdague> ttx: well, I won't give up my first born, but you can have some time
20:55:57 <ttx> sdague: wait until you have to and you'll beg me to take them
20:56:00 <ttx> two*
20:56:07 <ttx> OK, we need to move on
20:56:10 <jogo> what are the criteria for a session being picked?
20:56:40 <ttx> jogo: needs to be cross-project, and needs to be a problem the TC thinks is worth the time
20:56:41 <sdague> jogo: they look like they will be helpful to solving real problems in OpenStack, and involve > 2 projects
20:57:01 <ttx> much like how PTLs select sessions for their own track
20:57:11 <ttx> ok, moving on quickly
20:57:12 <jogo> shouldn't these also be things that we have not been able to resolve on the ML already as well?
20:57:15 <russellb> fwiw i think 2 project sessions should be considered fair game
20:57:20 <russellb> just lower priority
20:57:29 <ttx> jogo: right, worth the F2F time
20:57:37 <devananda> jogo: it sounds like some folks are pushing those towards individual project tracks
20:57:44 <ttx> #topic Projects list housekeeping
20:57:48 <sdague> russellb: yeh, honestly, I'd make an exception for the nova/neutron path forward thing because it's one of the top ops blockers
20:57:50 <russellb> last time i think some 2 project sessions would have been better uses of time
20:57:53 <stevebaker> is it too early to be having sessions about defining and assigning tags to projects?
20:57:59 <russellb> sdague: that's the main one i had in mind :)
20:58:11 <ttx> stevebaker: you can propose it. Not too early
20:58:19 <ttx> Two repository additions that have their PTL's +1 already. Will approve tomorrow unless someone -1s by then:
20:58:24 <ttx> * Add devstack-vagrant to QA (https://review.openstack.org/171677)
20:58:27 <ttx> * Add openstack-dev/specs-cookiecutter (https://review.openstack.org/170946)
20:58:30 <ttx> #topic Open discussion
20:58:48 <ttx> We can continue brainstorming topics in the remaining 2 min
20:59:00 <ttx> Any other topic / question ?
20:59:08 <markmcclain> I'll be off the grid Apr 17-28th
20:59:16 <ttx> Early questions on the Puppet/OpenStack and MagnetoDB applications ?
20:59:20 <jogo> I took a look at http://governance.openstack.org/reference/tags/index.html recently
20:59:35 <jogo> and tags are hard to use for downstream folks
20:59:46 <anteaya> ttx are we also going to allow in salt/chef/ansible because where puppet goes they all follow
20:59:47 <jogo> how do I find a set of projects that have the following tags etc.
21:00:03 <ttx> jogo: openstack.org/software is supposed to be overhauled
21:00:09 <jeblair> ttx: looks like the name is the biggest hurdle is what to name the openstack puppet "project"
21:00:16 <ttx> jogo: and provide search/navigation
21:00:28 <jogo> ttx: that will include tags?
21:00:33 <ttx> jogo: yes
21:00:40 <russellb> we should have someone design badges for each tag
21:00:44 <russellb> that would make the web site fun, heh
21:00:57 <sdague> jeblair: borkbork is alway an option
21:01:03 <ttx> jogo: you're free to come up with your own viz though if you don't like that idea
21:01:05 <devananda> russellb: i read that as "have someone design badgers"
21:01:07 <mikal> I would wear a "single point of failure" badge to the summit
21:01:08 <jogo> ttx: ahh, will that page end up linking back to governance/tags etc?
21:01:10 <devananda> which I like more than badges
21:01:11 <jeblair> russelb: and keep a graphic designer in business
21:01:12 <russellb> devananda: sure, that too!
21:01:16 <annegentle> SPOF tshirts
21:01:21 <jeblair> sdague: ++!
21:01:23 <russellb> jeblair: right, and that's always a nice thing
21:01:24 <ttx> jogo: should do yes
21:01:30 <ttx> and.. we are out of time
21:01:34 <ttx> #endmeeting