20:00:51 #startmeeting 20:00:52 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:18 hi everyone 20:01:20 haz quorum? 20:01:22 o/ 20:01:36 o/ 20:01:39 now we do 20:02:01 one quick question coming out of last week 20:02:40 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 o/ 20:03:03 jbryce: it has not, I will send out a message to the list outlining the options 20:03:12 (for nova) 20:03:16 notmyname made a reference to it on the list, but nothing else has flowed out as yet 20:03:28 ok 20:03:40 I've talked to the IBM people about CDMI on swift, and swift3 compatibility extraction is currently in-progress 20:03:52 #action vishy to send note out about 3rd party api plan 20:03:52 o/ 20:03:58 vishy: thanks 20:04:18 notmyname: cool...those are ones i was wondering about 20:04:35 #topic completeness of core 20:04:52 ttx: do you want to introduce this one? 20:05:00 Sure. As explained in https://lists.launchpad.net/openstack-poc/msg00513.html ... 20:05:19 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 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 ttx: I know jgriffith is here to talk about the cinder aspect 20:05:53 There are two ways to split features out. One is to split into another Core project (like Cinder) 20:06:08 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 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 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 Project teams/PTLs still get to decide what feature should be split and what feature should not... 20:07:19 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 Thoughts ? 20:08:06 ttx: I think maybe pbb should be an oversight not an active decider 20:08:34 anotherjesse: it's sometimes hard to fix after the fact. And you may discover certain things late... 20:08:36 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 how significant does a split need to be to involve people outside of the project? 20:09:15 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 since the PPB defines what's "core" 20:09:51 ttx: do you have an estimate of how much are we signing up for 20:10:06 ttx: i think another possibility is for features to go into another core project 20:10:16 vishy: indeed. Good point. 20:10:29 which would be perfectly alright if both projects agree. 20:10:31 are we expecting to split anything else out in the near term? 20:10:51 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 if not then I'd suggest treating a one off as such 20:11:19 mnaser: sure, that looks right 20:11:23 there is one specific concern that started this, so lets just address the concern and move on 20:11:24 sry 20:11:25 sorry... late 20:11:34 vishy: ++ 20:11:41 as an example, swift splitting swift3 sounds sane. Swift splitting keystone auth, a bit less. 20:11:54 notmyname: we were discussing keystone middleware for swift. Were you planning on pulling it out? 20:12:03 a core project that doesn't speak core auth doesn't make sense... 20:12:08 keystone middleware was never part of swift to begin with 20:12:21 notmyname: because keystone didn't exist until recently :-) 20:12:31 that's crazy to suggest removing keystone middleware from swift 20:12:34 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 notmyname: so it is currently in keystone. What about the changes to the client to enable keystone? 20:12:48 ttx: that seems fine 20:13:03 all that does is say that swift doesn't care about the rest of the projects 20:13:04 vishy: the swift client is being removed from swift (into a separate deliverable for the swift project) 20:13:21 notmyname: gotcha, but it is still managed by swift-core? 20:13:22 so that it can be developed separately and require other projects to have less dependencies 20:13:27 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 vishy: yes 20:13:57 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 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 however, swift client libs and bins don't have anything to do with where keystone/swift middleware lives 20:14:40 keystone/swift middleware is currently in keystone, no plans to remove it. 20:14:43 notmyname: so the preference of swift-core is that keystone integration would be a drop-in - not part of the project? 20:14:46 anotherjesse: agreed. I just want to make sure we are in the loop and have the final word on those. 20:15:07 vishy: agreed. there is no plan to remove the client lib and bin from swift-core team 20:15:16 heckj: and swift want to keep it there too 20:15:23 notmyname: why? 20:15:25 notmyname: ok cool that deals with most of my concerns then. 20:15:44 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 bcwaldon: yeah, that seems like it belongs in swift 20:16:11 yep 20:16:12 notmyname, anotherjesse: I think more important than the location of the middleware, is that we have a gating test somewhere 20:16:38 there's dependencies both ways - glance and swift have gone "one off" in middleware auth 20:16:53 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 nova, keystone, and quantum are all using token_auth to add context up the pipe 20:17:46 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 ttx: was just writing the same thing = ) 20:18:06 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 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 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 yes, so there is time to say no 20:19:08 jbryce: yes 20:19:10 when necessary 20:19:30 notmyname: there is a middleware that keystone maintains that converts keystone auth headers to a wsgi context 20:19:32 jbryce: yup 20:19:52 ttx: +1 20:19:53 notmyname: what swift needs inside it is a middleware that takes that wsgi context and converts it to what swift needs 20:19:56 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 jbryce: I'm not sure I agree with that 20:19:58 jbryce: and that the PPB is ultimately competent on Core feature content ? 20:20:14 notmyname: that shouldn't live in keystone, that should be in swift and should be versioned with swift not keystone 20:20:38 jbryce: yes 20:20:40 jbryce: or at least completeness / basic operation needs 20:21:04 notmyname: do you have an alternate idea or just would prefer no prior notification? 20:21:37 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 notmyname: not if its going to affect the ecosystem 20:22:44 notmyname: the proposal did not require approval just notification 20:22:53 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 notmyname: but for authentication, we rely on an openstack project. 20:24:06 making it incomplkete would look very bizarre. 20:24:19 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 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 heckj: ++ 20:25:04 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 heckj: I agree 20:25:37 notmyname: sure, we can defer to next week 20:25:54 notmyname: is the reason for making the integration be in keystone because swift doesn't want to maintain it? 20:25:54 notmyname: I just wanted to have teyh general rule spelled out, not the particular case 20:26:07 or does the swift team want to maintain integration but in a different project 20:26:17 anotherjesse: I'm not sure I'm ready to answer that :-) 20:26:42 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 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 i'm fine with deferring on the specifics of swift until next week 20:27:12 I don't think there is a problem that we need to have a policy about 20:27:34 notmyname: the concern is that swift doesn't care about integrating with openstack auth 20:27:53 which hurts the community 20:28:00 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 do other people think we should have a general standard around notification? 20:28:23 I don't really want to watch all commits for all projects and discover stuff. 20:28:35 jbryce: yes 20:28:59 jbryce: yes 20:29:01 ttx: agreed - if I am downstream of a project I'd like to know significant changes that are coiming 20:29:07 jbryce: yes 20:29:10 jbryce: +1 20:29:11 jbryce: +1 20:29:32 +0 20:29:42 bottom line is if there's a change that impacts other projects there has to be some notification/discussion 20:29:44 -1 20:29:44 anotherjesse: +1 and for me it's not just about the oversight of ppb, but just helping everyone be aware 20:30:08 jbryce: should be announced on the development list, yes 20:30:16 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 vishy: +1 20:30:30 vishy: it's not really policy, it's communication 20:30:59 like we said that new deps should be discussed as well 20:31:06 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 let's file that one under "obligation of communication" 20:31:28 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 vishy: +1 20:31:46 vishy: so that nobody can pretend they understood otherwise ? 20:31:49 danwent, vishy: i agree with you guys but it sounds like notmyname doesn't even agree with the idea? 20:32:42 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 vishy: I really don't want to fly to San Francisco to learn about the next one. 20:33:39 I'd like to make sure it will be on the ML 20:33:39 I would much rather solve this technically: i.e. get devstack gating in on the swift fuctionality we are depending on 20:34:22 vishy: we might miss special cases. Anything wrong with communication ? 20:34:23 currently ec2 support depends on the swift3 middleware. That is in core right now... 20:34:44 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: I think we are much more likely to miss proposed domino-effects from splits through announcements than through gating. 20:34:57 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 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 ttx: ^^ 20:35:10 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 is vishy talking to himself again? 20:35:25 vishy: yup 20:35:31 vishy: checking on gating is a complement, not an alternative 20:36:03 vishy: I'd rather discuss the issue before the change is pushed to jenkins. 20:36:12 ttx: if we want to officially support announcements that is fine 20:36:23 ttx: I think we're trying to fix a problem that doesn't exist though 20:37:14 vishy: some PPB members follow development from some projects from quite far and might miss something that affect them. 20:37:58 ttx: i agree, but the two examples we have of this so far there have been announcements already 20:38:13 vishy: After that fact. 20:38:21 s/that/the/ 20:38:39 soren: Oh? 20:39:40 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 notmyname: am I mistaken? 20:40:02 vishy: you are correct 20:40:12 Eh? 20:40:19 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 notmyname: ok I'm not going insane then :) 20:41:23 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 Sorry, my bad. 20:41:46 jbryce: +1 20:41:46 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 jbryce: and I think there is a lot of concern about keystone integration with swift 20:42:11 jbryce: I could agree with that. 20:42:16 for next week :) 20:42:26 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 anotherjesse: yes. let's get it on the agenda and talk about it specifically 20:42:37 so my bad too :) 20:42:39 jbryce: discussing it in advanace shouyld be the benefit of everyone. Prevents painful reverts 20:43:14 notmyname: can we talk about swift + keystone next week? 20:43:27 jbryce: sure 20:43:50 do people have specific issues they'd like notmyname to address next week? 20:44:22 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 or just general discussion on swift+keystone integration and maintenance of the integration code? 20:44:33 jbryce: what the intention is for the swift team in regard to keystone integration - active involvement? preferred deployment? assumed default? 20:44:33 ttx: +1 20:44:36 and that discussing splits in advance is a good thing ? 20:44:54 ttx: +1 20:44:58 doesn't have to be policy, just some assertion of what we care about 20:45:00 ttx: +1 and +1 20:45:03 I think that is just good community sense 20:45:11 i assert that i care about that = ) 20:45:14 indeed 20:46:03 (and if there is a specific issue with that, it should be raised as a topic separately) 20:47:29 anything else on this for this week? 20:47:54 was there anything specific we needed to talk about re: Cinder? 20:48:03 #topic open discussion 20:49:06 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 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 shipping cinder as core in folsom, removal of nova-volume from nova 20:49:26 good by me 20:49:29 otherwise we are updating code in both places 20:49:33 heckj: that was last week discussion 20:49:52 it does mean we can't do huge changes - we need to treat the code as "stable" and do incremental work 20:49:55 heckj: we'll track progress towards that at the weekly project/release meeting 20:49:57 yes, but vishy mentioned jgriffith was here to talk about Cindr - didn't know if there was another topic pending 20:50:09 anotherjesse: we discussed that last week and agreed on doing a big health check at folsom-2 20:50:26 jbryce: cool - was on a flight last week :-/ 20:50:29 anotherjesse: basically if things are looking good by folsom-2 then thats how we'll proceed 20:50:36 devcamcar: hawt 20:50:37 jbryce: i'll make sure to rise any red flag in advance of that milestone 20:50:43 heckj: Just an update for the upcoming project meeting (10 minutes) 20:50:56 anything else? 20:50:59 yes 20:51:09 do we have a policy on copyright assignment? 20:51:30 in what regard? 20:51:31 notmyname: the cla doesn't require it - so we haven't been doing copyright assignment afaik 20:51:36 we don't require it 20:51:58 if someone wants to assign copyright, they are allowed to 20:52:17 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 i'm betting that was not intentional. they probably just did a copy/paste and added their name. 20:53:00 notmyname: i'll ask alice about it 20:53:02 does seem a little strange 20:53:09 jbryce: ok, will do 20:53:09 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 jbryce: quite a few files in Nova are this way 20:53:24 #action jbryce to ask Alice King about copyright assignment to OpenStack, LLC 20:53:37 ttx: that makes sense if it was an edited file, but not a new file 20:53:40 jbryce: it's definitely not required or forbidden. 20:54:08 notmyname: some people start a new file by copying an existing and deleting the code leaving the header … 20:54:11 a guess 20:54:20 jbryce, ttx : generally that is due to multiple edits on the same file 20:54:24 jbryce: all the RAX contributed stuff (to swift) is assigned to openstack llc 20:54:32 notmyname: oh, you mean he probably shouldn't have assigned copyright to OpenStack LLC. Isee, and I concur 20:54:43 ie, there is no RAX copyright in any swift file 20:54:58 same for nova 20:54:59 notmyname: but I'm pretty sure he can if he wants (IANAL, etc) 20:55:06 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 but i'll send her an email 20:55:26 jbryce: the question there is who is "our" 20:55:34 notmyname: exactly 20:55:52 5 minutes...anything else? 20:57:40 all right. thanks everyone! 20:57:50 #endmeeting