20:03:05 #startmeeting tc 20:03:06 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:10 \o/ on tippie toes 20:03:10 The meeting name has been set to 'tc' 20:03:14 Our agenda for today: 20:03:19 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:36 #topic Asking permission to dedicate the Kilo release to the memory of Chris Yeoh 20:03:46 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 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 I would like to see this happen 20:04:01 How does that sound ? 20:04:06 +1 20:04:06 ttx: +1 20:04:07 ++ 20:04:09 +1 20:04:17 +2 20:04:21 o/ 20:04:24 ++ 20:04:27 sounds great 20:04:30 +1 20:04:32 +1 20:04:45 * jhesketh likes this as an onlooker 20:04:49 * dansmith does too 20:04:56 ttx: probably worth a roll call vote just to make it official and in the minutes 20:04:58 That will probably let the Foundation staff prepare somethign on the website too 20:05:01 ok, startvoting 20:05:03 * rockyg likes it though I can't vote 20:05:20 ttx: ++ 20:05:27 +1 20:05:34 #startvote Should the Kilo release be dedicated to the memory of Chris Yeoh? Yes, No, Abstain 20:05:35 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 Vote using '#vote OPTION'. Only your last vote counts. 20:05:38 #vote yes 20:05:40 #vote yes 20:05:41 #vote yes 20:05:42 #vote yes 20:05:44 #vote yes 20:05:44 #vote Yes 20:05:45 #vote yes 20:05:46 #vote Yes 20:05:46 #vote yes 20:05:47 #vote Yes 20:05:58 * ttx hopes the vote system is case-sensitive 20:06:03 insensitive I mean 20:06:07 #vote Yes 20:06:10 we'll find out in an minute 20:06:13 #vote yes 20:06:26 ok 30 more seconds 20:07:02 #endvote 20:07:03 Voted on "Should the Kilo release be dedicated to the memory of Chris Yeoh?" Results are 20:07:04 Yes (11): ttx, devananda, annegentle, jeblair, russellb, sdague, jgriffith, mikal, mordred, dhellmann, markmcclain 20:07:14 awesome, the vote bot is with us 20:07:19 woot 20:07:22 \o/ 20:07:24 yay vote-bot 20:07:26 nice 20:07:41 Awesome, thanks everyone 20:07:45 #topic Adding Mistral Workflow Service to OpenStack 20:07:55 #link https://review.openstack.org/170225 20:08:07 I think... it fits the requirements. 20:08:13 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 Thoughts ? 20:08:29 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 yeah, i had been meaning to define something around team size ... haven't gotten to it yet 20:08:59 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 even though they are supposed to use each other? 20:09:13 Can we avoid the term bus-factor? 20:09:21 hi everyone. I'm a PTL of Mistral and you can ask me questions if you have 20:09:22 yes 20:09:22 * anteaya wonders why we need a yaml based language when we have yaml 20:09:32 jgriffith: I'd describe it as a basic openstack client programming language 20:09:37 combined with a cron 20:09:50 ttx: so I should clarify... I'm struggling to see the point :) 20:10:00 ttx: errr... value 20:10:05 so - I'm +1 20:10:10 because there are people who like it 20:10:13 and it doesn't hurt anything 20:10:19 mordred: right 20:10:20 and I don't see any reason to deny it entry 20:10:20 is this (just) a service to run taskflow-as-a-service ? 20:10:24 jgriffith: so, same, but I'd still be +1, because apparently someone wants it 20:10:31 mordred: haha... yeah, I forget the low bar :) 20:10:34 i just posted the team diversity info to the review if anyone is interested 20:10:40 jgriffith: I'm just trying to remind everyone :) 20:10:41 russellb: thanks, looking 20:10:44 how is this different from heat's similar template thing? 20:10:45 * jgriffith refrains from smart a$$ comments 20:10:53 devananda, no, it's not taskflow-as-a-service 20:11:06 dhellmann: does it matter? we want to encourage competition I hear 20:11:09 anteaya: because YAML doesn't describe how to run workflow, therefore you'll always need some way of interpreting the YAML 20:11:13 mordred: no, I'm just curious 20:11:15 kk 20:11:17 I think the Amazonomorphy for it would be Amazon SWF 20:11:30 But then they have so many services :) 20:11:36 it's complementary to Heat IMO 20:12:03 Heat might trigger a workflow defined in Mistral in response to some condition it's watching 20:12:13 ah, cool 20:12:17 Yes, I spent some time looking into it and it feels complementary 20:12:19 I have heard people say the thing russellb said 20:12:25 russellb++ 20:12:39 and also vice-versa 20:12:47 indeed 20:13:10 So, what's a sample use case? 20:13:10 They also are unquestionably an OpenStack project 20:13:11 so, e.g. Ceilometer alarm triggers a workflow, part of which may be hitting the autoscaling trigger in Heat 20:13:15 That might make this clearer for people\ 20:13:36 mikal: they have plenty of use cases described on their wiki page 20:14:24 https://wiki.openstack.org/wiki/Mistral 20:14:39 sdague: it seems like they plan on fixing that during liberty cycle 20:14:47 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 jeblair: yeh, I'm +1, but I thought it was worth recording 20:15:05 sdague: hopefully they'll adopt g-r...? 20:15:17 mikal: running payroll change jobs quarterly or at bonus time in your OpenStack cloud 20:15:35 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 jeblair: do we actually have adopting g-r as a requirement now? 20:15:44 annegentle: I was actually thiking video transcode for example 20:15:47 I see some value in it, and more importantly I don't see any drawback to having it 20:15:58 Ok... fair enough I suppose 20:16:06 the way I always put it is: Heat models nouns, Mistral models verbs. Both are important, and complementary :) 20:16:09 dhellmann: i don't think we do, but it seems like maybe they might want to 20:16:12 mikal: https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron 20:16:15 Getting some network lag, so please proceed if I suddenly disappear 20:16:21 jeblair: yeah 20:16:22 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 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 We have 8 YES at this point 20:17:18 jeblair: yeah, and I think that's really about the GPL, not g-r 20:17:22 dhellmann: i think reading that to mean g-r would be an... expansive... reading of it... :) 20:17:36 ttx: 9 20:17:37 I'll let the discussion continue for a bit but it already has enough for acceptance 20:17:37 dhellmann: honestly, it was mostly just a coordination issue between mistral and murano 20:17:57 sdague: yeah 20:18:01 dhellmann: yes, it's about (A)GPL 20:18:01 because we ran into that rstlib issue 20:18:13 really late in grizzly 20:19:02 that was so much fun 20:19:21 really really late 20:19:44 I think we need to acknowledge that increased integration actually hurts. 20:20:01 as far as Murano and Mistral compatibility, it's being solved now and will be solved in 1-2 days 20:20:06 woot 20:20:19 OK, time to close it, unless someone has a definitive argument that (s)he thinks can sway voters completely 20:20:22 rakhmerov: cool 20:20:41 rakhmerov: ++ 20:20:45 ttx: moar rubber stamp! 20:20:50 approved 20:20:54 jgriffith: more than "doesn't hurt" the philosophy is "it's already an openstack project" 20:21:07 thanks! 20:21:49 ttx: point taken 20:21:54 rakhmerov: welcome 20:21:54 #topic More Defcore process discussion 20:22:35 o/ 20:22:39 #link http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst 20:22:47 * rockyg waves from behind zehicle 20:23:33 mainly here to collect feedback and answer questions 20:23:44 #link http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst 20:23:56 Last week we postponed the discussion until everyone had a chance to look into the proposed process 20:23:56 "A3. PTLs Recommend Changes to Designated Sections" 20:23:56 Personally I thought it was disconnected from the bylaws requirements (to build on top of the "tc-approved release") 20:23:57 And therefore I proposed the addition of wording to cover that, and it got merged: 20:23:57 #link https://review.openstack.org/172417 20:23:57 I don't have objections left 20:23:57 But you may have 20:23:57 zehicle: you around? 20:23:57 ttx I'm here, and can try to answer any questions. 20:23:57 wow, we seem to have weird lag with the bot too 20:23:57 I'm secretary to the committee, but obvs not on the board (and it's a board committee) 20:24:06 I don't think the tech community should have to be responsible for defining that 20:24:07 ttx, yes 20:24:14 that's what we spent lots of time going through last cycle 20:24:20 and declined to define 20:24:45 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 zehicle: don't we essentially rather recommend changes to Capabilities than Designated Sections ? 20:25:10 (we as PTLs) 20:25:19 the goal for DefCore is to be trailing. not having tests would be a reason to exclude it from consideration 20:25:30 basically, I think the TC and/or PTLs should be outside of this as much as possible 20:25:33 the point is to pick up things that are stable and adopted 20:25:39 with the only exception being defining the TC approved release 20:25:48 Crazy idea... runs the tempest tests same as in gate... done 20:25:55 russellb: the way I understand it was inside a project, designated sections can be updated with PTLs opinion 20:26:07 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 zehicle_: so no new features of kilo would be included until a later release? 20:26:12 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 different from TC listing projects from above 20:26:20 dhellmann, yes, by definition 20:26:27 zehicle_: ok, thanks 20:26:29 i don't think we should have to agree or approve to using a subset of the code 20:26:54 would it be better to submit a patch with my justification in commit message? 20:26:54 dhellmann, in fact, we intentionally took out the release timing from the process. it's date specs now 20:27:05 sdague: ++ 20:27:11 russellb: that's the PTLs, right? not the TC? 20:27:12 russellb, patches strongly encouraged. 20:27:26 but want to be available to answer questions interactively too 20:27:29 dhellmann: "we" as the technical community / technical leadership more generally 20:27:43 since we want to conclude discussions before we meet f2f in vancouver 20:27:47 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 dhellmann, yes. 20:28:06 dhellmann: yes 20:28:07 sdague: ++ 20:28:20 zehicle_: there was a dependency question I had, let me see if I can articulate 20:28:24 zehicle_: that might be clarified elsewhere, but if not maybe add a note? 20:28:49 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 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 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 zehicle_: (mikal too probably knows) 20:29:28 new stuff = stuff that isn't currently in Defcore that lots of folks are using 20:29:45 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 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 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 anteaya, we do have a lexicon in the repo 20:31:03 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 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 devananda, we'd look at the project as a whole. new features would be included in that 20:31:32 zehicle_: sorry, that should have ended with a ? 20:31:49 zehicle_: ok, gotcha 20:31:49 anteaya, please add! 20:31:53 annegentle: I think there is an assumption that defcore will provide tempest tests where they are missing 20:31:55 annegentle: the tests are all listed in a json file, and categorized, so you look for the image v2 category 20:31:58 zehicle_: I don't know what should go there 20:32:01 annegentle: that's certainly what they've said to me in the past 20:32:06 mikal: ok 20:32:07 * ttx can testify the process to get changes in is rather straightforward :) 20:32:08 o/ 20:32:10 sorry i’m late 20:32:19 mikal, no - defcore does not provide tests. we're limited to what;s there 20:32:32 we are currently discussion how to take tempests that are outside of tempest too 20:32:33 yeah, i'll just post my feedback as a patch, i think that'll be easier 20:32:47 that's likely a hot topic post Vancouver 20:32:48 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 russellb, +1 20:33:02 zehicle_: yeah, that's going to be important 20:33:05 mikal: so if there are no image v2 tests, then that feature would be excluded from the current defcore definition 20:33:06 mikal add tests to tempest or elsewhere 20:33:11 mikal, we are creating _incentives_ to increase tests 20:33:15 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 we are not a technical group that can create tests - that's the community 20:33:30 So, what happens when nova removes a tempest test because the devs no longer care for it? 20:33:34 But its used in defcore? 20:33:42 mikal: right. that's what I was about to ask 20:33:44 rockyg: I think it's that the compute test can't know what glance api it's using 20:33:45 mikal: I've done that with keystone so we can add identity to the defcore capablities. 20:33:56 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 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 in fact, the board approves at the capability level. 20:34:38 devananda, perhaps. 20:34:39 So this happened the other day right? 20:34:42 which also means more people who may not be tracking exactly what tests they shouldn't change / delete 20:34:54 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 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 We'd now have to check with the board before we did anything like that? 20:35:07 Just in case its used by defcore? 20:35:15 devananda, true but there are more people consuming the tests against the guideline, so we're likely to find conflicts quickly 20:35:33 mikal, no - that's covered in the process. 20:35:35 zehicle_: I'll bet you a beer we can delete them faster than you'll spot them 20:35:49 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 dhellmann, I'll buy you a beer if you can add them fater 20:35:55 annegentle: if there is a problem with the defined tests, the vendors/community can contest them with their reasons why 20:36:00 zehicle_: :-) 20:36:24 rockyg: the problem is that after the test is removed, it's too late to say "no, no, put that back!" 20:36:38 whatever code that test was checking might have changed in a way that the test would no longer pass 20:36:46 dhellmann, if you remove it, then it's for a reason. we'll code 20:36:51 grrr. we'll cope 20:37:01 hogepodge: is this the test list? https://review.openstack.org/#/c/167620/1/2015.03/2015.03.required.txt 20:37:08 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 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 zehicle_: sure. I think the real question is, how can we minimize friction on both sides of the question, though 20:37:20 I think this is an edge condition that 1 test per cycle might hit 20:37:24 at the most 20:37:32 and, even that's kind of doubtful 20:37:35 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 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 sdague: it sounds like we've already had a case though, with the ec2 stuff mikal mentioned 20:38:01 dhellmann: ec2 wasn't in the defcore list 20:38:05 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 sdague: ok, then I'm confused by mikal's comment 20:38:13 ok, we need to timebox this 20:38:14 it in no way triggered anything anyone is worried about 20:38:25 devananda: defcore is attaching labels to tests identified by defcore 20:38:26 hogepodge: ok thanks 20:38:35 rockyg: perfect. then I think it's fine 20:38:38 also, hogepodge is hanging out in #openstack-qa all the time and chatting with mtreinish a lot 20:38:42 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 devananda, we're putting them into a json file. I'm sure there's a way to automate the xref. 20:38:55 dhellmann: it was just an example 20:38:58 uh oh, my name popped up in a tc meeting 20:39:04 mikal: ok, I read too much into it 20:39:12 there is lots of communication there now, so I am pretty confident it will be figured out reasonably 20:39:22 So, I'm actually not fussed 20:39:34 sdague: yes, they seem to make a lot of progress lately 20:39:43 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 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 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 Because when / if they complain in the future, I can point back here 20:40:02 mikal: heh 20:40:19 devananda, not objecting. not owning at this point either 20:40:44 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 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 PSA: 5 more minutes and we'll move on 20:41:07 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 mikal: like a test changes name, or breaks, for example. 20:41:23 either way, we are already tracking moving tests out of tempest and discussing 20:41:26 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 https://wiki.openstack.org/wiki/QA/Tempest-test-removal 20:41:41 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 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 we're talking on one point (tests) - please make sure that you read the doc as a larger whole too. 20:42:54 sdague: ++ 20:43:08 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 sdague, mtreinish : sounds good -- I didn't realize you'd already been working on this. 20:43:28 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 I dont think that's happened yet 20:43:37 but wondering if folks have thought about it 20:43:44 *direct representative 20:43:48 devananda: the TC is not part of the process beyong the tc-approved release 20:43:56 +1 20:43:57 everythign else mentions PTL, no ? 20:44:00 annegentle, I think the "communitiy" has a pretty strong, "we write and demand tests" mantra. 20:44:16 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 annegentle, but I'm inclined to agree we need to watch out for commons will do it 20:44:23 zehicle_: we do have to try and see. 20:44:47 annegentle, my hope is that DefCore gives vendors incentive to add tests. 20:44:54 OK, we need to move on... 20:44:59 Thanks zehicle! 20:45:08 thanks everyone. happy to answer questions on the DefCore list or 1x1 too 20:45:28 #topic Avoid "policy" in Congress description 20:45:36 #link https://review.openstack.org/169480 20:45:43 Looks like we need to bikeshed a bit to make progress there 20:45:50 But we don't have that much time left in meeting to play 20:45:59 jeblair, annegentle: could you discuss offline and come up with something that pleases you both ? 20:46:22 As long as it doesn't use policy I'm fine with it. 20:46:28 or "project" 20:46:34 or "core" 20:46:36 heh 20:46:43 or middleware 20:46:48 ttx: sure 20:46:58 i don't actually care, just wanted to have something to bikeshed on 20:47:04 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 sure - jeblair I just want a shorter service name so it can be written in a doc 20:47:28 #topic Cross-project track at the Design Summit 20:47:35 We have a number of proposals at: 20:47:40 #link https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit?usp=sharing 20:48:03 I'll include dhellmann and annegentle who volunteered from the TC as editors on that doc. Everyone else can add comments 20:48:11 ttx: is this spreadsheet the appropriate place to make such proposals? 20:48:20 no, that' sthe result sheet. 20:48:20 ttx: i can't seem to edit that 20:48:30 The way to add is through the foirm 20:48:31 form 20:48:32 #link submit a session proposal http://goo.gl/forms/S69HM6XEeb 20:48:48 ha @ nova and neutron "hug it out" 20:48:53 All links were posted to ML and https://wiki.openstack.org/wiki/Design_Summit/Planning 20:49:20 russellb: heh, that's not going to take 50 minutes 20:49:23 the link dhellmann posted is to add an entry, and anyone can 20:49:29 * mestery is ready to hug 20:49:34 yeh, I need to add a couple here 20:49:35 heh extended hugs session 20:49:36 The question at this point is more.. what is missing 20:49:37 mikal: unless it was also used as the place to have the "next steps" conversation 20:49:46 We really need to have a Service Catalog Standards conversation 20:49:46 docs are in, that's all I care about (kidding) 20:49:49 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 sdague: yes 20:49:53 lol 20:50:20 mikal: I will throw chickens at you two while you hug 20:50:25 sdague: ++ 20:50:27 the js one I'm not sure fits for cross project 20:50:30 mestery: mikal planning to have a session in nova or neutron track on next steps? 20:50:32 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 sdague: YES TO SERVICE CATALOG STANDARDS 20:50:33 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 russellb: but I think that can't be done until next week 20:50:50 mikal: ++ 20:50:53 k 20:51:09 i like what we did a couple cycles ago, the gap analysis action plan 20:51:24 mikal/russellb/mestery: there is one time slot where neutron doesn't have anything and nova has a slot, ftr 20:51:26 sounds like it's time to have another detailed action plan like that 20:51:35 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 Well, I think we need to include actual operators more this time, I think that's where we missed last time 20:51:39 the last one got us much closer 20:51:41 ttx; I'm hoping to use taht one as the track :) 20:51:52 mikal: ++ 20:51:57 devananda: I think that's a nova track thing 20:52:02 mikal: ack 20:52:05 ttx: can you get the Cloud Service Federation people to explain more? That is terribly vague to me 20:52:08 mikal, devananda: I'd like to lurk/heckle that one 20:52:25 devananda, mikal : yeah, in the past we've said that cross-project needs to mean more than 2 projects 20:52:26 sdague: I stopped readin at "supply chain" 20:52:26 mordred: you're welcome to 20:52:28 sdague: its about Federating your Cloud Service 20:52:35 mikal: awesome! 20:52:48 mordred: so... stackforge/os-policy-core-middleware is it? 20:53:09 sdague: /core/maintainer/ 20:53:09 dhellmann: so physical network support will involve ironic + nova + neutron. I'll toss that one on the form 20:53:12 sdague: stackforge/python-os-policy-core-middleware 20:53:39 sdague: stackforge/python-os-policy-core-middleware-tenant 20:53:44 devananda: ok. That might still just fall under team-specific integration, vs. "how should openstack approach problems generally" 20:53:55 sdague: could you add a comment on that cell saying it's vague ? I'll reach out to them 20:54:04 ttx: I don't have edit perms 20:54:13 You have comment perms trough 20:54:16 though 20:54:21 sdague: added as a comment 20:54:24 ah, ok 20:54:26 or at least you should have 20:54:28 oops, s/added/add it/ 20:54:29 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 does anyone want to have a session on how hard it is to deploy openstack for small deployments? 20:54:57 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 anteaya: that sounds like an ops summit session? 20:55:15 or fuel, or tripleo, or ... 20:55:22 really? 20:55:40