20:01:52 #startmeeting tc 20:01:53 Meeting started Tue Feb 11 20:01:52 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:57 The meeting name has been set to 'tc' 20:02:02 Our agenda for today: 20:02:07 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:21 #topic Incubation request: Barbican 20:02:29 Original request: 20:02:31 #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025860.html 20:02:36 Etherpad with analysis: 20:02:41 #link https://etherpad.openstack.org/p/GFoJ4LpK8A 20:02:50 * ttx refreshes 20:04:12 Looks like everything is covered 20:04:32 yep 20:04:33 jraim: devstack-gate job still missing, but on its way ? 20:04:43 really appreciate the hard work since we last talked 20:04:53 jraim: the devstack integration is done and the reviews look good, but it hasn't been merged yet 20:04:57 we need to poke some people I think 20:05:21 russellb: thanks - I appreciate the feedback we've gotten from everyone during this process 20:05:37 comments anyone ? 20:05:44 yes 20:06:05 I was wondering if there were any steps taken based on justinsbs feedback 20:06:05 yes 20:06:12 about the apis 20:06:14 ttx: o/ 20:06:27 lifeless, annegentle: welcome 20:06:31 vishy: the issue about having more of the API defined? 20:07:09 jraim: I had also hoped the api docs would be in a public repo for comment and review 20:07:27 ttx: o/ as well 20:07:33 jraim: the thread here http://lists.openstack.org/pipermail/openstack-dev/2013-September/015477.html 20:08:07 technically API docs are listed as a requirement, too ... so have to decide whether we're willing to waive that if they're not there ... also have the devstack-gate issue 20:08:26 annegentle: we plan to do that, I think ayoung put in the first review for it 20:08:40 jraim: actually wrong thread 20:08:42 this one: http://markmail.org/message/erzouim6pnqjaqtz 20:08:49 russellb: we do have API docs on our wiki in github and those are being moved to docbook now 20:08:51 are these not API docs? https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface 20:08:57 jraim: ok 20:09:02 nm then 20:09:05 jraim: ah, found it. https://review.openstack.org/#/c/71396/ 20:09:21 vishy: right. While I sympathize with the problem, I don't think roughing out APIs that don't have code or consumers before they are needed is the right way to go 20:09:29 specifically key rotation / symmetric keys 20:09:49 so the plan is to figure it out later and fix it in v2? 20:10:24 I think the plan is to add those features when there is need and deal with the API changes. Hopefully, we can do them in a backwards compatible manner 20:10:37 jraim: ok 20:10:41 if we can't, then we'll have to factor that into the implementation 20:10:52 vishy: they are entering incubation, not being released just now 20:11:15 ttx: I know, I'm unclear on when a 1.0 api would be considered final 20:11:27 but it isn't totally obvious that it would be at integration time 20:11:39 so I wanted to follow up a bit on justin's concerns 20:11:44 vishy: yes, I have a point about that later in the meeting 20:12:00 (about the API stability constraints) 20:12:06 it is a reasonable concern. I'm not sure how to fix it however. Building stable APIs is hard 20:12:11 jraim, what happens "the Cloud Keep initiative" if Barbican enters Incubation? 20:12:17 we can try the best we can and then version appropriately 20:12:29 markmc: most of our work is already moved over to stackforge 20:12:34 and when we would expect other openstack projects to start using it -- on incubation, in the j cycle, or graduation... 20:12:50 CloudKeep might keep some things outside of OpenStack (e.g. vendor plugins, etc) 20:12:58 but other than that, I don't have a lot of plans for it 20:13:00 jraim, I guess I'm asking what would be part of this new program apart from barbican and python-barbicanclient 20:13:18 jraim: which plugins do you expect to be in barbican then? 20:13:28 jraim, or how would you decide as PTL what to move into the program from cloudkeep and what to keep in cloudkeep? 20:13:29 markmc: right now, I think that's it. We are looking at Dogtag integration which might be its own repo, we'll see how the RedHat guys feel 20:13:54 which would you encourage in vs out 20:14:01 or how would you decide that 20:14:07 markmc: off the top of my head, anything that we would want to use openstack process for (e.g. gerrit, etc) would move over 20:14:16 not sure how other projects handle vendor plugins 20:14:22 but I'd probably steal their ideas on that one 20:14:39 I'd rather default to in OpenStack / in-tree is possible 20:14:42 include them all for the most part, as long as they make sense / play by the rules 20:14:43 Why wouldn't you want to use our process for everything? 20:14:50 and just be mindful of adding things that no one cares about 20:15:03 jraim, no https://github.com/stackforge/postern ? and cloudkeep/postern is essentially empty ? 20:15:06 Ahhh, ok 20:15:09 mikal: if the code is written by a non-contributor maybe? 20:15:13 jraim, how important is an agent to barbican? 20:15:38 markmc: is was part of the original idea behind the project. Since then, we've looked at certmonger and some other options 20:15:50 we might still create an agent if there are use cases for it 20:16:07 ok, so no use cases requiring it right now? 20:16:08 not sure if those are useful for openstack services or just consumers of an openstack cloud 20:16:25 markmc: I have some use cases for apps that run on an openstack cloud 20:16:33 and redhat has some based on certmonger for openstack services 20:16:50 there are some needs there, but more thought required before we started working on anything 20:17:04 redhat might move forward with certmonger integreation - we've talked about it 20:17:17 so, cloud operators would need to get an agent from elsewhere for those use cases ? 20:17:40 markmc: we could go either way. If we think it belongs in openstack, happy to do it here 20:17:55 but where's the agent now? 20:18:02 TC members: do you think we should wait for the minimal devstack-gate requirement to be fully implemented before considering this request ? Or can we provisionally accept ? 20:18:13 but if it just an app that uses barbican that can work on any platform, maybe it doesn't go in openstack? 20:18:47 ttx: i think we should wait 20:18:58 jraim, if features of barbican aren't functional to users of openstack clouds without the agent, then I think it's an important part of this new program 20:19:01 #link https://review.openstack.org/#/c/70512/ 20:19:13 (That's the review for the devstack gate, right sdague?) 20:19:17 markmc: I would agree. 20:19:20 markmc: +1 20:19:24 jraim, where's the code for the agent? 20:19:25 markmc: the agent looks pretty optional to me ? 20:19:40 ttx, that's what I was asking - sounds like it's required for some use cases 20:19:42 annegentle: that's the devstack side 20:19:43 ttx: right now, certainly since it doesn't exist :) 20:19:51 jraim, ah! 20:19:58 jraim: where's the d-g side of that? 20:19:58 ok, so no use cases requiring it right now? 20:20:01 i think the reason for that requirement was to either make sure it gets done, or determine major obstacles; i don't think that process is far enough along yet to say it's served either of those purposes. 20:20:05 markmc: I have some use cases for apps that run on an openstack cloud 20:20:10 https://github.com/cloudkeep/postern#why-use-postern make it look like a client lib 20:20:11 jraim, that's where the confusion came from :) 20:20:12 markmc: we have some ideas about what an agent could enable, but nothing is done yet 20:20:26 sdague: not implemented 20:20:32 sdague: open question of whether we should block on it 20:20:40 sdague: devstack support up for review, no job yet, AFAIK 20:20:51 right, I think having the job is pretty important 20:21:00 markmc: understood, sorry about that. I just meant we have some ideas of problems we could solve with it, nothing done yet 20:21:07 because it demonstrates this can actually install and coexist with the rest of openstack 20:21:16 i think we have the requirements for good reasons ... and should probably defer again 20:21:19 OK, so it looks like we should delay voting until all requirements are filled 20:21:19 and revisit once it's done 20:21:20 russellb: I agree 20:21:25 ttx: +1 20:21:26 jraim, ok, so .. palisade :) 20:21:29 ttx: sounds good 20:21:36 jraim, does that become an horizon integration effort? 20:21:49 is there anything else the barbican folks need to cover before coming back to us ? 20:21:52 russellb: sdague when I looked at the gating job, it seemed like being in devstack was enough if you weren't part of enabled services? 20:21:58 markmc: that's my plan now 20:22:08 jraim: you can have a job that just runs on barbican that spins up devstack with barbican enabled 20:22:12 that's what we need here 20:22:18 and that does something 20:22:27 some minimal testing of any nature you like 20:22:28 "hey API, are you alive?" 20:22:34 right 20:22:34 would probably be sufficient at this stage IMO 20:22:41 #info Missing basic devstack-gate job 20:22:42 russellb: so we've been doing that to test our impl, where would we add that job? 20:23:00 let's chat details outside the meeting, happy to give pointers 20:23:01 jraim: there are a few examples of this; let us know in the #openstack-infra channel and we can point you at them 20:23:03 we did a little of that in just devstack with our exercises, but I'm happy to add it 20:23:06 russellb: great, thanks 20:23:15 jeblair: will do 20:23:18 basically you need 1) devstack, 2) devstack-gate, and 3) infra config 20:23:23 changes in those 3 places 20:23:23 ok, so we should defer the decision on this 20:23:40 russellb: (actually not devstack-gate for incubation) 20:23:42 ttx: agreed 20:23:43 jraim: I'll also help you draft the governance repo change that will serve as the base for the final decision 20:23:55 ttx: great 20:23:56 jeblair: i guess so, ENABLED_SERVICES is enough, you're right 20:23:57 I would like a single source of truth for API docs (not that I'm noticing disagreement, but just noting) 20:24:01 jraim: ping me when the devstack-gate stuff is covered 20:24:09 ok, devstack and infra config :) 20:24:18 anything else on that topic ? 20:24:22 annegentle: I think the goal is to migrate to docbook and remove everything else 20:24:38 russellb, btw, is it ok to merge into devstack not yet incubated project? 20:24:52 jraim: sounds good 20:24:59 jraim, minor thing, but it'd be good if statements like "The Postern agent is capable of presenting these secrets in various formats to ease integration." weren't in the present tense :) 20:25:09 jraim, from https://wiki.openstack.org/wiki/Barbican/Incubation 20:25:17 errr ... i guess you can do devstack support as plugins, not actually as a patch to devstack itself 20:25:24 markmc: yeah, I'll go back and clean that stuff up. The only impl we ever had was a PoC that couldn't be run in prod 20:25:28 that's how solum has it for example, and they have a devstack-gate job 20:25:34 ok, moving on 20:25:34 jraim, cool 20:25:37 yeh, solum is actually a good example 20:25:38 SergeyLukjanov, russellb: yeah, i think that's the way devstack wants to go for pre-integrated projects 20:25:44 makes sense 20:25:55 #topic Defining "designated sections" for DefCore 20:26:04 #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026413.html 20:26:16 In that thread I proposed that we approached this question in two steps 20:26:29 First we would answer the objective question: "which parts of each project have a pluggable interface ?" 20:26:41 Then, once we have that list, we could answer a second question: "where, in that list, is it acceptable to run an out of tree implementation ?" 20:26:42 a public pluggable interface 20:26:50 russellb: +1 20:26:56 Anyone against this two-step approach ? 20:27:21 nope, lgtm 20:27:21 well 20:27:35 I don't know that there was much agreement that this is going to ultimately be useful 20:27:37 right? 20:27:40 markmc: +1 20:27:43 e.g. http://lists.openstack.org/pipermail/openstack-dev/2014-February/026559.html 20:27:47 agree with markmc 20:27:56 I think we need to discuss how we feel about vendor specific modifications to the unpluggable bits too 20:27:59 also not entirely sure about that appraoch 20:28:00 "The request from the DefCore committee around designated sections would replace Section 2(i) in the above example. The external API testing that is being developed would fulfill Section 3." 20:28:02 what is "this"? designating at all, or using the plugin API? 20:28:05 as the designation 20:28:19 personally, the more I think about it - I'd rather us just be tackling the API testing part 20:28:31 markmc: can you describe? 20:28:38 markmc: just API compat and call it good? 20:28:50 API compat and a general "you must use the code" statement? 20:28:52 "include the entirety of the [..] code from either of the latest two releases and associated milestones, but no older" 20:28:59 that seems fine to me for now 20:29:05 include != "run" 20:29:05 that's the current statement right? 20:29:12 markmc: I'd prefer something along the lines of "include and run" 20:29:17 no point blocking progress on API testing on the "run the code" part 20:29:33 mikal, well, think of a distro - a distro can only include it 20:29:33 true 20:29:34 markmc: I'd be ok with that, and of course if the project accepts pluggable drivers use whatever you want as long as the API tests work 20:29:34 core or extensions too? 20:29:37 er, API core 20:29:47 I'm finding many of the cinder drivers don't succeed here 20:29:56 markmc: well, they run it by adding the relevant hooks (e.g. systemd start entries) 20:29:59 i think all this detailed listing of components (and trying to keep that accurate for all of these rapidly evolving projects) sounds like a nightmare 20:30:10 russellb: +1 20:30:10 and feels like overkill 20:30:20 russellb: and I'm not sure what/if it means 20:30:22 mikal, our users run the code 20:30:34 is the driving factor there some desire to have part of a project not be listed as core? 20:30:36 mikal: the deployed instances run it, distros only in testing. 20:30:40 hmm, I think this is not our game, though. Defcore is where those rules are defined... and they ask us to designate code sections. If you think that's not the right approach, you can fight that approach at DefCore level 20:30:43 markmc: i really liked your list comment about keeping what we say now, and go after anyone that the board doesn't feel is acting in good faith 20:30:44 markmc: I don't want someone re-writing nova in Java, and then saying they've included the python code by dumping it in a dir and therefore can use the trademark 20:30:45 mikal: Ubuntu OpenStack for instance. 20:30:58 i'm just trying to answer their technical question 20:30:58 mikal: +1 20:31:03 ttx: so why isn't the tempst gate tests our defcore test? 20:31:10 mikal, sure - I just don't think that's what we need to be going after right now 20:31:17 so maybe we only certify /installs/ of OpenStack 20:31:22 ttx: I mean, we define OpenStak by what we gate on 20:31:28 ttx: well can we give feedback to our resident board members? :) 20:31:34 jgriffith: realistically, I expect the defcore folks are going to lift tests from tempest 20:31:35 mikal, i.e. which is the best next baby step - firming up the "run the code" requirements or adding API testing requirements? 20:31:35 and folk that are intermediaries can say that their installer gets you a certifiable OpenStack ? 20:31:43 lifeless: the distros will want to use the trademark too 20:31:43 but lets take some concrete examples 20:31:54 dhellmann: yes, and I support that 20:31:58 markmc: but is the board expecting this to be a baby step, or the final answer for several years? 20:32:00 russellb: we can 20:32:01 ttx, we can and should give our feedback 20:32:01 sdague: I would hope so, but I'm saying is this all being made much more complicated than it should be? 20:32:20 for instance, tempest full doesn't pass on any of the hypervisors besides kvm (some pass almost all, but not quite all) 20:32:30 lifeless: me, too, but that means we need some way to certify the distros, no? 20:32:40 and it passes only about 60% if you have cells enabled 20:32:40 sdague: ahhh.... see where you're going 20:32:48 dhellmann: problem is that a distro is an installer basically 20:33:04 mikal, our feedback could be "we'd prefer to focus our (the TC) energies right now on helping you with API testing - come back later on the other stuff" 20:33:06 dhellmann: and installers can install both meets-requirements and doesn't-meet-requirements clouds 20:33:09 jgriffith: "we" don't define the trademark rules. The board does. We can voice our opinion, but that's about it 20:33:12 dhellmann: so 20:33:13 so that makes me scratch my head a bunch about what is Nova, if we consider all those options 20:33:22 sdague: so.... IMO you pair out what we gate on, thy Hypervisor things would have to be fixed if you want to run them and be "OpenStacK" cloud 20:33:36 ttx: understood.... 20:33:38 Personally I'd rather have the TC stay away from trademark usage rules 20:33:39 dhellmann: I don't think we can say 'you get the trademark only if ALL THE INSTALLS you do meet the requirements' 20:33:48 markmc: yes, but perhaps with a deadline? We ant to defer the other bit until the Juno release? 20:33:50 which is why we separated integrated from core in the first place 20:33:53 or decide for each project what is the actual API contract 20:33:53 lifeless: I don't think that's what I was suggesting 20:33:54 ttx: but defining "code components" is what I'm still trying to get my head wrapped around 20:33:54 s/ant/want/ 20:33:56 dhellmann: instead, I think it has to be 'you get the trademark if your default meets the requirements' 20:33:58 ttx: hard to stay away when tech details get wrapped up into defining it 20:34:00 dhellmann: or something like that 20:34:03 ttx: otherwise totally +1 20:34:13 lifeless: +1 20:34:23 I think we've gone pretty heavy on optional API, and need to reconsider that if we want interop 20:34:28 russellb: right. We can basically issue a statement saying this is not very convenient, and propose an alternate approach 20:34:37 sdague: +infinity 20:34:37 ttx, yes, we want to stay away from trademark policy decisions - I agree 20:34:40 ttx: fair 20:34:51 russellb: but if they decide to ignore our statement, we'll have to give them the technical answers they are asking for 20:35:04 boo 20:35:06 because I think we are better placed to answer them than they are 20:35:06 :-p 20:35:10 so didn't we try this with plugins vs modules etc 20:35:12 yes, that's true. 20:35:19 and ended up with terrible verbiage 20:35:30 we don't have to give the board answers :) 20:35:32 markmc: so you think we should pause and first propose an alternate approach ? 20:35:37 "this is a bad idea, we don't want to help" :) 20:35:46 markmc: sure. they will designate the code themselves then 20:35:46 markmc: that's kind of how i feel :( 20:35:57 I'm pretty certain if the consensus amongst us that this is a bad idea or not the right time 20:36:05 and that we should focus our efforts now on API testing 20:36:08 markmc: or how about "I can't help if you can't explain what you're trying to solve" 20:36:13 the board would take that on ... uh ... board 20:36:14 markmc: because frankly I'm still unclear 20:36:19 jgriffith: +1 20:36:35 markmc: *groan* 20:36:35 markmc: honestly, I'm also concerned that the parties driving this are basically part of orgs that don't give anything back (or much back) to the community as well 20:36:36 crazy idea, why not make the definition the docs rather than the code? 20:36:48 It seems to me that things like 'dont get the trademark if you rewrite in java' are better directly measured, rather than through awkward indirect means 20:36:50 markmc: at the very least we need to come up with an aswer detailing why we think it's a bad idea 20:36:50 * annegentle has to ask 20:36:58 sdague, I'd prefer to assume good faith 20:37:06 annegentle: this is mostly about interop of deployments though 20:37:08 because, honestly would some of this energy in defcore going into actually helping on test implementation 20:37:25 mikal: but you know how many software companies ensure legal contracts are bound by docs? 20:37:30 ttx: let's provide those details then 20:37:43 annegentle: no 20:37:53 do we have a volunteer to draft the TC response ("sounds like a bad idea") ? 20:37:55 mikal: so it seems like a write up away from code might be the better discussion ground than the code itself 20:38:04 and I think the fact that the vend diagram of people that work on the test tool chain for OpenStack have 0 overlap with the people working to define DefCore is probably a big part of the disconnect 20:38:16 sdague: venn ? 20:38:19 I suppose all of this falls out if you say: "Must use /API code from release and pass API compat test 20:38:20 lifeless: yes 20:38:21 mikal: often software companies state in the contract where they sell the product that the product can only do what the docs say 20:38:31 ttx: I think a review in governance would be a good way to do that 20:38:33 (well, not sure if often is correct, that's rather vague) 20:38:44 annegentle: oh, ok 20:38:45 That enforces what's "required" non-pluggable 20:38:46 mikal: sure. You still need to seed it with something 20:38:58 mikal: looking for someone to lead that 20:39:00 ttx: sure, I will draft something if no one else wants to 20:39:03 just wondering if the response is "code is too difficult to split in this way, let's try a document" 20:39:04 annegentle: the problem with natural language docs for enforcement is they are open to interpretation -- a test suite is not 20:39:10 * russellb nominates markmc :-p 20:39:16 dhellmann: true that 20:39:24 markmc is the other obvious candidate, but I can work with him on something 20:39:28 dhellmann: a test suite certainly is ... in that you can just fake the thing it talks too. 20:39:34 mikal, sounds good 20:39:37 dhellmann: that is endemic in vendor interop efforts. 20:39:40 lifeless: +100000 20:39:43 mikal: markmc sounds great to me 20:39:45 We basically need a DefCore delegate 20:39:50 lifeless: good to know 20:40:00 lifeless: sure, but it's at least easier for well intentioned players to do the right thing 20:40:01 ttx, that would be good - especially if it wasn't me or monty 20:40:03 ttx: I said at the HK board meeting I was happy to help them, they've never asked me for anything 20:40:06 gamers are going to always find a way around 20:40:10 ttx: so I stand by that 20:40:18 ttx: I can draft something with markmc's input for next week 20:40:23 mikal: i support you in this endeavor. 20:40:26 ttx, just sign up to the defcore-committee list, then 20:40:36 sdague: right, but if you look at e.g. http proxy bake offs, for decades now, every single commercial vendor targets the test suite specifically. 20:40:37 ttx, meeting notifications go there ... mostly, I think 20:40:40 sorry 20:40:46 mikal, ^^ that's to you 20:40:46 sdague: we're going to see exacrly the same thing. 20:40:54 mikal: would you be willing to follow DefCore work and act as a TC interface there ? We badly need someone 20:40:59 mikal, I don't have any more insight into anything than what goes across that list 20:41:01 markmc: this is the first I've heard there's a list. I will give it a try 20:41:05 ttx: sure 20:41:09 mikal, cool 20:41:12 mikal: awesome 20:41:14 mikal, http://lists.openstack.org/pipermail/defcore-committee/ 20:41:16 ttx: until we find someone better... 20:41:23 mikal: thx for volunteering ;) 20:41:33 go go mikal 20:41:38 lifeless: so what's your alternative? 20:41:41 mikal: ^5 gogogo 20:41:54 yeh, thanks mikal 20:42:06 I may yet rage quit, but I'll give it a go 20:42:20 because given my bandwidth, i'm inclined to provide them the answers they want just because I don't have time to follow or suggest better routes. (lame, I know) 20:42:21 mikal: I'll subscribe to the list too and can be your backup 20:42:26 ttx: if that's ok 20:42:33 annegentle: thanks, I would love that 20:42:35 sdague: I'm just saying, we can't use the test suite as a proxy metric for other things; what it exercises *exactly* will be covered, other things - like corner cases - may well be all over the shop. 20:42:45 as long as there is someone tracking that effort closely, I think we are good 20:42:49 sdague: and it won't prevent the 'rewrite the plumbing' scenario on its own 20:42:55 mikal, annegentle: I've subscribed, too 20:43:00 ttx, you think it's easier to get those answers? 20:43:14 ttx, my assumption is we'll tie ourselves up in knots working out the answers? 20:43:23 markmc: it's compatible with my bandwidth. 20:43:39 ttx, ahm ok :) 20:43:48 ttx: let's let mikal have a chance 20:43:50 Ok, on the list 20:43:50 * russellb joined the list too 20:43:51 markmc: having TC delegates follow defcore and propose alternative solutions is 100x better 20:43:54 * markmcclain joined too 20:43:56 lifeless: it's better than not. At least those interfaces will be interoperable. Saying the problem is hard doesn't seem to me like a reason to throw in the towl 20:44:09 sdague: I wasn't suggesting throwing in the towel 20:44:21 sdague: I was answering '09:39 < dhellmann> annegentle: the problem with natural language docs for enforcement is they are open to interpretation -- a test suite is not 20:44:33 ttx, I'm happy to have them join! 20:44:35 I know mikal feels strongly about this so I trust him to follow that closely :) 20:44:35 sdague: which I read as a suggestion to use a test suite instead of english. 20:44:49 sdague: which is iMO a mistake - its not either-or, its both. 20:44:54 if tenant == testing: do_the_thing_it_expects() else: do_the_thing_we_want() 20:45:00 tests not foolproof solution either :) 20:45:02 russellb: exactly :( 20:45:04 russellb: thats my point 20:45:09 but a good step forward 20:45:15 lifeless: do you have an alternate solution though? 20:45:17 zehicle: I think having clear TC delegates will help solving the communication issues we had in the past 20:45:20 sure, I'm not saying they are. I'm saying they are a good first step 20:45:23 please let us know who is going to join, yes 20:45:24 mikal: the test suite is a good thing to have. 20:45:32 and it moves everything in the right direction 20:45:33 russellb: right so the thing is that we would not merge code that does that 20:45:33 mikal: prose saying what we mean is a good thing to have. 20:45:34 and for docs I was not really thinking of narrative but of reference docs like API docs, config reference, etc. 20:45:39 mikal: I think we should have both. 20:45:48 jeblair: not upstream, but downstream there could be ... i'm being extreme 20:45:51 to try to get closer to "truth" 20:45:58 russellb: which is why i think that the "you must run openstack" is the stronger part of this 20:46:15 jeblair: +1 exactly 20:46:15 zehicle_at_dell: I'm going to draft a quick email explaining our plan to that list after this meeting 20:46:19 #agreed mikal will act as TC interface to follow the DefCore effort and channel TC views. with annegentle as substitute 20:46:26 saying you must run it, sure, defining it in a lot of detail sounds like a rat hole i'm not sure we'll get out of 20:46:32 thanks 20:46:34 * ttx feels better about this 20:47:02 more on this, or can we jump on the next topic ? 20:47:28 or is that jump to ? 20:47:29 vote jump 20:47:31 ttx: jump! 20:47:36 * russellb jumps 20:47:37 #topic Integrated projects and new requirements: Nova 20:47:44 #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026450.html 20:47:51 oh 20:47:59 russellb: you jumped 20:48:03 russellb: jump back 20:48:03 As we raise requirements for new incubating projects, it was suggested that we should review existing integrated projects to make sure there was a plan to cover any gap 20:48:04 * dhellmann wonders if russellb has jumper's remorse 20:48:10 * russellb jumps back quickly 20:48:18 I suggested we started the process with projects where the PTL is also a TC member: Nova, Cinder, Neutron 20:48:26 russellb: did you prepare an answer for Nova yet ? 20:48:26 so, nova meetup this week means i haven't had a chance to write up an analysis of Nova vs requirements 20:48:29 i did not :( 20:48:30 haha 20:48:50 no biggie, I have another topic up my sleeve 20:49:02 ok, yeah, let's start that next week 20:49:05 unless another project is ready 20:49:06 (sorry) 20:49:10 jgriffith, markmcclain: you shall be next, so plan to prepare that in the coming weeks 20:49:34 #topic Minor governance changes 20:49:40 * markmcclain can't wait to write the duplicated functionality paragraph 20:49:51 markmc: I know, right 20:49:52 * Add some REST API graduation requirements (https://review.openstack.org/#/c/68258/) 20:50:04 that was markmcclain, not markmc 20:50:22 So.. on that one... Had a question there about requiring API stability at graduartion time vs. art release time 20:50:22 ttx, I'll mark as WIP - I think these should be "after graduation, before first release" as you say 20:50:33 ttx, which would be a new section 20:50:39 markmc: looks like we need one yes 20:50:59 ttx: and I wondered about "stability for which version of the API" and timing of that stability 20:50:59 BUT note that we don't review stuff between graduation and release. That happens automatically 20:51:09 hard to enforce that, but at least good for setting clear expectations 20:51:29 i.e. once we said "you will be in the next release", it would take a pretty bad event to make us not follow up on that 20:51:38 would this be a good time to a graduation question? 20:51:41 because we communicate a lot around that 20:51:50 NobodyCam: wait for open discussion 20:51:51 ttx, yeah 20:51:53 :) 20:51:59 and we invest a lot around that 20:51:59 ttx, I guess at graduation, we're just looking for a commitment 20:52:14 markthere is still value in detailing the post-graduation tasks 20:52:19 I think we need to separate out 'stable' vs 'finished' - nova is on v3 for instance 20:52:22 things evolve 20:52:27 markmc: is there any reason not to hold graduation until a 1.0 API is complete? 20:52:35 damn my markcompletion powers are broken today 20:52:43 dhellmann, just that we've not done it before 20:53:11 we've not had most of these guidelines before, right? 20:53:16 markmc: example post-grad tasks would be: get into horizon proper 20:53:25 ttx, yeah 20:53:38 markmc: so feel free to add them to the doc 20:53:45 markmc: have we had a project release without a 1.0 API in the past? 20:53:46 dhellmann, I think we're mostly just documenting existing expectations and firming up them a little 20:53:57 dhellmann: rigth, but I think we commit to supporting the API at release time, not really before 20:53:59 dhellmann, stable API would be quite new 20:54:05 ttx, add them back you mean 20:54:11 ok 20:54:17 sdague, we're talking about graduation, not release 20:54:44 oh, right 20:54:48 dhellmann: in particular, if integration with other projects creates a need, that should be adressable in the initial API version, not a second one 20:54:59 ttx: good point 20:55:08 mikal asked a good question on the review 20:55:13 dhellmann: what we want for graduation is a pretty-compete APi. Not a stable one 20:55:16 Yes, I am smart 20:55:18 what if we have a project that we want to be integrated, but doesn't need a REST API 20:55:20 complete* 20:55:28 russellb: or an API at all 20:55:31 deal with that as an exception if/when it comes up? 20:55:34 russellb: could you make up an example ? 20:55:44 gantt in theory ... we may want to use rpc only for that 20:55:46 russellb: yeah, exceptions ftw 20:55:54 exceptions is a reasonable answer for me 20:56:02 well, I think we've always said that incubation is for "server projects" 20:56:04 those rules are moving grounds anyway 20:56:08 which imply API 20:56:09 Or we could just word this differently 20:56:15 "If the project exposes an API..." 20:56:19 and an inter-project RPC API would be a new thing 20:56:27 think we'd want the TC to vet that 20:56:27 yeah, *punt* 20:56:33 deal with it if/when it comes 20:56:39 gantt nowhere near anything we need to review here 20:56:51 All the other governance changes, i'll approve when they reach enough approvals: 20:56:55 * Add a requirement for deprecating duplicated code (https://review.openstack.org/#/c/70389/) 20:56:59 * Add missed mission statement for Data Processing (https://review.openstack.org/#/c/71045/) 20:57:02 * add identity mission statement (https://review.openstack.org/#/c/71271/) 20:57:06 * Oslo program changes (https://review.openstack.org/#/c/72335/) 20:57:27 Unless someone has a comment about those, we can move to open discussion ? 20:57:41 ttx, "mission statement for Data Processing" needs one more iteration on my side 20:57:58 SergeyLukjanov: sure, but I don't think it needs to be re-discussed at a TC meeting 20:58:14 ttx, yup, just wording 20:58:15 so we can go on and approve it once it reaches the approvals on the review 20:58:20 #topic Open discussion 20:58:24 We're still missing a number of mission statements 20:58:30 (object store, image service, dashboard, networking, block storage, telemetry, orchestration, infrastructure) 20:58:32 NobodyCam, ^^^ 20:58:37 Would be good if the TC members could lead by example here, before we start chasing the individual PTLs 20:58:37 quickly: graduation question: are items like the nova driver (which are mainly out of our control) and migration scripts required to land for projects like Ironic to graduate? 20:58:45 So jeblair, markmcclain, jgriffith: would be great if you could propose a mission statement addition to the governance repo 20:58:56 NobodyCam: yes 20:59:04 NobodyCam: there is a governance change up for review that covers this 20:59:04 NobodyCam: I frel like the nova driver would meet the "deprecated code removal" test 20:59:07 ttx: ack 20:59:09 s/frel/feel/ 20:59:10 NobodyCam: https://review.openstack.org/#/c/70389/ 20:59:17 very much applies to the ironic case 20:59:22 ttx: will do 20:59:23 russellb, might be good to clarify your exact expectations e.g. around dates 20:59:28 russellb, it's getting tight 20:59:30 ack :) 20:59:37 markmcclain, jeblair: cool, thx 20:59:41 ttx: i believe the wiki has the statement that the tc approved, i will push that. 20:59:43 well ... before we do graduation review? 20:59:49 What happens in the ironic case if they fall out of the hypervisor support matrix and get deprecated? 20:59:49 jeblair: ack 20:59:49 ttx: how much of a requirement is it for a project considering incubation to have a program decided upon? Is that a hard requirement for a review? 20:59:56 Does that imply unintegrating ironic? 21:00:08 Thank you 21:00:09 Cause that ties the nova team's hands on driver quality... 21:00:20 russellb, more about freeze date for the driver, what you need to deprecate the old baremetal stuff in this release 21:00:24 annegentle: an incubated project needs to be covered by a program yes, it's one of the requirements 21:00:38 annegentle: if none existing, would create a new one 21:00:41 mikal: i don't believe ironic is integrated; it is in incubation. 21:00:41 russellb, perhaps it's obvious, but no harm in spelling it out - I think there's confusion 21:00:42 ttx: but if they are not sure which to apply under, can that be part of the discussion? 21:00:48 ttx: ok that's helpful too 21:00:50 jeblair: usre, this is a future thing 21:01:01 markmc: i guess i've largely been relying on the ironic folks on this 21:01:04 annegentle: we just make the team official, basically. 21:01:08 ttx: just wasn't sure if it's a push or pull (programs recruiting vs. projects looking for a home) 21:01:12 ok, no time left 21:01:15 both ? 21:01:17 Thanks peoples 21:01:23 #endmeeting