| *** adjohn has joined #openstack-meeting | 00:44 | |
| *** dendro-afk is now known as dendrobates | 00:53 | |
| *** dendrobates is now known as dendro-afk | 01:44 | |
| *** adjohn has quit IRC | 04:53 | |
| *** adjohn has joined #openstack-meeting | 04:56 | |
| *** adjohn has joined #openstack-meeting | 05:37 | |
| *** adjohn has joined #openstack-meeting | 05:37 | |
| *** adjohn_ has joined #openstack-meeting | 07:38 | |
| *** adjohn has quit IRC | 07:41 | |
| *** adjohn_ has quit IRC | 07:43 | |
| *** adjohn has joined #openstack-meeting | 08:01 | |
| *** dendro-afk is now known as dendrobates | 08:41 | |
| *** adjohn has quit IRC | 09:14 | |
| *** adjohn has joined #openstack-meeting | 11:35 | |
| *** dabo has left #openstack-meeting | 11:44 | |
| *** adjohn has quit IRC | 12:19 | |
| *** dprince has joined #openstack-meeting | 13:31 | |
| *** adjohn has joined #openstack-meeting | 13:54 | |
| *** edconzel has joined #openstack-meeting | 13:55 | |
| *** jkoelker has joined #openstack-meeting | 14:14 | |
| *** VanpoofFluffy-ku has joined #openstack-meeting | 14:40 | |
| *** dragondm has joined #openstack-meeting | 15:06 | |
| *** adjohn has quit IRC | 15:20 | |
| *** dprince has quit IRC | 15:49 | |
| *** dprince has joined #openstack-meeting | 16:03 | |
| *** dendrobates is now known as dendro-afk | 16:43 | |
| *** dendro-afk is now known as dendrobates | 17:13 | |
| *** jaypipes has quit IRC | 17:46 | |
| *** jbryce has joined #openstack-meeting | 18:37 | |
| *** ttx has joined #openstack-meeting | 18:40 | |
| *** jaypipes has joined #openstack-meeting | 18:43 | |
| soren | Hi, guys. I just stopped by to let you know that I won't be able to attend. I have the day off and is about to head elsewhere. | 18:56 |
|---|---|---|
| jbryce | thanks soren | 18:59 |
| ttx | o/ | 18:59 |
| jbryce | enjoy your day | 18:59 |
| jbryce | #startmeeting | 19:00 |
| openstack | Meeting started Mon Apr 18 19:00:11 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. | 19:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 19:00 |
| jaypipes | o/ | 19:00 |
| dendrobates | o) | 19:00 |
| jbryce | agenda is on the bottom of http://wiki.openstack.org/Governance/PPB | 19:00 |
| jbryce | looks like 4 of us here so far....we'll give the others a couple of minutes to straggle in | 19:01 |
| vishy | o/ | 19:02 |
| jbryce | did you make it out of dfw finally vishy? | 19:03 |
| vishy | eventually | 19:03 |
| vishy | 11 hours from sat to sfo | 19:03 |
| vishy | :( | 19:03 |
| *** ewanmellor has joined #openstack-meeting | 19:03 | |
| jaypipes | vishy: not in Canada? | 19:04 |
| ewanmellor | Hi, sorry I'm late -- had trouble getting on freenode. | 19:04 |
| jaypipes | ewanmellor: no worries, mate. | 19:04 |
| jbryce | ok...let's get going | 19:05 |
| jbryce | #topic "sessionizing" blueprints for summit | 19:05 |
| *** openstack changes topic to ""sessionizing" blueprints for summit" | 19:05 | |
| jbryce | so josh was interested in this one...i think he's planning on joining in a minute, but i've heard this question from a couple of people as well | 19:05 |
| ttx | jbryce: ok | 19:05 |
| jbryce | i saw vishy sent out an email that touched on it a little bit for nova | 19:06 |
| vishy | josh will be here in a few | 19:06 |
| ttx | jbryce: what was the question exactly ? | 19:06 |
| jbryce | the questions i've gotten have been around the use of blueprints for design summit + coding...do they need to create 2 blueprints (one for session and one for code) or just one that will then be used going forward | 19:07 |
| ttx | the same one will be used, if its reusable. | 19:07 |
| jbryce | ok | 19:07 |
| ttx | sometimes the session ends up spawning multiple smaller blueprints | 19:07 |
| ttx | in which case it cas be set as a prereq so that the link is preserved | 19:08 |
| ttx | ideally 1 session = 1 feature = 1 blueprint | 19:08 |
| jbryce | ok | 19:08 |
| dendrobates | ttx isn't all this pretty well documented? | 19:08 |
| *** joshuamckenty_ has joined #openstack-meeting | 19:08 | |
| jbryce | dendrobates: apparently not | 19:08 |
| jbryce | dendrobates: there are a couple of wiki pages, but people still have questions | 19:09 |
| ttx | we have too many sessions and not enough slots, so we try to regroup them | 19:09 |
| ttx | I agree it's not documented very well. | 19:09 |
| jbryce | and i think the docs cover the happy path | 19:09 |
| ttx | We always discover a few days before the summit that we have 60 sessions for 50 slots | 19:09 |
| jbryce | yep | 19:09 |
| jbryce | which is the other question i hear. if my blueprint doesn't get discussed...what next? | 19:10 |
| ttx | so we play a grouping game... which ends up screwing the 1=1=1 rule a bit :) | 19:10 |
| *** comstud has joined #openstack-meeting | 19:10 | |
| jaypipes | I've now read all the proposed blueprints. There are quite a few overlaps. | 19:10 |
| ttx | jbryce: you mean if the BP doesn't get a session at the summit ? or is refused for the summit ? | 19:10 |
| ttx | there are 3 steps... | 19:11 |
| ttx | one is the session at the summit | 19:11 |
| vishy | = | 19:11 |
| ttx | the other is formal acceptation in the "diablo plan" | 19:11 |
| ttx | the last one is the merge proposal | 19:11 |
| ttx | only the last one is *necessary* | 19:11 |
| ttx | but the previous two usually help the last one a lot | 19:12 |
| ttx | especially if you don't want to star tworking on something that will get rejected in the end | 19:12 |
| jbryce | ok | 19:12 |
| dendrobates | or duplicate work | 19:12 |
| ttx | I think vish's email is good | 19:12 |
| jaypipes | ttx: but as vishy eloquently wrote on his ML post, people can certainly work on stuff without a blueprint... and just propose code for merging. | 19:13 |
| jbryce | joshuamckenty_: we're talking blueprints...did you have other q's? | 19:13 |
| ttx | jaypipes: certainly. It's just more risky. | 19:13 |
| jbryce | and blueprints are nice for bubbling information up through ttx's releasestatus script for people who don't see every merge proposal | 19:14 |
| vishy | bak | 19:14 |
| *** jk0 has joined #openstack-meeting | 19:15 | |
| vishy | I was carrying my laptop open so it didn't disconnect and I managed to hold in the power and hard reboot it | 19:15 |
| vishy | FAIL | 19:15 |
| comstud | epic fail! | 19:15 |
| jbryce | i might take a stab at updating some of the wiki pages about blueprints | 19:16 |
| jaypipes | vishy: we were just discussing that your explanation of th eblueprint process (and that someone doesn't *have* to use blueprints) was a good explanation. | 19:16 |
| jbryce | joshuamckenty_: last chance before we move on to next topic if you've got any remaining questions | 19:16 |
| joshuamckenty_ | I'll mail em | 19:16 |
| joshuamckenty_ | Driving | 19:16 |
| jbryce | haha...focus on that then | 19:16 |
| jaypipes | yes, please :) | 19:16 |
| joshuamckenty_ | Tnx | 19:16 |
| jbryce | #topic openstack-common | 19:16 |
| ttx | jbryce: keep me posted, I'll help | 19:16 |
| *** openstack changes topic to "openstack-common" | 19:16 | |
| vishy | jaypipes: thanks, that helps. I lost scrollback | 19:17 |
| jbryce | ttx: thanks...i'll definitely want you to review | 19:17 |
| jaypipes | notmyname: here? | 19:17 |
| notmyname | indeed | 19:17 |
| jbryce | we had some good discussion on the list already around this | 19:17 |
| jaypipes | notmyname: cool, just wanted to make sure you were here for the openstack-common discussion.. | 19:17 |
| vishy | so i think the discussion on the ml was that openstack-auth should be separate | 19:17 |
| jaypipes | ++ | 19:17 |
| vishy | so i think there is a good potential start for openstack-common which is prep for splitting out NaaS and Vaas | 19:18 |
| vishy | so we can start moving some common nova code there that will be shared by the services | 19:19 |
| jaypipes | vishy, notmyname: do we agree that openstack-common is the place to put duplicated "utility" code and stuff like common WSGI handling code, etc? | 19:19 |
| jbryce | besides the specific items, does everyone think the PTLs co-manage openstack-common makes sense? | 19:19 |
| vishy | it doesn't get us that far when it comes to glance/burrow/swift, but at least it starts getting some visibility | 19:19 |
| ttx | jbryce: I think it's OK. If they disagree they should call the PPB to decide. | 19:19 |
| vishy | jaypaipes: yes | 19:19 |
| jaypipes | vishy: so, should we just propose pieces of code for openstack-common? | 19:20 |
| vishy | jbryce: yes i think it will get its own ptl eventually | 19:20 |
| jaypipes | vishy: on the ML or just to the PTLs? (I would prefer the main ML, I think) | 19:20 |
| *** dprince has quit IRC | 19:20 | |
| jbryce | ++ for ML | 19:20 |
| notmyname | it's not clear to me if the proposed -common project is for smaller subprojects or more or a common code library | 19:21 |
| jaypipes | notmyname: the latter I believe. | 19:22 |
| jbryce | notmyname: i think the latter | 19:22 |
| notmyname | vishy: ? same view? | 19:22 |
| dendrobates | i agree | 19:22 |
| jaypipes | notmyname: for "smaller common subprojects", could you elaborate? an example? | 19:22 |
| *** jmckenty has joined #openstack-meeting | 19:23 | |
| vishy | jaypipes: I think it going to have to be one big move on the nova-side to support the split of NaaS and VaaS | 19:23 |
| vishy | I made a blueprint for it | 19:23 |
| notmyname | not sure I have one yet, but I think it would be things like the start of the auth projects. they would eventually grow to need their own structure, but could start in a -common project | 19:23 |
| notmyname | basically, anything that is an internal service that all projects can use | 19:23 |
| jaypipes | vishy: sorry, are you talking about openstack-cmmon stuff? | 19:23 |
| notmyname | perhaps stats or map/reduce tools | 19:24 |
| notmyname | log processing, etc | 19:24 |
| ttx | vishy: note there already is a "NaaS project" BP, maybe that duplicates it ? | 19:24 |
| jbryce | jaypipes: he's talking about splitting out some things that are in nova that would be shared by compute, network and volumes and putting it in -common | 19:24 |
| ttx | notmyname: config file parsing / options processing ? | 19:24 |
| jaypipes | notmyname: I would say if the project has some standalone service, it would go into its own project, but if it is only *library* code that can/should be used by all projects, it would go into openstack-common. I would say log processing would go into openstack-common, but a map-reduce project would be a separate project? | 19:25 |
| jaypipes | jbarratt: ah, sorry. | 19:25 |
| notmyname | ttx: those are less stand-alone, so I would say no (using the model of subprojects vs code library) | 19:25 |
| jaypipes | #agreed | 19:25 |
| ttx | notmyname: oh right | 19:26 |
| jbryce | ok...let me see if we've got consensus around a proposal here | 19:26 |
| jaypipes | notmyname, vishy: there's a lot of code (usually found in files called util.py) that is duplicated across the projects. Those would be a good first start I think? | 19:26 |
| jmckenty | jaypipes and vishy - without being the crazy guy to point out the elephant, doesn't this drift back into the "coding standards" discussion that stalled openstack-common the first time? | 19:27 |
| notmyname | my opinion on a -common project is a place for smaller projects that can stand alone but aren't (or aren't yet) complex enough to need their own governance structure. IMO, -common should be a place where these smaller things can live without neglect from not having PTLs etc | 19:27 |
| jaypipes | jmckenty: yep. ;) | 19:27 |
| jmckenty | notmyname: I would try and avoid cramming the "incubator" projects (DUPLO) into common | 19:28 |
| jmckenty | but I agree we need a "common" area for them | 19:28 |
| vishy | notmyname: if that is the case, we need a different place to put shared code | 19:28 |
| jmckenty | I like the semantics of -common for shared libraries | 19:28 |
| ttx | jmckenty: +1 | 19:28 |
| jbryce | openstack-common will be made up primarily of library code that may be used by multiple projects. initially, it will be co-managed by the other projects' PTLs who will determine the best options for inclusion and the process for code acceptance. at some point, it will make sense for openstack-common to have its own PTL. | 19:28 |
| jmckenty | and -duplo for subprojects that aren't yet distinct | 19:28 |
| jaypipes | jmckenty: DUPLO? | 19:29 |
| jmckenty | but really, -duplo projects are still going to have their own repos, right? | 19:29 |
| vishy | jmckenty: right | 19:29 |
| jmckenty | ah, sorry. DUPLO is big, baby lego | 19:29 |
| jaypipes | heh, ok. | 19:30 |
| jmckenty | if openstack == lego, openstack incubation == duplo | 19:30 |
| jaypipes | gotcha :) | 19:30 |
| ewanmellor | Couldn't we have "incubator" projects just stand on their own? A map-reduce project, for example, can just live on Launchpad/github somewhere. It doesn't need to be openstack- anything. | 19:30 |
| jaypipes | jmckenty, vishy: yes, I would assume DUPLO projects would get their own repo entirely | 19:30 |
| ttx | yes, I expect -duplo projects to be separated when they start. And lead by their original PTL untli they get their own | 19:30 |
| jmckenty | right, that's what I meant | 19:30 |
| jmckenty | so back to -common | 19:30 |
| jbryce | i think incubation and common are distinct | 19:30 |
| jbryce | yes | 19:31 |
| ttx | for example, vish would lead a separated "volumes" projetc until it gets its own PTL, but it would have its own repo as soon as it's split | 19:31 |
| jmckenty | can we agree that PPB can own -common as far as coding standards? | 19:31 |
| jaypipes | notmyname: OK, so would you go along with openstack-common being for common library code, not stand-alone projects? | 19:31 |
| jmckenty | and we can hope that those standards would drift back into the distinct projects as well go along | 19:31 |
| vishy | ttx: yes but splitting is a challenge unless we have a place to put common code | 19:31 |
| vishy | does openstack-volumes import nova to get shared files such as manager.py / service.py etc.? | 19:32 |
| vishy | or do we put it into openstack-common? | 19:32 |
| jmckenty | I think it goes into common | 19:32 |
| ttx | vishy: both options are valid. I'd prefer it to go to -common ultimately | 19:32 |
| jmckenty | but that means we need to prioritize any merge prop related to -common | 19:32 |
| jmckenty | so that we don't block multiple projects | 19:32 |
| vishy | my thought is that we put it into common and nova / NaaS / VaaS imports it | 19:32 |
| jmckenty | er, subprojects | 19:32 |
| jaypipes | vishy: I would prefer that code that is shared go into openstack-common, I mean that's what it was intended for. The issue is going to be agreeing on the coding standards and style of code that goes in there :) | 19:32 |
| jaypipes | vishy: that was precisely the intent of openstack-common, yes. | 19:33 |
| jaypipes | so, from openstack.common import logging... | 19:33 |
| vishy | jmckenty: i think the subprojects can subclass / override common code so they don't have to be blocked | 19:33 |
| jmckenty | right, I meant factoring OUT the common code | 19:33 |
| jmckenty | to make it available | 19:33 |
| vishy | ah right | 19:34 |
| ewanmellor | And also we'll have to be stricter on the interface for things like manager.py. The interface to that probably isn't well enough defined to be split out yet. | 19:34 |
| jmckenty | that's a tough Order of Ops problem | 19:34 |
| vishy | ewanmellor: all this stuff is vital to prepare for separate projects though | 19:34 |
| jmckenty | we need to factor it out first, so we can start prototyping against it in multiple projects, so we end up with the right data points on what the interface needs to be | 19:34 |
| ewanmellor | vishy: I agree entirely. | 19:35 |
| jmckenty | but of course, we'll have more points of impact if we change it later | 19:35 |
| vishy | we also need good tooling to make it easy for devs to work with multiple projects | 19:35 |
| vishy | something like svn-externals | 19:35 |
| jmckenty | Can I suggest stronger version promises for openstack-common | 19:35 |
| jmckenty | ? | 19:35 |
| jaypipes | OK, so can we agree on a process for getting stuff into openstack-common? Do we just use merge proposals? | 19:35 |
| jmckenty | e.g., rather than supporting just a few versions back, we need to support at least <N>? | 19:36 |
| vishy | so I have a blueprint for this work, but the scope is a little undefined at the moment | 19:36 |
| jmckenty | vishy: I think something like externals is a first step, but I can feel the arguments for paste building... | 19:37 |
| ttx | jaypipes: who is responsible for the -common merge proposals ? All -core teams combined ? A subgroup of interested dudes ? | 19:37 |
| dendrobates | I vote for all -core teams | 19:37 |
| jmckenty | ttx: I would vote for just PPB for the time being | 19:37 |
| jaypipes | fine by me. | 19:37 |
| jaypipes | either way. | 19:37 |
| jmckenty | all of -core is a lot of developers | 19:37 |
| jmckenty | I think arguing over the standards bit will be easiest with a subset | 19:38 |
| ttx | jmckenty: yes that's what I was thinking. | 19:38 |
| jaypipes | well, it's the developers who will have to use and be comfortable using the code in openstack-common. The last thing we want is people bitching about the code in a common library. | 19:38 |
| jmckenty | but maybe go to all of -core if it's disputed? | 19:38 |
| dendrobates | if we limit the group too much, reviews will be hard to come by | 19:38 |
| jmckenty | hence my proposal that they get bumped in priority | 19:38 |
| jaypipes | how about this: goes to PPB devs. If not a consensus agreement, throw it to ML for discussion on best practice/code style? | 19:40 |
| ttx | or maybe, two approvals including one PPB review ? | 19:40 |
| jmckenty | ttx: +1 | 19:40 |
| jmckenty | With a goal to document the approved coding standards and turn it back over to -core within 3 releases? | 19:40 |
| jaypipes | sure | 19:41 |
| jaypipes | sounds like a plan. | 19:41 |
| *** joshuamckenty_ has quit IRC | 19:41 | |
| ttx | right, I don't expect the standards to become an issue after a few cycles | 19:41 |
| jbryce | member:openstack-common will be made up primarily of library code that may be used by multiple projects. initially, it will be co-managed by the other projects' PTLs who will determine the best options for inclusion. at some point, it will make sense for member:openstack-common to have its own PTL. code will be accepted using the standard merge proposal process with a requirement of 2 reviews including at least one from a m | 19:41 |
| jbryce | of the PPB | 19:41 |
| jbryce | ? | 19:42 |
| vishy | yes, and we can use the design summit discussion to scope the initial move of code / tooling and select a team to start working on it | 19:42 |
| jaypipes | #agreed | 19:42 |
| jmckenty | I would amend co-managed to be by the PPB, rather than just PTLs, only so that we have a good mechanism to talk about -common support of upcoming subprojects | 19:42 |
| jmckenty | but I'm not attached | 19:42 |
| jbryce | i'm ok with that amendment if there aren't other objections | 19:43 |
| ttx | #agreed | 19:43 |
| * jmckenty can get vishy to represent for the disenfranchised | 19:43 | |
| jmckenty | #agreed | 19:43 |
| ewanmellor | #agreed | 19:43 |
| jbryce | dendrobates, notmyname? | 19:43 |
| ttx | having the PPB manage it is more coherent with the approval rule | 19:43 |
| notmyname | thinking | 19:44 |
| dendrobates | I'm fine with it. | 19:44 |
| jbryce | notmyname: that's a lot of thinking | 19:44 |
| notmyname | heh | 19:45 |
| jbryce | last call for objections | 19:46 |
| notmyname | I'm not a big fan of -common as a shared code library, but if that is what the consensus is, the above proposal is good | 19:46 |
| * jmckenty plays jeopardy music | 19:46 | |
| jbryce | well...it does seem to be the consensus for now | 19:46 |
| jmckenty | notmyname: you can +0 it | 19:46 |
| jmckenty | or even -0 it | 19:46 |
| jmckenty | and then later you can say I told you so | 19:47 |
| jbryce | we can also change the charter later or address shared services in some better way | 19:47 |
| jbryce | #agreed openstack-common will be made up primarily of library code that may be used by multiple projects. initially, it will be co-managed by the PPB who will determine the best options for inclusion. at some point, it will make sense for openstack-common to have its own PTL. code will be accepted using the standard merge proposal process with a requirement of 2 reviews including at least one from a member of the PPB | 19:48 |
| jbryce | #topic coordination between other open initiatives | 19:48 |
| *** openstack changes topic to "coordination between other open initiatives" | 19:48 | |
| jbryce | so jmckenty....want to lead this one? | 19:48 |
| jmckenty | yup | 19:48 |
| jmckenty | So I met with the Nimbus, OpenNebula and Globus folks | 19:48 |
| jmckenty | and told them that I thought their projects were the walking dead | 19:49 |
| jbryce | haha | 19:49 |
| jmckenty | and that they should join forces with OpenStack before we made them irrelevant | 19:49 |
| ttx | jmckenty: you know how to please them. | 19:49 |
| jbryce | i have a hard time imagining you saying something like that, josh | 19:49 |
| jmckenty | So they're very interested in collaborating | 19:49 |
| jmckenty | I showed a chart comparing the number of users in IRC, the number of commits, etc | 19:49 |
| jmckenty | it was compelling | 19:49 |
| jmckenty | So they'd like to figure out how to work with openstack without giving up their individual branding | 19:50 |
| jmckenty | and, hence, their funding | 19:50 |
| jmckenty | There are some logical points of collaboration, particularly the new subprojects | 19:50 |
| jmckenty | e.g., NaaS, the queue service, some of the unified auth proposals, etc | 19:51 |
| jmckenty | I also see possibilities with MapReduce / computable object store, or some of the distributed filesystem support (Sheepdog, ceph) | 19:51 |
| dendrobates | I have talked to opennebula and eucalyptus about collaborating on NaaS, they are interested. | 19:51 |
| jmckenty | so the thinking was, to put together some guidelines for "ambassadors" to these other projects | 19:51 |
| notmyname | ttx: these are some of the issues that I was thinking of when I was talking with you the other day about release processes. I think these issues are related | 19:52 |
| jmckenty | Open questions: | 19:52 |
| jmckenty | 1. Do the relevant organizations need to join OpenStack? | 19:52 |
| ttx | notmyname: how ? | 19:52 |
| jmckenty | (E.g. Argonne or Fermi Labs, John Hopkins, Notre Dame, etc) | 19:52 |
| jmckenty | 2. License compatability | 19:53 |
| jmckenty | My bias is that all openstack projects should continue to be Apache2 | 19:53 |
| jmckenty | which precludes wholesale donations of code, but so be it | 19:53 |
| ewanmellor | Does it preclude donations from all of those people? | 19:54 |
| jmckenty | no | 19:54 |
| jmckenty | just some | 19:54 |
| ewanmellor | Do you know which ones? | 19:54 |
| jmckenty | I'd have to go back through the list | 19:54 |
| notmyname | jmckenty: agreed on licensing | 19:54 |
| jmckenty | 3. Can the PPB recommend commercial partners without getting into a tricky position? | 19:55 |
| jmckenty | E.g., can I tell Argonne to talk to Dell and RCB about a test cloud using OpenStack? | 19:55 |
| jmckenty | 4. Our relationship with the OCC and the Science Data Cloud project | 19:55 |
| jmckenty | I'm going to bring up the OCC again next week when we're talking about governance, | 19:56 |
| jmckenty | especially since they're getting ready to switch the Science Data Cloud to OpenStack | 19:56 |
| jmckenty | But it may be a lot easier for these organizations to structure any type of cloud collaboration within the OCC (where they're already members, and which is perceived as 'neutral' to the different projects) | 19:57 |
| jmckenty | Is that workable for us? | 19:57 |
| notmyname | ttx: we can discuss at the summit (don't want to get off track here) | 19:57 |
| ttx | notmyname: ok | 19:57 |
| jaypipes | jmckenty: #agreed | 19:57 |
| jbryce | jmckenty: that's a lot... | 19:58 |
| * jbryce thinking like notmyname | 19:58 | |
| jmckenty | Basically, item 4. is a more general question of "How do we make it easy for academic organizations to join/participate?", and "Should we take advantage of the OCC for it?" | 19:59 |
| jmckenty | I'm happy to defer this to the in-person meeting next week | 19:59 |
| jmckenty | just wanted to put it under everyone's hat | 19:59 |
| jbryce | yeah...we're up against our hour anyway | 20:00 |
| jbryce | let's defer to next week and think about it in the meantime | 20:00 |
| ewanmellor | Could you give me that list of potential academic collaborators again? | 20:00 |
| jmckenty | two secs...http://opencloudconsortium.org/members/ | 20:00 |
| ewanmellor | I will ask the "how do academic orgs collaborate" question of a few people at Cambridge U who've done this many times before. | 20:00 |
| jmckenty | Plus Notre Dame and Fermi Labs | 20:01 |
| jmckenty | jbryce: sounds good | 20:01 |
| jmckenty | actually, can we get a quick show of hands of who'd like to be involved in this? | 20:01 |
| jmckenty | if it's much less than the full PPB, we can make a working group and it'll make scheduling easier | 20:02 |
| jbryce | i'm interested | 20:02 |
| ewanmellor | Me | 20:03 |
| jaypipes | jmckenty: sure | 20:03 |
| jbryce | ok | 20:03 |
| jbryce | #topic next meetings | 20:03 |
| *** openstack changes topic to "next meetings" | 20:03 | |
| jbryce | is there a time that works for doing an in person meeting at the design summit? | 20:04 |
| jmckenty | Something involving beer? | 20:04 |
| jbryce | i know the summit sessions are already packed in, so yanking everyone out for an hour during the day may not be ideal.... | 20:04 |
| ttx | jbryce: beer o clock, one of those days ? | 20:04 |
| jbryce | jmckenty: that's what i'm thinking | 20:04 |
| jmckenty | The breakfast meeting last time was rough to get everyone to on time | 20:04 |
| dendrobates | yeah, evenings are best | 20:05 |
| jbryce | yep | 20:05 |
| jmckenty | there are three sponsored parties, which night is free so far? | 20:05 |
| jbryce | not sure any night is free | 20:05 |
| jbryce | but we might just squeeze in some time before a party | 20:05 |
| ttx | the wed night is mostly free | 20:05 |
| dendrobates | parties are optional in my book, we can always arrive late | 20:05 |
| jbryce | wed works for me | 20:06 |
| jbryce | we'll plan for wednesday evening | 20:06 |
| jbryce | and then for our regular time, does anyone have a pref for moving from 2000 UTC thursdays? | 20:07 |
| ttx | I'd prefer 1900 UTC, any day but Tuesday. | 20:08 |
| ttx | is this every week or every two weeks ? | 20:08 |
| jmckenty | every week | 20:08 |
| ttx | ok | 20:09 |
| jmckenty | unless there's nothing on the docket | 20:09 |
| notmyname | I'd prefer 1900 UTC | 20:09 |
| jmckenty | I'm fine with 1900 | 20:09 |
| jaypipes | no objections from me. | 20:09 |
| jbryce | ok | 20:09 |
| jbryce | works for me | 20:09 |
| jbryce | i'll send a note out | 20:09 |
| ttx | cool. | 20:09 |
| jmckenty | doublecool | 20:09 |
| jbryce | that's all i've got | 20:09 |
| dendrobates | one last thing | 20:09 |
| jbryce | #topic open discussion | 20:09 |
| *** openstack changes topic to "open discussion" | 20:09 | |
| dendrobates | Rackspace is sponsoring a mini NaaS summit on Monday before the summit | 20:10 |
| dendrobates | it will be in the summit hotel. | 20:10 |
| dendrobates | I just wanted to make sure everyone knew about it. | 20:10 |
| jmckenty | I didn't | 20:11 |
| dendrobates | All the parties are going to try and agree on a starting point | 20:11 |
| jmckenty | time and date? | 20:11 |
| jmckenty | e.g., room and start time | 20:11 |
| dendrobates | Erik Carlin in planning it | 20:11 |
| jmckenty | k | 20:11 |
| dendrobates | It is monday, that is all I know | 20:11 |
| jmckenty | that's Easter Monday, right? | 20:11 |
| dendrobates | yep | 20:11 |
| dendrobates | I complained about that | 20:11 |
| jmckenty | I've got children who will be all sugared up | 20:11 |
| jmckenty | will see what I can do | 20:12 |
| dendrobates | me too. I will be arriving late to the meeting. | 20:12 |
| jbryce | jmckenty: bring the kids | 20:12 |
| ttx | my plane arrives monday evening, so will miss it | 20:12 |
| jbryce | ttx: mine too | 20:12 |
| jbryce | anyone have anything else? | 20:12 |
| ttx | nope. | 20:13 |
| jmckenty | not for now | 20:13 |
| jbryce | thanks guys | 20:13 |
| jbryce | see you all in a week | 20:13 |
| jbryce | #endmeeting | 20:13 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 20:13 | |
| openstack | Meeting ended Mon Apr 18 20:13:58 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:14 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-04-18-19.00.html | 20:14 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-04-18-19.00.txt | 20:14 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-04-18-19.00.log.html | 20:14 |
| *** ewanmellor has quit IRC | 20:14 | |
| *** jk0 has left #openstack-meeting | 20:14 | |
| *** eday has joined #openstack-meeting | 20:15 | |
| eday | doh, confused timezones | 20:16 |
| jaypipes | eday: :) | 20:17 |
| *** jmckenty has quit IRC | 20:31 | |
| *** markwash has joined #openstack-meeting | 21:24 | |
| *** dendrobates is now known as dendro-afk | 21:52 | |
| *** dendro-afk is now known as dendrobates | 22:11 | |
| *** VanpoofFluffy-ku has quit IRC | 22:19 | |
| *** ovidwu has quit IRC | 22:42 | |
| *** ovidwu has joined #openstack-meeting | 22:43 | |
| *** edconzel has quit IRC | 22:44 | |
| *** jkoelker has quit IRC | 23:44 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!