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