21:00:43 #startmeeting 21:00:44 Meeting started Thu Feb 10 21:00:43 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:01:05 ola 21:01:08 * creiht bows 21:01:23 agenda? 21:01:27 So i see 6 of us here--looks like we're missing jesse, ewan and mark. jesse is supposed to be joining shortly 21:01:41 agenda can be seen at the bottom of the page here: http://wiki.openstack.org/Governance/POC 21:02:11 #topic 2011 scope and charter 21:02:11 ah, cool 21:02:40 so we discussed this on email and there were a few open questions that were raised 21:02:51 creiht: can you summarize what we've agreed to so far? 21:03:09 one is around the inclusion of the draft service architecture 21:03:26 ah, right. Yeah, I still think we should make that a separate action. 21:03:34 the other item up for discussion was around the specification of individual languages 21:04:00 so on the service architecture, what specific points do you want to see separated out? 21:04:18 http://wiki.openstack.org/Governance/Proposed/2011%20Charter%20and%20Scope - that's the current proposal state 21:04:25 opening it now... 21:04:44 hi ewan...we're just getting started 21:04:48 hi 21:04:58 Sorry I'm late 21:05:12 jesse is on a plane 21:05:15 so on the service architecture 21:05:28 * on his way to a plane 21:05:38 1. No problem with public RESTful API as a req 21:05:54 2. No problem with RESTful admin API (not sure it should be required to be public) 21:06:14 And not sure that calling it out as protected by ACL/permissions should be part of the service arch 21:06:25 since I think there are some innovations I'd like to push forward this year on that front 21:06:33 ok...i can see that 21:06:53 Don't mind calling out pub/sub as a specific option, but would like to see webhooks mentioned as well 21:07:21 e.g., programatic webhooks via pub/sub or some other notification mechanism (could be the new queueing stuff that Eric is starting on) 21:07:46 ok...i'm fine with those modifications 21:08:02 Would like to call out WSGI as a specific technology for the extension interface or service framework (don't know where exactly we should mention it) 21:08:21 I guess that's more between API and service framework 21:08:35 And the last concern was on the extension interface 21:08:56 I think we'll get ourselves into trouble (astronauting) if we start trying to spec out too much extensionability 21:09:22 If we're going to describe it as an interface, maybe pointing specifically to what Ewan did with the Xen abstraction? 21:09:59 i think in this document, though, we're not trying to get too low-level and specific and more describe in general terms the attributes that a project would have. 21:10:19 i think the actual details could vary by project and should probably be driven more at that level 21:10:23 e.g., implementations *must* vs., *can*, and how implementation-specific code gets calls. Extension interface can imply infinitely complex (e.g. XPCOM) 21:10:25 sure 21:10:47 Yes i think broad and general is best at this level 21:10:55 I just don't want projects to think they need to have XPCOM or a whole run-time scriptable language to qualify 21:11:09 monkey-patches are extensions, too 21:11:30 as written, it leaves room for that 21:11:32 here's my proposal 21:11:50 1. modify public management API to say optionally protected 21:12:06 2. say "such as pub/sub" on the notification interface item 21:12:26 3. remove the specific languages being called out 21:13:05 then approve this one and move on to other proposals like the process for incubation and project evaluation 21:13:08 Can we require services to be implemented as WSGI? 21:13:26 for common auth or what have you 21:13:27 jmckenty: Not sure, since WSGI is python specific 21:14:14 you can make Java / PHP talk WSGI 21:14:28 if you're crazy 21:14:29 not within a python app stack 21:14:31 heh 21:14:44 at that level that is why we specify RESTful apis 21:14:56 to ensure common communication between services 21:15:02 k, fair enough. I'm good with your plan, jbryce 21:15:11 creiht: http://pythonpaste.org/wphp/ 21:15:25 jmckenty: lol :) 21:15:34 so as amended, let's vote on the 2011 scope charter 21:15:35 +1 21:15:42 +1 21:15:52 +1 21:16:00 +1 21:16:55 dendrobates? 21:17:30 and ewan? 21:17:48 and soren ? 21:18:00 oh yeah where is soren? 21:18:27 I vote 0. 21:18:42 is that abstain? 21:18:58 I'm uncomfortable with the idea of telling people how to architect their software in a_ charter_. 21:18:58 +0 or -0 ? 21:19:25 I don't think that we should even be talking about software architecture, when it comes to a charter for OpenStack. 21:19:46 But I don't think that there's enough that's bad about the proposal on the table to give it -1. 21:20:01 ewanmellor: even at the broad level of having basic common api technology? 21:20:13 well, you can give it -0 which is non-blocking 21:20:24 So I'm happy for you to proceed, if it's helping something that you're trying to do. 21:20:29 ok 21:20:43 we've got 4 of 7, which is a majority and a quorum 21:20:53 It gives us some common ground for evaluating proposed projects for inclusion into openstack. I think that's the big win 21:20:54 I agree that public APIs should be RESTful, modulo a long and tedious discussion about what RESTful means. 21:21:06 #agreed Approve the 2011 project charter and scope 21:21:15 I disagree that RESTful is the right way to design all APIs. 21:21:21 But anyway, let's move on. 21:21:25 * jmckenty and ewanmellor will drink beer and bemoan the bastardization of the term RESTful 21:21:26 #info 4 approves, 3 abstentions 21:21:40 #topic Image formats 21:21:53 ah, fun 21:22:07 this was another proposal on publishing a stance on image formats 21:22:13 http://wiki.openstack.org/Governance/Proposed/ImageFormats - that is the draft 21:23:11 Why is this a governance issue, not just a blueprint for Glance / Nova? 21:23:12 the proposal had 3 main components: 21:23:15 Can I point us briefly to the Open Cloud Manifesto? 21:23:22 1) we need a standardized exchange format--proposal is to define an ovf/ova for our use 21:23:47 2) openstack should not specify preferred/default virtual disk format 21:24:12 3) glance should be extended to include conversion capabilities (seems like a feature definition/blueprint) 21:24:16 both of those points make sense to me 21:24:25 a lot of this seems specific to glance 21:24:41 http://www.opencloudmanifesto.org/opencloudmanifesto6.htm - use and adopt existing standards where appropriate 21:25:19 jmckenty: Does that mean "use something that exists if it's the right thing to do, but don't if it's not"? 21:25:20 jmckenty: isn't that what is being suggested? 21:25:34 on the ovf/ova layer, yes 21:25:47 but the specific statement that we *shouldn't* espouse a standard disk image format, I'm not sure about 21:25:59 I think perhaps we SHOULD espouse one, but support many 21:26:24 I don't know if this is a case, such as hypervisors, where there are complex tradeoffs and no clear best choice 21:26:51 what is meant by standard? as in what is used on the backend? 21:27:01 because I think that is very hypervisor-specific 21:27:06 The disk format within the OVF 21:27:17 e.g., within glance and for transport 21:27:31 anyway, I guess we dodge the issues this way 21:27:42 "This also sidesteps the potentially divisive topic of support for VHD and the Microsoft Open Promise licensin" 21:27:42 i think what it said was "preferred or default" rather than standard for disk format 21:27:55 I have nothing against OVF (my name is on the spec, after all), but just some points of info: 21:28:24 OVF doesn't give you interoperability. The metadata standard isn't standard enough to be interoperable. 21:28:40 OVF doesn't specify a disk format, so you still need to handle all the disk conversions. 21:29:04 There's a practice concern around defaults - in order for the install process to be manageable, we *need* defaults 21:29:12 I would propose the least optimum default - RAW 21:29:25 everyone supports it, and most installs will switch to something else 21:29:42 i think publicly raw is the way to go, perhaps with gz compression 21:30:16 sirp: raw within a tarball container seems like a sensible default 21:30:18 but internally i don't think there is a need to bless a format, and conversions between formats should be provided. 21:30:20 ewanmellor: do you think it's reasonable to try and draft a restricted OVF definition that WOULD be portable? 21:30:32 ewanmellor: true, but if we put a stake in the ground for openstack, then at least openstack clouds would interop with each other and given enough critical mass may move to a broader adoption 21:30:50 vishy: i agree 21:30:54 e.g., *an* OVF, not *any* OVF 21:31:00 jmckenty: Yes. You could say "VMware's OVF" or "Citrix's OVF". 21:31:16 no, I meant "OpenStack's OVF" 21:31:25 is there a subset that's useful? 21:31:30 No, that's my point. 21:31:30 jmckenty: that is what john is proposing 21:31:47 right. john is proposing it, ewanmellor is saying it's not possible 21:31:57 ewanmellor, technically, would know ;) 21:32:22 "OpenStack's OVF" would have to choose either VHD or VMDK, so at the least someone would have to convert the disk format for either VMware or Hyper-V/XenServer/QEMU. 21:32:36 ewanmellor: can't it choose raw? 21:32:52 vishy: Yes it can, I think, but then it's useless. 21:32:59 pourquoi? 21:33:19 The OVF spec says "any published format", IIRC, so raw would be acceptable. 21:34:04 So how bout this - a proposed OVF spec that glance supports, along with transforms that convert that to the OVF-variant that's usefully executable by the particular hypervisor? 21:34:09 But you can't use that as a transport format: an empty virtual disk with a 100 GB filesystem would be 100GB in raw. 21:34:24 yes - we noticed that early on :) 21:34:28 So if you want to transport it between clouds, all your templates are much much larger than they ever need to be. 21:34:38 So it's useless as an interop format, because you can't use it for transport. 21:35:03 well, hence the tarball proposal, but that's not a supported disk format yet 21:35:24 Because the most important point of interop is from appliance vendors to customers, and those always have much more free space than used, to allow the customer to expand into the free space. 21:36:10 i see 21:36:23 XenServer's XVA is basically raw, but skipping any 2MB block that's completely zero, and with checksums, and then a tarball wrapper, and then gzipped. 21:36:31 It's basically what you're getting at. 21:36:36 jbryce: I think we may have to take this back offline for more debate 21:36:39 ok...sounds like we need some more thought on this one 21:36:42 But then, of course, you're using XenServer's format, not a neutral one. 21:37:11 #info need to re-evaluate proposal 21:37:13 who's on the glance team - any POC members? 21:37:26 i am 21:37:29 jaypipes as well 21:37:33 #action jbryce to get with John Purrier 21:37:55 #action jbryce and John Purrier to get with glance devs as well? 21:38:08 Citrix, of course, has lots of IP in the conversions-between-hypervisors space. 21:38:09 yes 21:38:26 let's keep it moving 21:38:30 #topic Versioning and minor releases 21:38:37 ooh, fun 21:38:41 heh 21:38:44 did you all get a chance to review theirry's presentation of the issue in his email? 21:38:58 o 21:38:59 No 21:38:59 I did 21:39:03 Recent email? 21:39:08 a while ago 21:39:20 https://lists.launchpad.net/openstack-poc/msg00036.html - it's in this message 21:39:39 ewanmellor: from tuesday when i sent out the agenda 21:40:09 Oh yeah, I read that. 21:40:25 My take is that people will use packaged distibutions 21:40:27 I wondered whether Canonical's new involvement changed anything. 21:40:40 i.e., what Josh just said. 21:41:05 I would also suggest we hold off on making a decision on this until the testing environment is running properly 21:41:36 e.g., we can tell Canonical and RedHat that we think trunk is a good candidate for a stable bug-fix release when the tests are all passing 21:42:02 just based on the number of bugfixes we put in post bexar, it would be nice to get that out somehow withoug making people use trunk. 21:42:11 I think the biggest problem is security holes, because they're a PITA for everyone. 21:42:30 right, but to get coverage we're going to need to work with the upstream folks on that anyway 21:42:32 no? 21:42:39 If we had a security alert, could we rely on Ubuntu / Canonical to handle everything (CVE, etc) or are we going to have to do that ourselves? 21:42:48 * jmckenty always confuses upstream and downstream 21:43:23 not everyone is going to be deploying from a distribution 21:43:39 There's a good case for security (and integration testing, as well) to be managed by a parent openstack project 21:43:40 and we really only have coverage in one distribution right now 21:43:48 and not left to individual components 21:43:51 Is this a question about distribution, or is it about having point releases? 21:43:57 those seem like 2 separate questions 21:44:05 it's about whether we're responsible for point releases, 21:44:09 or whether the distribution channels are 21:44:18 creiht: the thinking is that the distros would handle those intermediate releases 21:44:40 That seems a bit silly to me, do we have examples of other projects that do that? 21:44:46 Do we have the capacity to handle point releases, even if we wanted to? With 3 monthly cycle anyway, it will be hard to have point releases. 21:45:54 The problem with that is that people that are trying to use a supposedly "stable" release are stuck without bug fixes until the next release 21:46:16 #action jbryce to get ahold of our upstream partners for clarification on distribution of security/point releases 21:46:25 creiht: I'm proposing that they get their bug fixes from the distro. Assuming that the distro is happy with that! 21:46:38 Also maybe a good idea to hash this out when soren can comment? 21:46:40 Is there an example of any other project that does that? 21:46:41 yes 21:47:00 creiht: So we're cutting edge ;-) 21:47:07 it wouldn't be the first time 21:47:10 Every project that I follow does its own releases, which distros pick up 21:47:13 lol 21:47:16 sounds pretty lazy to me 21:47:28 3 monthly releases aren't lazy. 21:47:38 not lazy, efficient. We're better coders than packagers, right? 21:47:40 Is anyone doing 3 monthly releases _and_ doing their own point releases? 21:47:47 It is if you are trying ot implement what someone has released, but has to wait 3 months for a bugfix 21:48:03 We already have people running 1.0 and 1.1 swift code 21:48:11 Again, I think the testing environment will really help with this 21:48:24 mostly 1.1 now 21:48:27 we can tag trunk when things look reasonably good 21:48:51 creiht: Does Swift plan to keep going with 3 monthly releases? It's obviously at a different maturity level than Nova. 21:48:55 Perhaps a better suggestion 21:49:13 Perhaps we can leave this to the project's disgretion? 21:49:25 * jmckenty longs for the day when Nova gets split into volumes, compute, and networking. 21:49:29 the default is that projects will have timed releases 21:49:47 if a project chooses to, allow them to manage point releases 21:50:26 creiht: i kind of like that 21:50:29 Even to support swift internally at RS, it is difficult to do this with out allowing us to make point releases 21:50:55 As long as the full set of components (especially ones that interop heavily) work together every major upstream release, I think project-by-project point releases make sense 21:51:25 But esp. between glance and nova, and probably the new queue stuff as well, I think we may end up with ugly point-to-point release dependencies 21:51:49 jmckenty: that's what packaging is for right? :) 21:52:00 So, we have one significant problem that needs to be solved 21:52:11 bexar has some significant bugs 21:52:18 * jmckenty hates packaging, and praises those who do it well 21:52:28 vishy: can we blame you for those? 21:52:28 why not do a .1 release? 21:52:31 yes 21:52:37 nova bugs, or swift bugs? 21:52:40 nova 21:52:50 are we worried about having to support .0 and .1? 21:52:54 The current bexar issue I think highlights the issue, what seems to me to be a very straight forward, yes fix it issue has turned into quite a debachle 21:52:55 so how do we decide we're ready for the .1 21:53:02 and people are still downloading broken version 21:53:43 i think the teams could propose and vote on a .1 release (or we could nominate patches for backporting) 21:53:44 jmckenty: seems like that should be up to the project 21:54:21 So if we're going to support point releases, I think we should encourage folks to install from PPA and not a tarball 21:54:37 jmckenty: what's the difference? 21:54:49 and not everyone is on debian 21:54:59 /ubuntu 21:55:11 I agree that we should offer both 21:55:32 we're hosting the project on launchpad, so I think we've telegraphed our biases there a bit. Upgrading a PPA is easier, IMO. 21:55:48 ditto for an APT repo, then 21:55:52 agreed, but we can't be blind to the rest of the linux community 21:55:58 At work, we fix the bug in trunk and then tag it with "candidate for backport" and let the release manager decide which ones should be backported into the next point release. They then get the dev to backport as necessary, or just do the merges themselves. 21:56:05 Is this something that we can do with Launchpad. 21:56:22 ? 21:56:24 ewanmellor: yeah lp lets you tag bugs to other release milestones 21:56:28 ewanmellor: yes 21:56:32 and then has a separate set of fields for tracking 21:56:42 We've done that with a couple of bugs in swift, and it works quite well 21:57:03 So would Thierry be the one to manage the point release? When we have one, and which things go in it when we do? 21:57:08 lp actually makes the backport process pretty easy 21:57:19 ewanmellor: I think he would, yes 21:57:36 ewanmellor: I think that should be up to the project, and the release manager helps facilitate it 21:57:40 ewanmellor: I think anyone in the community should be able to petition the project 21:57:49 I'm fine with the project having point releases, as long as you guys think that you've got resources to do it. 21:57:54 the release manager shouldn't be the one makeing those specific decisions 21:58:00 ok 21:58:02 creiht: I second that 21:58:15 so let's see if there's a proposal here shaping up 21:58:28 creiht: We give the job to them, because they have to analyse risk vs impact. 21:58:38 1) intermediate release policy is determined at the project level 21:59:01 2) release manager helps facilitate intermediate releases if the project determines it's necessary 21:59:11 ewanmellor: then we need release manager dedicated to each team that really knows what things will impact 21:59:30 creiht and ewanmellor: the release manager should default to saying no if they're unsure 21:59:40 otherwise how do they really know what is a risk and what isn't 21:59:48 and the dev or community member can do the merge and try and prove it's safe 22:00:04 or get core team members to weigh in 22:00:22 creiht: The release manager is expected to speak to the devs until they understand the risk. 22:00:52 But that's a commercial setting where we're all in the same room. It's not necessarily going to work well in a global OSS setting. 22:00:57 so we're right up to 4:00 now--i know there are some who have to leave 22:00:58 right, but we *are* going to run out of resources if we start having thierry spinning point releases 22:01:09 GSOC? 22:01:22 #action jbryce to start email thread on release process for POC to continue discussion 22:01:28 #topic next meeting time 22:01:43 since we have a couple of unresolved issues, can we get together again same time next week? 22:01:49 sure 22:01:49 +1 22:02:00 +1 22:02:03 +1 22:02:07 +1 22:02:17 +1 22:02:28 Well, +0.5 22:02:33 I might not make it. 22:02:35 21:00 UTC 2/17 22:03:04 thanks everyone 22:03:09 thanks guys...i'll send around a couple of emails and we can continue the discussion there 22:03:15 sounds good 22:03:21 ewanmellor: if there's a nearby time that works better, maybe we can adjust slightly 22:03:22 Does that mean that GSOC is floating for another week? 22:03:37 * creiht has time if we wish to discuss 22:03:39 are we up against any deadlines there? 22:03:56 jbryce: Thanks, but no, 10pm is just as bad as 9pm or 11pm. 22:04:07 yes the gsoc is closing mar 10 I think 22:04:14 for submissions that is 22:04:26 deadline in mar 11 22:04:50 submissions can't start until feb 28 22:04:57 so waiting a week probably isn't bad 22:04:58 on GSOC, you guys can continue to discuss...i've got to run. if someone can just send out a note to the list of any major points we can continue there 22:05:48 I have half-an-hour before my next call. Does anyone want to discuss GSOC, or shall we postpone? I'm fine either way. 22:06:10 sounds like postpone 22:06:14 see you guys. thanks for the time! 22:06:15 #endmeeting