20:01:23 #startmeeting tc 20:01:23 Meeting started Tue Dec 10 20:01:23 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:27 The meeting name has been set to 'tc' 20:01:31 o/ 20:01:31 Our agenda for today: 20:01:39 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:03 #topic Assert control over website and memberdata systems 20:02:10 #link https://review.openstack.org/#/c/58072/ 20:02:19 mordred: did you post a thread about that anywhere, yet ? 20:02:29 I guess we can still discuss it... 20:02:33 mikal raises a good point that there hasn't been a recent thread on that 20:02:36 ttx: I did not. 20:02:53 sdague: that prevents us from closing the vote, but not from having a discussion about it 20:02:57 ttx: I got in a twitter fight about it, but I don't think that counts :) 20:03:08 mordred: is there discussion elsewhere? heh sdague oh I'll look for that one then 20:03:10 sdague: :) 20:03:11 mordred: care to summarize the issue ? 20:03:37 the issues is - the website and the membership system are run by thefoundation and not part of infra at all 20:03:55 that means that there are, effectively, project resources which are not under our technical governance 20:04:05 which I think is unacceptable 20:04:18 mordred: there is a distinction between project resources and foundation resources 20:04:41 jbryce: is the foundation membership system required to check in code? 20:04:45 mordred: and they actually have different requirements that come into play 20:05:04 jbryce: because if it is, it should be under the governance of the project 20:05:08 jbryce: is there? When I read the charter as a result of that motion being put up, I didn't see one. 20:05:12 mordred: if that's the biggest issue maybe we could get some help on the review to get the id system moved into infra 20:05:22 mordred: https://review.openstack.org/#/c/53644/18 20:05:27 jbryce: we're going to be on that right after this :) 20:05:28 jbryce: the foundation is the seat of everything, and then the subsection labelled 'technical' is carved off, lock stock and barrel. 20:05:42 jbryce: that change is merged. and it had SO MUCH HELP. 20:05:44 jbryce: the other thing is - the source code that runs the website, and I don't mean the content in the website 20:05:59 jbryce: i would call that a triumph of community development process. :) 20:06:04 should be open source and in infra 20:06:24 jbryce: i think everything should be run that way 20:06:37 jeblair: run which way? 20:06:46 we have one of the best dev systems in the world, that is one of the most openly collaborative 20:06:54 we should use it for development 20:06:55 mordred: while I think it would be better if it was open source and under infra, I don't think anything forces them to be 20:06:56 jbryce: the direction the id system is heading. 20:07:17 o/ 20:07:44 ttx: 'technical governance of the project' - I'm pretty sure that source code running the project's website meets that definition 20:07:58 unless we're saying that the website is the website of the foudation 20:08:05 ttx: i agree with mordred's reading of the bylaws 20:08:18 how is the foundation distinct from the project? 20:08:19 mordred: there is actually utility for both the project and the foundation in having some distinction between the resources 20:08:34 mordred: I think that's jbryce's argument ("foundation website") 20:08:48 jbryce: is openstack.org not the web site for the openstack project? 20:08:50 * russellb has a hard time understanding why anyone would *not* want infra running all this stuff 20:08:55 russellb: ++ 20:09:03 mordred: anyway, i would rather have those resources voluntarily placed under infra/TC than being forced to 20:09:10 ttx: I would to 20:09:11 too 20:09:11 russellb: it's not that we don't want it running in one way or another 20:09:20 ttx: me too, and i thought we had come to an agreement about that > 1 year ago 20:09:20 russellb: yeh, that's the camp I'm in as well 20:09:37 also, I'd like it if the website wasn't running on a proprietary system, but instead ran on openstack 20:09:40 BUT 20:09:48 the teams working on it have been moving that direction over time 20:09:49 I'm willing to defer even talking about that 20:10:13 and the id portion is a very big piece of the member system that they are attempting to split out completely in the new model 20:10:27 running in infra and through gerrit from the get go 20:10:34 awesome 20:10:40 that's awesome, honestly. 20:10:47 jbryce: ignoring what the bylaws may or may not say on the topic, would you agree that those should be placed under infra program ? 20:10:48 I just don't understand why the existing git repos can't be moved 20:11:19 if we can agree that moving this stuff under infra would be good for its own sake 20:11:27 then it would be awesome to avoid a bylaws debate :) 20:11:30 ++ 20:11:48 I'd rather not have the TC asserting its understanding of the bylaws tp force the hand of anyone 20:11:53 to* 20:12:03 and have people voluntarily converge 20:12:13 ttx: i think that would be swell 20:12:54 so is it a problem of the migration not going fast enough, or the idea of migration being completely refused ? 20:13:08 ttx: that's what i was just going to ask 20:13:28 I'd say it's going so slow as to amount to being politely refused 20:13:37 it's been a year since we started discussing it 20:13:47 moving a git repo without making any other changes at all to deployment 20:13:48 * ttx feels like an arbitrator now 20:13:52 takes about 30 minutes 20:14:30 if that happened, then sdague could submit a patch when he notices a problem with the profile page, and everyone is happy 20:14:51 here's what I'd like 20:14:55 jbryce: do you agree with the idea of a migration ? and if yes do you think it could happen faster ? 20:14:59 I ask - because people ask us when stuff goes wrong, because they assume we run it 20:15:01 if there is consensus that the operation should all be moving to -infra 20:15:11 I also think things came to a head when openstack.org had a big outage last month 20:15:16 yup 20:15:18 more than one 20:15:20 and people streamed into -infra asking what was up 20:15:22 lifeless: that's what we must first establish 20:15:25 then I'd like there to be - asap - like by next week - a set of bugs in -infra, which when all closed, will mean that all the ops is in -infra 20:15:27 and people pinged us immediately 20:15:37 I don't think we need to talk -at all- about the mechanics of moving 20:15:47 lifeless: agree 20:15:57 as long as there is consensus that we should, and a public list of what work - so we can see it being burnt down. 20:16:02 sdague: sorry... wrong number 20:16:06 sdague: just sayin 20:16:23 ttx: I bring this up because the discussion is getting into implementation. 20:16:30 sdague: people "ask infra" is not a good reason IMO 20:16:30 ttx: in general terms yes, but again there are many additional restrictions on foundation resources than on the project resources 20:16:38 ttx: and since mordred has agreed, we can now focus back on the broad consensus question 20:16:53 jbryce: can you clarify what that even means? 20:16:54 jbryce: like what, if I may ask? 20:17:01 jbryce: can you elaborate a little? 20:17:04 heh 20:17:08 jinx 20:17:21 jbryce: because I don't understand the distinction you're drawing; the technical subpart of the project is in the bylaws 20:17:21 * markmc had same typed too :) 20:17:39 the website/member system/foundation database are basically all in a single datastore currently 20:17:48 jbryce: so, the first thing I want to understand, is what is a 'foundation resource' vs a 'project resource' 20:17:52 this is what the team is working on breaking into separate pieces 20:18:14 individual members are legally members of the foundation 20:18:19 jbryce: thats interesting work, but I don't understand the relevance to the broad discussion, probably because I don't understand the distinction again. 20:18:20 ATCs are a subset of that 20:18:28 jbryce: right. but we're not suggesting moving the operation of that data store - just the source code 20:18:44 I would personally rather not have access to that database 20:18:59 there are contractual and legal requirements about access and control of the data and the systems that have access the data 20:19:12 jbryce: if mordred were to rasie a thread about this on -infra or -dev, would you be willing to publicly map the remaining tasks to complete to migrate the stuff ? Then we can understand the steps and check progress... 20:19:18 mordred: I think you're jumping ahead of the discussion - and I'm 100% sure you know a lot more about the plumbing than the rest of us; could you perhaps let us learn :) 20:19:22 I'm not 20:19:28 this is where the confusion lies 20:19:44 I'm NOT saying that we should take over operatoin of all of the things that have potential legal ramifications 20:20:11 mordred: you are saying that 'The management of the technical matters relating to the OpenStack Project shall be managed by the Technical Committee. ' applies 20:20:20 lifeless: ok. fair 20:20:21 that this is a technical matter, which we should be managing 20:20:27 * mordred shuts up - passes mic back to jbryce 20:20:37 running ops of a secure database with legal ramifications is a supremely technical matter 20:20:47 lifeless: is a sponsorship contract between a corporation and the foundation a matter of the project? 20:20:58 that it needs to be only accessed by specific personal due to legal issues is a huge and important constraint 20:21:37 so in order for me to say 'hey, mordred, I agree with you', I think we need to understand why some bits count as 'technical' and others don't 20:22:08 lifeless: right. and to be clear - I thnk it's not that the bits are technical - I think it's key that some of them are technical parts of the project 20:22:22 I do agree with jbryce that there are potentially technical bits that are not part of the project 20:22:25 lifeless: or a proprietary operations data a user has submitted under the condition that it only be shared with the foundation 20:22:25 mordred: i think that's a key distinction 20:22:26 to take a step back 20:22:51 i don't think any of us is against the idea of moving repos to follow the standard contribution process 20:22:57 jbryce: I don't know! This is why I'm asking these 'please define stuff for me' questions! 20:23:09 we are not against running resources on -infra resources where possible 20:23:32 because it's not clear to me why a git repo for running a foundation-but-not-project website would be a technical matter for the project 20:23:35 BUT 20:23:40 the ops of said website wouldn't be 20:23:54 there's no bright line I can see [yet] that delineates one but not the other 20:24:22 I think ultimately, once the legal bits are segregated, that there is no difference 20:24:47 mordred/jbryce: I think the main issue is the absence of roadmap -- it's difficult to comment on how fast we go (or how blocked we are) if you don't even agree on the list of work items 20:24:51 part of that is that I don't actually understand the difference between 'the foundation' and the 'project' except that the foundation exists to nurture the project 20:25:00 ttx: ++ 20:25:06 ttx, yep 20:25:15 mordred/jbryce: so to move on, I'd like you two to participate in an open ML thread on the topic 20:25:30 ttx: ok. shall I start that? 20:25:43 mordred/jbryce: see if we can converge at least on the list of steps and the limits 20:25:53 In principle, could infra run the website and delegate back to *only foundation staff* all potential access to the legally sensitive bits? 20:25:59 and maybe rather than debate the meta issues in the thread 20:26:06 markmc: yes 20:26:06 focus more on what systems could next move to infra 20:26:10 and what one's can't 20:26:17 if so, I could see an easy line of 'it's technical -> infra' but also 'this is legal -> only foundation staff touch' 20:26:20 if incidental access to a sensitive database was required for infra-root, i'm sure we'd be willing to accomodate legal and technical requriements. we already maintain high standards of access to systems that we run. 20:26:28 well - yes - there is one thing though ... I _do_ at some point want to establish, possibly in this thread 20:26:40 which bits are actually under the governance of the TC and which bits are not 20:26:40 because I think I agree with both of you I think. It should be infra/open source wherever it can 20:26:40 i do have a problem with a broad assertion about tc oversight in anything that could be classified as "technical" and is necessary for the operations of the foundation. so i think the scope issue is very important 20:26:52 jbryce: would that sort of chain work for the foundation, from a legal perspective? 20:26:52 roadmap for implementation of getting them pysically controlled stems from that 20:26:53 lifeless: in other words, to your suggestion: possibly; but i'd like to explore the idea of a flat structure because i think it could work. 20:27:05 jbryce: I think I'm with you on that 20:27:06 because I do not believe we are in agreement on that point yet 20:27:15 jbryce: yes, I think we have to recognize that the Foundation is different from the Open source project 20:27:18 jbryce: I want to understand the scope issue too ;) 20:27:22 jbryce: exactly 20:27:32 jbryce: to be clear, I don't have a specific axe to grind here, I'm doing my best to understand it all :) 20:27:33 jbryce, right, I'm saying if we all put that assertion aside for a while we might make more concrete progress 20:27:35 jbryce: I _don't_ think we have oversight of all things technical that the foundation might do 20:27:50 I'd like to figure out which ones we do have oversight of though 20:28:00 mordred: ok. let's work on that 20:28:03 mordred: I'd like to figure out a rule for figuring them out ;) 20:28:06 ok, let's move on 20:28:10 jbryce: ++ 20:28:11 if possible 20:28:18 #action mordred to start public thread on that 20:28:42 #topic Barbican incubation request (initial discussion) 20:28:58 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020830.html 20:29:08 #link https://wiki.openstack.org/wiki/Barbican 20:29:14 * ttx can stop juggling with his hats 20:29:23 As usual we'll do this over two meetings 20:29:39 The first one we'll discuss and raise the main objections, so that the Barbican team can address them in new threads 20:29:49 The second one we'll do the final review and push for votes 20:30:15 hm, i seem to recall a bunch more information added to the wiki 20:30:17 was it a different page? 20:30:19 jraim: ^ ? 20:30:29 scope, mission statement, for example 20:30:30 I looked at this request and I have a number of issues with it 20:30:32 russellb I added a bunch to the incuation section 20:30:41 #link https://wiki.openstack.org/wiki/Barbican/Incubation 20:30:48 https://wiki.openstack.org/wiki/Barbican/Incubation 20:30:50 yep 20:30:58 ah yes thanks 20:31:03 I can move it out to the main page if we like it all 20:31:11 My main objection would be similar to the one we rejected Designate for 20:31:24 68% of commits coming from the same person 20:31:34 96% of commits coming from a single company 20:31:44 which makes it a bit brittle 20:31:55 if said company or individual were to move on 20:32:07 Rack has 3 FT devs, 1 FT test in addition to product / doc writers 20:32:22 We've had some interest from other groups in contributing 20:32:29 I'm hoping that incubation will help that process along 20:33:05 this is the same chicken and egg problem, tbh 20:33:25 and I think we're going to have to sort it out at some point - it's not going to keep not coming up 20:33:25 jraim: yes, unfortunately we don't have a status for that "attract contributors to this promising thing" state yet 20:33:46 My plan is to propose one such state very soon 20:33:48 so we have a new set of guidelines we're working up 20:33:53 Barbican request came before I could 20:33:54 ttx understood, but I think we have a strong team working the product now. That should allow us to attract developers over time 20:33:56 looks like barbican falls short of them to me 20:34:00 actually, I don't thinkn we need a new one 20:34:05 like - no tempest thirdparty tests yet 20:34:06 ttx I'd agree with you if there wasn't already a team on it 20:34:08 lifeless: a number of them actually 20:34:09 we take programs without incubating them 20:34:15 tripleo is one 20:34:17 it has projects 20:34:22 lifeless: it's actually devstack-gate for pre-incubation 20:34:27 if those projects want to be incubated 20:34:28 tempest comes after 20:34:28 it has to propose them 20:34:33 so I think we have the structure already 20:34:34 russellb: a number of requirements; or a number of proposed sets of requirements? 20:34:41 lifeless: d-g is also missing 20:34:44 we can accept the program proposal from barbican 20:34:52 mordred: so you think they should apply for a program first ? 20:34:53 sdague: right, I was using an example :) 20:35:04 lifeless: barbican is missing a number of the things we have listed requirements 20:35:06 We do have a pretty good integration test suite. It uses the CloudCAFE testing framework 20:35:06 which would make them 'official' and people could work on them - but the repo barbican is still not incubated even 20:35:07 jraim: what kind of feedback are you getting from other groups about their interest in barbican? 20:35:07 a number in progress already 20:35:08 ttx: yes 20:35:12 russellb: right - I think we agree :) 20:35:17 russellb: I think you did a good job higlithing that in your thread, I see the list of tasks at "Tasks for Incubation" to be pre-incubation requirements 20:35:20 mordred: I have several objections to that... 20:35:24 ttx: beeause I think that accepting the program means we agree on the need 20:35:26 sdague: yep 20:35:27 so it seems premature to be doing this until those are done 20:35:36 jeblair I'm seeing a lot of desire for the features we can help with. e.g projects wanting to provide encryption services 20:35:38 that's my opinion, yes 20:35:46 we could give it a "promising" status if we can come up with one though 20:35:50 ttx: okj 20:35:53 gah 20:36:00 jraim: what happens when you ask them to commit resources to it? 20:36:06 mordred: that means they would place themselves under the TC authority even if they get rejected from incubation ? 20:36:16 ttx: welcome to the jungle, yeah 20:36:32 ttx: again - tripleo is under tc authority, none of their repos are integrated 20:36:35 or incubated 20:36:49 mordred: trying to wrap my head around it 20:36:57 jeblair We've had good responses (from swift for example) when we asked if they would be interseted in merging encryption patches 20:37:12 we don't have it listed in our requirements for new programs, but I'm surprised ... 20:37:13 mordred / ttx : that seems like a meta discussion for another day 20:37:17 jraim: what is "good response"? 20:37:20 integration is for the integrated release 20:37:31 would have thought diversity and viability of the new program's team would be just as important 20:37:36 programs are for initiatives we see that we need with teams built up around them 20:37:37 mordred: so programs could be about scope and incubation about maturity and integrated scope fit 20:37:39 jgriffith ptl said he would be willing to merge the patches and gave us guidance on what they would need to look like 20:37:41 jraim: this line of thinking still gets me to barbican being under another umbrella, perhaps a security program 20:37:46 markmc: it was in there at one point .. 20:37:47 jraim: thanks 20:37:47 projects are deliverables of programs 20:37:53 devstack isn't integrated 20:38:00 jgriffith We've also seen work from the APL guys on transparent encryption for cinder which seemed reasonably well received 20:38:02 nor is infra 20:38:10 jraim: ;) 20:38:23 jraim: I'm vaguely familiar 20:38:36 jraim: I assumed Cinder was the primary target here TBH 20:38:39 mordred: I guess approving program but not incubation could be one way out of this maze 20:39:03 jgriffith they are cetainly on the list, though I think the current approach is too limiting (e.g. tagged to libvirt) 20:39:12 jraim: so honestly, using cloudcafe ends up being probably long term problematic because you'll need to convert over to tempest for integration 20:39:25 ttx: 2 things: i think a program needs a diverse team too so may not be a solution; and are we straying from the topic? :) 20:39:29 jgriffith I want to see if we can enable transparent encyrption for all storage on a VM, not just cinder or ephemeral, but both with the same code. 20:39:35 jeblair: ok 20:39:52 jraim: we should chat off meeting sometime 20:39:53 Let's discuss scope for a bit 20:39:54 jraim: I think it's fine you've got a writer started, I want to provide a template approach for other projects who want to plug into openstack docs eventually 20:39:55 jraim: jgriffith probably off topic :) 20:40:07 sdague this seems to be a conversation we have to have. I'm assured that the CloudCAFE tests can be run in the gate. IF that's not true, we obviously have a problem 20:40:18 jgriffith will do 20:40:19 jraim: could you explain where barbican actually stores data ? Swift ? Cinder ? Own data store ? 20:40:23 russellb: and thus my "we should chat off meeting" 20:40:25 jraim: you have been asured incorrectly 20:40:33 jraim: what sdague said 20:40:33 annegentle she said she was going to touch base with you, but happy to talk more 20:40:36 jgriffith: yep, latency. 20:40:58 russellb: but tbh the majority of comments of late are "off topic" 20:40:58 ttx we store data in our own database. We also allow an optional HSM to be used to secure that data store 20:41:38 jraim: what sdague says is true 20:41:39 jraim: is there any reason to believe the sort of auditable and secured storage features you have in Barbican wouldn't make sense as part of... say... swift ? 20:41:41 sdague than I agree that is a major problem. I agree that our integration test suite must be run as part of the gate. If CloudCAFE won't work, we'll have to move it 20:42:12 jraim: we do testing in openstack with tempest. there is nothing stopping rackspace from running cloudcafe as a third-party thing 20:42:29 jraim, how would you compare Barbican capabilities to similar capabilities offered by existing public clouds (like AWS CloudHSM) ? 20:42:33 (or anyone else, for that matter) 20:42:34 ttx all projects will expose their own end user services (e.g. encryption, auditing, etc). Barbican offers a way for services to deliver those services in a much easier way 20:42:41 AFAIK, you can't write third-party tempest tests though, can you? 20:42:46 jraim, not so much about quality or anything, but what's Barbican analogous to ? 20:42:51 doesn't have a plugin mechanism or something 20:42:53 russellb: we don't have a stable internals api 20:43:08 so you could... but it was be rebase chasing 20:43:10 so up and coming projects, for now, have to write an independent suite of some sort 20:43:11 mordred true, but all our integration tests are currently in CloudCAFE. Sounds like we'd need some or all of them in tempest 20:43:18 jraim: ++ 20:43:22 jraim: yes :) 20:43:29 point being ... we can't tell people they need to be in tempest 20:43:32 because you can't do that 20:43:34 except you can put them in tempest until they are integrated. 20:43:34 russellb: so the d-g job idea was to have basic sanity 20:44:00 sdague: right, i get it, and i've been working through it with solum 20:44:03 markmc Barbican uses the same HSM that Amazon does. However, amazon is bascially provisioning you a slice of an HSM and allowing direct access. We use an HSM as a backend, but Barbican takes care of multi-tenancy and 'speaking openstack' 20:44:13 russellb: I think the line we took in the proposal was "some kind of job" in a d-g env for incubation, then tempest testing for integration 20:44:25 * russellb nods 20:44:41 right. so you could add tests to tempest in incubation, and would need to for graduatoin I think? 20:44:43 markmc Barbican is very similar to the software you would find in an HSM, just open-source and free. We do add some features and OpenStack integration, but the API is basically key management and generation 20:44:47 where "for" means prereq of 20:44:56 not during 20:44:58 jraim, cool, thanks 20:45:02 sdague: ++ 20:45:05 point is, tempest won't accept tests pre-incubation AFAIK 20:45:09 sdague: I agree with that 20:45:13 russellb: yes, that's true 20:45:14 so it's kind of all mixed up 20:45:17 jraim: thx for the explanation, solves most of my scope concerns 20:45:31 jeblair: *cant* put them in tempest until they are integrated? 20:45:32 but yes, you can still do a basic devstack-gate job without tempest 20:45:41 devananda: correct 20:45:46 russellb: so honestly.... we have the problem that we have integrated projects that have no tempest testing :) 20:45:54 jraim: so the user cases are: give me access to my encrypted cinder volume? Or: give me access to the secret that gives me access to the cinder volume? 20:45:55 sdague: *nod* 20:45:58 wait. no. that's not what we just said 20:46:04 So it seems like we would want to move our basic integration tests over to tempest before graduation. CloudCAFE could still store additional tests as desired? 20:46:09 you can't put them into tempest until their incubated 20:46:17 s/their/they're/ 20:46:17 mordred: that 20:46:19 annegentle Users would access an encrypted volume thorugh cinder 20:46:23 and you can't write tempest tests outside of tempest 20:46:27 annegentle cinder would use barbican 20:46:32 devananda: what mordred said 20:46:35 sdague: and incubated projects taht want to be tested. but ... 20:46:36 and this is why I think we need to make tempest have a somewhat stable api 20:46:36 so you just need "something" 20:46:39 * lifeless opens the can of worms 20:46:40 for incubation IMO 20:46:44 lifeless: +1 20:46:45 right. so during incubatoin, one is expected to write tempest tests and put them there 20:46:45 wait. now i'm confused 20:46:46 devananda: incubated projects are fair game 20:46:47 lol 20:46:51 but just talking about what we have today 20:46:51 sdague: ack 20:46:54 annegentle users would use barbican directly for auditing, logging or recokation 20:46:59 mordred: yes 20:46:59 As it stands, I think cloudcafe is entirely fine for *pre-integration* 20:47:04 sorry 20:47:06 mordred: or port your stuff to tempest 20:47:07 annegentle customers of an openstack cloud would also use it for secret storage 20:47:08 *pre-incubation* 20:47:11 incubating directory in Tempest... separate tag and gate job (non-voting) 20:47:16 russellb: ++ 20:47:26 once the incubation switch is flipped, moving into tempest... 20:47:30 ok - we might be going off into the weeds talking about tempets extension mechanisms here 20:47:33 becomes a priority 20:47:35 but hopefully your devstack-gate job runs whatever you *do* have pre-incubation 20:47:36 russellb: or that :) 20:47:37 jraim, do you forsee pretty much all OpenStack services eventually depending on Barbican, sorta similar to how everything depends on Keystone 20:47:39 that seems reasonable 20:47:44 jraim: for your scope, do you expect an admin api and auditing capability before "completion" 20:48:20 * markmc notes the current topic is scope of the project, not tempest integration :) 20:48:33 yeh... we've gone off topic quite a bit 20:48:39 ok so to summarize 20:48:41 markmc I hope so. Most projects should / want to offer encryption services to customers. I hope that Barbican provides the ability to do that in a way that is secure, auditable and meets compliance requirments 20:48:54 it looks like the scope of the project is well-defined and makes sense 20:48:58 annegentle we have an admin api in the code now, we just haven't put anything in it yet 20:49:39 there are some concerns about time size/diversity and some work to be done before filling all the current requirements for incubation 20:49:45 ow 20:49:48 s/time/team 20:49:53 ~ 20:49:54 jraim, I guess that's implicit in the Future section of your Roadmap? would be good to list out the future potential integration points 20:50:03 markmc will do 20:50:09 jraim, excellent 20:50:33 ttx: agreed; my biggest concern is diversity. 20:50:35 I think we can discuss all that this week in the thread and move on to a final decision next meeting 20:50:48 any other concern that was not directly mentioned yet ? 20:50:49 i think you guys have done a great job responding to work items so far, so thanks for that 20:50:57 jraim: is hardware HSM testing required, or will software only (in the cloud) testing sufficiently test the project? 20:50:58 ttx I will reach out to some folks that have expressed interest and see if they can speak up 20:51:09 i'm concerned it probably won't all get done by next week, though 20:51:32 jeblair we offer a 'dev' hsm that is fine for testing in the cloud 20:51:34 so it may be worth talking about the program but not project idea a bit more on list 20:51:35 jraim: I'll explore the idea of applying to become an official "program", before applying for incubation 20:51:38 yeh, it seems like it might be better to table a vote until after that list got knocked out 20:51:41 jraim: thanks 20:51:42 ttx: +1 20:51:48 ok let's move on 20:51:56 #topic Incubation / Graduation / New program requirements 20:52:05 #link https://review.openstack.org/#/c/59454/ 20:52:11 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020844.html 20:52:17 #vote yes 20:52:19 I pushed a second version based on early comments. 20:52:29 The goal is to get to a consensual base version and then address new requirements as incremental change to this (living) document 20:52:35 * devananda perks up 20:52:40 It will be much easier to review incremental changes after the base one is in 20:52:47 So please check if there is any rule you disagree strongly with 20:52:47 ttx: +1 thinking about it -- like i said, i'm skeptical; i think a new program should have a diverse team too. i'm still mentioning this because it's current for this topic as well. :) 20:52:57 if you want more in there, propose them as future changes instead of blocking this one 20:53:01 "Project must have a basic devstack-gate job set up" 20:53:07 I do not disagree with the rule 20:53:08 Will approve it once it passes the required number of +1 20:53:09 BUT 20:53:26 as we're currently working on the early bits of tripleo-gate too - I think we might want to genercise that sentence? 20:53:38 gate job that runs some sort of functional testing? 20:53:41 hang on 20:53:49 can do that as a follow-up change though i think 20:53:51 not critical 20:53:56 right now, d-g is the only way things in the *integrated gate* get tested. 20:54:00 yeah. I'm not going to -1 it 20:54:01 It's entirely accurate as-is. 20:54:04 yes 20:54:06 it's fine to pass 20:54:08 just being that guy 20:54:11 ok 20:54:20 TripleO's deliverables aren't in the integrated gate, nor are they integrated or incubated. 20:54:21 and for most projects, something based on devstack-gate is how you'd add functional testing 20:54:22 yeh, let's clarify in post 20:54:31 Tuskar will be a project that we incubate soonish. 20:54:37 (a bit of a pain to be honest, but doable) 20:54:43 moving on then :) 20:54:45 And that will either go in d-g, or we'll revisit the language at that time. 20:54:56 #topic Other governance changes in progress 20:55:03 oh - wait 20:55:09 i refuse to wait 20:55:12 #undo 20:55:13 dammit 20:55:13 Removing item from minutes: 20:55:19 mordred: yes ? 20:55:25 Project must be compatible with all currently OpenStack-supported versions of python 20:55:37 good point 20:55:37 ttx that's amazing i've never seen that before. 20:55:37 I had quibbles with that 20:55:37 right, lifeless didn't like that one that much either 20:55:51 I think that should genericize 20:55:54 I can live with it, but I don't think it actually captures intent 20:55:57 jeblair: watch and learn 20:56:23 because aiui, we do not yet have a hard-fast-encoded rule about must be python 20:56:25 'I think this is trying to say 'must be deployable anywhere current OpenStack can be deployed today' using 'compatible with the Pythons we support' as a proxy - I'd rather we state the thing more directly.' 20:56:30 Is what I said in review 20:56:45 yeah, something like that works 20:56:46 mordred: how about you propose those in a subsequent change ? 20:56:53 ttx: ok. Iwill do that 20:56:59 it's not as if the document was binding us or anything 20:57:00 deployable where openstack is deployable today would imply no new requirements 20:57:04 which isn't terribly realistic :) 20:57:09 new projects introducing new dependencies is potentially ok, though 20:57:14 markmc: jinx 20:57:19 it's more of an hopefully up-to-date matrix to check and communicate to wannabees 20:57:19 :) 20:57:19 must comply with current TC software policies 20:57:36 we have those? 20:57:37 russellb: huh? no, it says that anyone coming in can't be incompatible with where we support deployments 20:57:39 markmc: yah 20:57:45 mordred, documented ? :) 20:57:46 mordred: all our integrated projects are python, and we have established supported python versions 20:57:49 arosen: that was my question too 20:57:53 i actually don't see a problem with it as written 20:57:58 let's get this one in, wil be so much easier to discuss additions one by one after that ;) 20:57:58 err... markmc ^^ 20:58:04 ttx: ok 20:58:06 #topic Other governance changes in progress 20:58:16 jeblair: something that doesn't work with the RH patched Python2.6 for instance, would that be a problem? 20:58:17 I approved the Compute program mission statement yesterday as we mentioned it at last meeting and it reached enough approvals 20:58:19 these are guidelines; they don't prohibit us from varying from them or accepting non-python projects, which will require some work anyway. 20:58:24 Alphabetize list of extra ATCs: https://review.openstack.org/#/c/58610/ 20:58:30 y 20:58:31 jeblair: even though it does work with vanilla Python2.6 20:58:33 lifeless: it already is. :) 20:58:40 I think that one shall be abandoned, given that the main use for this list is time-sorted rather than alpha-sorted, and it didn't get that much YESes 20:58:51 jeblair: I mean, would we reject their incubation on that basis? 20:58:53 lifeless, jeblair, that eventlet/subprocess thing is resolved now, btw 20:59:00 markmc: cool 20:59:05 lifeless, jeblair, and RH Python maintainers accept it was their screwup 20:59:12 will abandon if it doesn't get enough YES by EOW 20:59:16 #topic Open discussion 20:59:21 lifeless: i expect we should have a discussion about it and seriously consider whether to waive the requirement 20:59:30 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/021233.html 20:59:35 potential glance scope adjustment 20:59:38 jeblair: sure. I'm just saying we don't have to duplicate our current policies on that subject 20:59:40 not sure if of TC interest 20:59:41 jeblair: we can reference them 20:59:43 lifeless: in that case, i would consider that this list of requirements had the intended effect. 20:59:46 J naming poll coming up, waiting for the lawyers pass on proposed name 20:59:49 markmc: doit; you don't have enough on your plate atm 20:59:51 (go Jekyll) 20:59:56 bah 20:59:59 markwash: ^ 20:59:59 proposed names* 21:00:02 jekyll++ 21:00:17 markwash: I'm interested :) 21:00:20 Jekyll, indiana? 21:00:32 lifeless: jekyll island, georgia 21:00:33 markwash: thanks for the link 21:00:34 I mean, it has to be Indiana or Idaho right, for crazy names... 21:00:36 mordred: okay. :) it would be good if it pointed to something concrete though, so a new project would know what's expected. that's what this list accomplishes. 21:00:40 Jekyll++ 21:00:44 jeblair: ++ 21:00:45 done 21:00:56 ok, time is up 21:01:04 jeblair: I was really just trying to make sure that if we change them, we don't have to remember to do it in two places 21:01:13 #endmeeting