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