20:00:51 <jbryce> #startmeeting
20:00:52 <openstack> Meeting started Tue May 15 20:00:51 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:18 <jbryce> hi everyone
20:01:20 <ttx> haz quorum?
20:01:22 <vishy> o/
20:01:36 <danwent> o/
20:01:39 <jbryce> now we do
20:02:01 <jbryce> one quick question coming out of last week
20:02:40 <jbryce> since we agreed on an approach concerning 3rd party APIs, has that been communicated at all to any of those working on 3rd party API patches?
20:02:47 <heckj> o/
20:03:03 <vishy> jbryce: it has not, I will send out a message to the list outlining the options
20:03:12 <vishy> (for nova)
20:03:16 <heckj> notmyname made a reference to it on the list, but nothing else has flowed out as yet
20:03:28 <jbryce> ok
20:03:40 <notmyname> I've talked to the IBM people about CDMI on swift, and swift3 compatibility extraction is currently in-progress
20:03:52 <jbryce> #action vishy to send note out about 3rd party api plan
20:03:52 <devcamcar_> o/
20:03:58 <jbryce> vishy: thanks
20:04:18 <jbryce> notmyname: cool...those are ones i was wondering about
20:04:35 <jbryce> #topic completeness of core
20:04:52 <jbryce> ttx: do you want to introduce this one?
20:05:00 <ttx> Sure. As explained in https://lists.launchpad.net/openstack-poc/msg00513.html ...
20:05:19 <ttx> As several projects consider splitting some existing parts out, I think it's the responsibility of the PPB to make sure OpenStack Core (as a whole) remains complete and usable on its basic functionality
20:05:35 <ttx> The PPB accept projects in Core based on the features they bring, so it's fair that we watch to make sure those features don't dramatically change
20:05:36 <anotherjesse> ttx: I know jgriffith is here to talk about the cinder aspect
20:05:53 <ttx> There are two ways to split features out. One is to split into another Core project (like Cinder)
20:06:08 <ttx> The other is to split into a non-Core project (I suspect most of the Swift splits so far belong to this category)
20:06:30 <ttx> For the first category, last week we established the rule that the project split needs to be completed by the middle of the cycle (a.k.a. folsom-2). A Core project split also needs a dedicated team/PTL to pursue development on it
20:06:47 <ttx> In order to assess if a split is a core or non-core split, I suggest that proposed splits should be acked by the PPB
20:07:00 <ttx> Project teams/PTLs still get to decide what feature should be split and what feature should not...
20:07:19 <ttx> But we get to decide if a split feature is a Core feature or not. And therefore if it should be split into a Core project (with all the constraints that creates) or into an ecosystem project.
20:07:26 <ttx> Thoughts ?
20:08:06 <anotherjesse> ttx: I think maybe pbb should be an oversight not an active decider
20:08:34 <ttx> anotherjesse: it's sometimes hard to fix after the fact. And you may discover certain things late...
20:08:36 <anotherjesse> ttx: for instance in nova we might want to split volumes out to cinder and be core, but split cloudpipe out to a non-core project
20:08:51 <jbryce> how significant does a split need to be to involve people outside of the project?
20:09:15 <ttx> anotherjesse: that's perfectly alright to me. I just think the decision of removing features from core does not belong solely to the project
20:09:33 <ttx> since the PPB defines what's "core"
20:09:51 <anotherjesse> ttx: do you have an estimate of how much are we signing up for
20:10:06 <vishy> ttx: i think another possibility is for features to go into another core project
20:10:16 <ttx> vishy: indeed. Good point.
20:10:29 <ttx> which would be perfectly alright if both projects agree.
20:10:31 <devcamcar_> are we expecting to split anything else out in the near term?
20:10:51 <vishy> I think it is a bit much to assume that we should ack everything that wants to be pulled out, but perhaps there isn't really a lot
20:10:51 <devcamcar_> if not then I'd suggest treating a one off as such
20:11:19 <bcwaldon> mnaser: sure, that looks right
20:11:23 <vishy> there is one specific concern that started this, so lets just address the concern and move on
20:11:24 <bcwaldon> sry
20:11:25 <jgriffith> sorry... late
20:11:34 <heckj> vishy: ++
20:11:41 <ttx> as an example, swift splitting swift3 sounds sane. Swift splitting keystone auth, a bit less.
20:11:54 <vishy> notmyname: we were discussing keystone middleware for swift. Were you planning on pulling it out?
20:12:03 <anotherjesse> a core project that doesn't speak core auth doesn't make sense...
20:12:08 <notmyname> keystone middleware was never part of swift to begin with
20:12:21 <anotherjesse> notmyname: because keystone didn't exist until recently :-)
20:12:31 <devcamcar_> that's crazy to suggest removing keystone middleware from swift
20:12:34 <ttx> vishy: we could simply make the requirement that splits need to be announced on the ML some time before they are done... to let us intervene in case of need (oversight)
20:12:35 <vishy> notmyname: so it is currently in keystone. What about the changes to the client to enable keystone?
20:12:48 <vishy> ttx: that seems fine
20:13:03 <devcamcar_> all that does is say that swift doesn't care about the rest of the projects
20:13:04 <notmyname> vishy: the swift client is being removed from swift (into a separate deliverable for the swift project)
20:13:21 <vishy> notmyname: gotcha, but it is still managed by swift-core?
20:13:22 <notmyname> so that it can be developed separately and require other projects to have less dependencies
20:13:27 <ttx> anotherjesse: would that work for you ? Announce clearly in advance to let the PPB react if they don't like the idea ?
20:13:28 <notmyname> vishy: yes
20:13:57 <vishy> notmyname: I think the general concern is that if there is some part of a core projects that other projects are depending on, that we make sure it stays in core somewhere
20:14:03 <anotherjesse> ttx: yeah, I'm not against having pbb actively involved, it just seems like it would be a lot of work that isn't needed if there is a way like you just suggested
20:14:17 <notmyname> however, swift client libs and bins don't have anything to do with where keystone/swift middleware lives
20:14:40 <heckj> keystone/swift middleware is currently in keystone, no plans to remove it.
20:14:43 <anotherjesse> notmyname: so the preference of swift-core is that keystone integration would be a drop-in - not part of the project?
20:14:46 <ttx> anotherjesse: agreed. I just want to make sure we are in the loop and have the final word on those.
20:15:07 <notmyname> vishy: agreed. there is no plan to remove the client lib and bin from swift-core team
20:15:16 <notmyname> heckj: and swift want to keep it there too
20:15:23 <anotherjesse> notmyname: why?
20:15:25 <vishy> notmyname: ok cool that deals with most of my concerns then.
20:15:44 <bcwaldon> sorry if I missed something, but why in the world does it make sense for keystone to own the identity api middleware that converts headers into swift-specific attrs?
20:16:04 <anotherjesse> bcwaldon: yeah, that seems like it belongs in swift
20:16:11 <devcamcar_> yep
20:16:12 <vishy> notmyname, anotherjesse: I think more important than the location of the middleware, is that we have a gating test somewhere
20:16:38 <heckj> there's dependencies both ways - glance and swift have gone "one off" in middleware auth
20:16:53 <notmyname> the swift (or any project) middleware that provides keystone integration should, IMO, live with keystone (the auth system). therefore the auth system become a contained piece that develops it's features as a whole
20:16:54 <heckj> nova, keystone, and quantum are all using token_auth to add context up the pipe
20:17:46 <ttx> jbryce: before we address the specific case of keystone auth in Swift... do we have agreement that core projects splits should be announced in advance to let the PPB question or oppose them if need be ?
20:18:05 <jbryce> ttx: was just writing the same thing = )
20:18:06 <bcwaldon> notmyname: it shouldnt live with keystone, its only used by swift, and what it does depends directly on how swift is organized
20:18:50 <ttx> that way we can solve the problem earlier next time, in case it happens again. Then we can talk about how we solve the current questionable split
20:18:53 <jbryce> before we dive too far into specific case, does everyone feel like having major feature splits announced prior to the work being complete and giving people a chance to comment is a good idea?
20:19:07 <bcwaldon> yes, so there is time to say no
20:19:08 <heckj> jbryce: yes
20:19:10 <bcwaldon> when necessary
20:19:30 <anotherjesse> notmyname: there is a middleware that keystone maintains that converts keystone auth headers to a wsgi context
20:19:32 <vishy> jbryce: yup
20:19:52 <devcamcar_> ttx: +1
20:19:53 <anotherjesse> notmyname: what swift needs inside it is a middleware that takes that wsgi context and converts it to what swift needs
20:19:56 <jbryce> and my practical definition for major splits would be pulling something out that would then go into a project of its own
20:19:58 <notmyname> jbryce: I'm not sure I agree with that
20:19:58 <ttx> jbryce: and that the PPB is ultimately competent on Core feature content ?
20:20:14 <anotherjesse> notmyname: that shouldn't live in keystone, that should be in swift and should be versioned with swift not keystone
20:20:38 <anotherjesse> jbryce: yes
20:20:40 <ttx> jbryce: or at least completeness / basic operation needs
20:21:04 <jbryce> notmyname: do you have an alternate idea or just would prefer no prior notification?
20:21:37 <notmyname> jbryce: no, separating parts of the project requiring approval by the PPB is not something I support. it's technical decisions that should live within the project
20:21:55 <bcwaldon> notmyname: not if its going to affect the ecosystem
20:22:44 <jbryce> notmyname: the proposal did not require approval just notification
20:22:53 <notmyname> bcwaldon: one problem is the original problem that ttx proposed to solve is that it can't be solved. we already are relying on projects "out of our control" to provide functionality within openstack projects (all the 3rd party libraries)
20:23:45 <ttx> notmyname: but for authentication, we rely on an openstack project.
20:24:06 <ttx> making it incomplkete would look very bizarre.
20:24:19 <jbryce> sure we can't solve it for all code in the world, but for code that we have been responsible for, it seems like it's not a bad idea to do a sanity check that we are not throwing out something that is critical to openstack as a whole
20:24:39 <heckj> notmyname: the technical choices of one project need to consider the ecosystem as a whole - OpenStack Core as a viable, coordinated product
20:24:50 <bcwaldon> heckj: ++
20:25:04 <notmyname> ttx: ok, so about 10 minutes ago was the first time (recently) that keystone swift integration has been mentioned as a major problem requiring ppb oversight. I don't really feel ready to address that issue fully here (especially with the several conversations going on at once)
20:25:11 <notmyname> heckj: I agree
20:25:37 <ttx> notmyname: sure, we can defer to next week
20:25:54 <anotherjesse> notmyname: is the reason for making the integration be in keystone because swift doesn't want to maintain it?
20:25:54 <ttx> notmyname: I just wanted to have teyh general rule spelled out, not the particular case
20:26:07 <anotherjesse> or does the swift team want to maintain integration but in a different project
20:26:17 <notmyname> anotherjesse: I'm not sure I'm ready to answer that :-)
20:26:42 <ttx> jbryce: maybe for this week we should just vote on the general rule ("advance announcement" and "PPB rules the completeness of core")
20:26:50 <notmyname> ttx: but I don't think we need a general rule. ie nobody is proposing to remove any sort of "core" functionality
20:26:53 <jbryce> i'm fine with deferring on the specifics of swift until next week
20:27:12 <notmyname> I don't think there is a problem that we need to have a policy about
20:27:34 <anotherjesse> notmyname: the concern is that swift doesn't care about integrating with openstack auth
20:27:53 <anotherjesse> which hurts the community
20:28:00 <ttx> notmyname: I think that example proves otherwise. I don't see a drawback in saying that splits should be announced in advance to let a chance for the PPB to question it.
20:28:06 <jbryce> do other people think we should have a general standard around notification?
20:28:23 <ttx> I don't really want to watch all commits for all projects and discover stuff.
20:28:35 <jgriffith> jbryce: yes
20:28:59 <bcwaldon> jbryce: yes
20:29:01 <anotherjesse> ttx: agreed - if I am downstream of a project I'd like to know significant changes that are coiming
20:29:07 <heckj> jbryce: yes
20:29:10 <devcamcar_> jbryce: +1
20:29:11 <anotherjesse> jbryce: +1
20:29:32 <vishy> +0
20:29:42 <jgriffith> bottom line is if there's a change that impacts other projects there has to be some notification/discussion
20:29:44 <notmyname> -1
20:29:44 <jbryce> anotherjesse: +1  and for me it's not just about the oversight of ppb, but just helping everyone be aware
20:30:08 <ttx> jbryce: should be announced on the development list, yes
20:30:16 <vishy> I don't see the need for more policy. I think we notice these things when they come up and i don't think any of the ptls would remove major pieces of the code without discussion/notification
20:30:29 <danwent> vishy: +1
20:30:30 <ttx> vishy: it's not really policy, it's communication
20:30:59 <ttx> like we said that new deps should be discussed as well
20:31:06 <danwent> I think we can agree that such things should be communicated… whether we need an official rule on it vs. trusting someone's common sense and good judgement is another thing.
20:31:14 <ttx> let's file that one under "obligation of communication"
20:31:28 <vishy> ttx: I agree that it is a good idea and should be done, I just don't see the need for an explicit policy about it.
20:31:39 <notmyname> vishy: +1
20:31:46 <ttx> vishy: so that nobody can pretend they understood otherwise ?
20:31:49 <jbryce> danwent, vishy: i agree with you guys but it sounds like notmyname doesn't even agree with the idea?
20:32:42 <notmyname> I agree that communication is good. I don't think there needs to be a policy and I _really_ don't think that non-core devs should be able to approve or deny the technical decisions of the core dev team
20:32:51 <ttx> vishy: I really don't want to fly to San Francisco to learn about the next one.
20:33:39 <ttx> I'd like to make sure it will be on the ML
20:33:39 <vishy> I would much rather solve this technically: i.e. get devstack gating in on the swift fuctionality we are depending on
20:34:22 <ttx> vishy: we might miss special cases. Anything wrong with communication ?
20:34:23 <vishy> currently ec2 support depends on the swift3 middleware.  That is in core right now...
20:34:44 <anotherjesse> notmyname: those are two different issues - whether we have a recommendation to communicate changes that affect users ----------- and whether a project has complete autonomy
20:34:54 <vishy> vishy: I think we are much more likely to miss proposed domino-effects from splits through announcements than through gating.
20:34:57 <jbryce> so instead of a policy, can we just agree that there should be a general standard of communication where major feature removal is communicated to the mailing list before the change is complete?
20:35:00 <ttx> vishy: I'm not asking that we have a formal PPB meeting before each proposed code split. Just that the splits are announced on the ML
20:35:07 <vishy> ttx: ^^
20:35:10 <bcwaldon> notmyname: these aren't just technical decisions, where code lives and what projects exist arent' technical decisions solely up to swift-core
20:35:18 <jbryce> is vishy talking to himself again?
20:35:25 <vishy> vishy: yup
20:35:31 <ttx> vishy: checking on gating is a complement, not an alternative
20:36:03 <ttx> vishy: I'd rather discuss the issue before the change is pushed to jenkins.
20:36:12 <vishy> ttx: if we want to officially support announcements that is fine
20:36:23 <vishy> ttx: I think we're trying to fix a problem that doesn't exist though
20:37:14 <ttx> vishy: some PPB members follow development from some projects from quite far and might miss something that affect them.
20:37:58 <vishy> ttx: i agree, but the two examples we have of this so far there have been announcements already
20:38:13 <soren> vishy: After that fact.
20:38:21 <soren> s/that/the/
20:38:39 <vishy> soren: Oh?
20:39:40 <vishy> maybe i was misinformed, I thought the announcement about the breakout of stuff was for the next release of swift (i.e. it hasn't happened yet)
20:39:47 <vishy> notmyname: am I mistaken?
20:40:02 <notmyname> vishy: you are correct
20:40:12 <soren> Eh?
20:40:19 <notmyname> all of the changes that we proposed were discussed extensively with the whole swift-core team, the 3rd party developers, over email, IRC,  and in person at the summit. the email that I sent was the conclusion of all of those discussions, but it was not sent after the code changes happened (some of the changes haven't happened yet)
20:41:06 <vishy> notmyname: ok I'm not going insane then :)
20:41:23 <jbryce> yeah, and i'm honestly not really big on trying to define yet another policy (YAP?). can we just say that it's good practice to announce big changes/splits/removals on the mailing list before they're completed?
20:41:26 <soren> Sorry, my bad.
20:41:46 <vishy> jbryce: +1
20:41:46 <jbryce> then we can discuss on a one-off basis if someone feels like something specific is really going in the wrong direction
20:42:05 <anotherjesse> jbryce: and I think there is a lot of concern about keystone integration with swift
20:42:11 <ttx> jbryce: I could agree with that.
20:42:16 <anotherjesse> for next week :)
20:42:26 <vishy> I think this all started because I thought that the swift/keystone middleware was in swift and it was on the list to get pulled out.
20:42:37 <jbryce> anotherjesse: yes. let's get it on the agenda and talk about it specifically
20:42:37 <vishy> so my bad too :)
20:42:39 <ttx> jbryce: discussing it in advanace shouyld be the benefit of everyone. Prevents painful reverts
20:43:14 <jbryce> notmyname: can we talk about swift + keystone next week?
20:43:27 <notmyname> jbryce: sure
20:43:50 <jbryce> do people have specific issues they'd like notmyname to address next week?
20:44:22 <ttx> So does everyone agree that we need to care about "OpenStack Core" being able to deliver basic functionality using non-ecosystem components ?
20:44:31 <jbryce> or just general discussion on swift+keystone integration and maintenance of the integration code?
20:44:33 <anotherjesse> jbryce: what the intention is for the swift team in regard to keystone integration - active involvement? preferred deployment? assumed default?
20:44:33 <vishy> ttx: +1
20:44:36 <ttx> and that discussing splits in advance is a good thing ?
20:44:54 <vishy> ttx: +1
20:44:58 <ttx> doesn't have to be policy, just some assertion of what we care about
20:45:00 <jbryce> ttx: +1 and +1
20:45:03 <vishy> I think that is just good community sense
20:45:11 <jbryce> i assert that i care about that = )
20:45:14 <ttx> indeed
20:46:03 <ttx> (and if there is a specific issue with that, it should be raised as a topic separately)
20:47:29 <jbryce> anything else on this for this week?
20:47:54 <heckj> was there anything specific we needed to talk about re: Cinder?
20:48:03 <jbryce> #topic open discussion
20:49:06 <anotherjesse> regarding cinder - we should write this up a little more formal but I hope that we can go down a path that results in:
20:49:14 <jbryce> heckj: cinder is on a fastrack for being core in folsom if it is able to match existing nova-volume functionality by folsom-2 milestone
20:49:23 <anotherjesse> shipping cinder as core in folsom, removal of nova-volume from nova
20:49:26 <heckj> good by me
20:49:29 <anotherjesse> otherwise we are updating code in both places
20:49:33 <ttx> heckj: that was last week discussion
20:49:52 <anotherjesse> it does mean we can't do huge changes - we need to treat the code as "stable" and do incremental work
20:49:55 <ttx> heckj: we'll track progress towards that at the weekly project/release meeting
20:49:57 <heckj> yes, but vishy mentioned jgriffith was here to talk about Cindr - didn't know if there was another topic pending
20:50:09 <jbryce> anotherjesse: we discussed that last week and agreed on doing a big health check at folsom-2
20:50:26 <anotherjesse> jbryce: cool - was on a flight last week :-/
20:50:29 <devcamcar> anotherjesse: basically if things are looking good by folsom-2 then thats how we'll proceed
20:50:36 <anotherjesse> devcamcar: hawt
20:50:37 <ttx> jbryce: i'll make sure to rise any red flag in advance of that milestone
20:50:43 <jgriffith> heckj: Just an update for the upcoming project meeting (10 minutes)
20:50:56 <jbryce> anything else?
20:50:59 <notmyname> yes
20:51:09 <notmyname> do we have a policy on copyright assignment?
20:51:30 <jbryce> in what regard?
20:51:31 <anotherjesse> notmyname: the cla doesn't require it - so we haven't been doing copyright assignment afaik
20:51:36 <jbryce> we don't require it
20:51:58 <anotherjesse> if someone wants to assign copyright, they are allowed to
20:52:17 <notmyname> we've had some recent submissions that are new files with copyright assigned to both the submitter and openstack llc. that seems weird to me
20:52:50 <russellb> i'm betting that was not intentional.  they probably just did a copy/paste and added their name.
20:53:00 <jbryce> notmyname: i'll ask alice about it
20:53:02 <jbryce> does seem a little strange
20:53:09 <notmyname> jbryce: ok, will do
20:53:09 <anotherjesse> notmyname: ianal, but the copyright holder can assign copyright - but I agree with russellb that it is probably just copy-paste of header
20:53:17 <ttx> jbryce: quite a few files in Nova are this way
20:53:24 <jbryce> #action jbryce to ask Alice King about copyright assignment to OpenStack, LLC
20:53:37 <notmyname> ttx: that makes sense if it was an edited file, but not a new file
20:53:40 <ttx> jbryce: it's definitely not required or forbidden.
20:54:08 <anotherjesse> notmyname: some people start a new file by copying an existing and deleting the code leaving the header …
20:54:11 <anotherjesse> a guess
20:54:20 <vishy> jbryce, ttx : generally that is due to multiple edits on the same file
20:54:24 <notmyname> jbryce: all the RAX contributed stuff (to swift) is assigned to openstack llc
20:54:32 <ttx> notmyname: oh, you mean he probably shouldn't have assigned copyright to OpenStack LLC. Isee, and I concur
20:54:43 <notmyname> ie, there is no RAX copyright in any swift file
20:54:58 <jk0> same for nova
20:54:59 <ttx> notmyname: but I'm pretty sure he can if he wants (IANAL, etc)
20:55:06 <jbryce> notmyname: right. i asked alice about something similar and she was concerned about people assigning new IP to OpenStack LLC without our awareness
20:55:25 <jbryce> but i'll send her an email
20:55:26 <notmyname> jbryce: the question there is who is "our"
20:55:34 <jbryce> notmyname: exactly
20:55:52 <jbryce> 5 minutes...anything else?
20:57:40 <jbryce> all right. thanks everyone!
20:57:50 <jbryce> #endmeeting