| *** sebastianstadil has quit IRC | 00:17 | |
| *** heckj has quit IRC | 00:39 | |
| *** adjohn has joined #openstack-meeting | 01:11 | |
| *** zul has joined #openstack-meeting | 01:26 | |
| *** dendro-afk is now known as dendrobates | 01:37 | |
| *** sebastianstadil has joined #openstack-meeting | 02:05 | |
| *** dendrobates is now known as dendro-afk | 02:12 | |
| *** vladimir3p has joined #openstack-meeting | 02:38 | |
| *** dendro-afk is now known as dendrobates | 02:39 | |
| *** medberry is now known as med_out | 04:01 | |
| *** cbeck has quit IRC | 04:03 | |
| *** cbeck has joined #openstack-meeting | 04:03 | |
| *** santhosh has joined #openstack-meeting | 04:12 | |
| *** santhosh has quit IRC | 04:22 | |
| *** santhosh has joined #openstack-meeting | 04:22 | |
| *** santhosh has quit IRC | 04:25 | |
| *** Binbin has joined #openstack-meeting | 04:34 | |
| *** sebastianstadil has quit IRC | 04:38 | |
| *** sebastianstadil has joined #openstack-meeting | 04:59 | |
| *** Binbin has joined #openstack-meeting | 05:09 | |
| *** vladimir3p has quit IRC | 07:06 | |
| *** Binbin has quit IRC | 09:06 | |
| *** Binbin has joined #openstack-meeting | 09:07 | |
| *** Binbin has quit IRC | 09:29 | |
| *** Binbin has joined #openstack-meeting | 09:42 | |
| *** sebastianstadil has quit IRC | 09:47 | |
| *** chmouel has quit IRC | 09:49 | |
| *** chmouel has joined #openstack-meeting | 09:51 | |
| *** Binbin has quit IRC | 10:16 | |
| *** GasbaKid has joined #openstack-meeting | 10:18 | |
| *** adjohn has quit IRC | 10:39 | |
| *** adjohn has joined #openstack-meeting | 11:23 | |
| *** zul has quit IRC | 11:24 | |
| *** zul has joined #openstack-meeting | 11:24 | |
| *** GasbaKid has quit IRC | 11:38 | |
| *** adjohn has quit IRC | 11:39 | |
| *** adjohn has joined #openstack-meeting | 12:13 | |
| *** med_out is now known as medberry | 13:26 | |
| *** edconzel has joined #openstack-meeting | 13:43 | |
| *** jkoelker has joined #openstack-meeting | 14:24 | |
| *** vladimir3p has joined #openstack-meeting | 14:34 | |
| *** dragondm has joined #openstack-meeting | 14:40 | |
| *** adjohn has quit IRC | 14:52 | |
| *** dendrobates is now known as dendro-afk | 15:15 | |
| *** dendro-afk is now known as dendrobates | 15:16 | |
| *** heckj has joined #openstack-meeting | 15:30 | |
| *** johnpur has joined #openstack-meeting | 15:31 | |
| *** dendrobates is now known as dendro-afk | 15:35 | |
| *** dendro-afk is now known as dendrobates | 16:04 | |
| *** Tv has joined #openstack-meeting | 16:30 | |
| *** primeministerp has joined #openstack-meeting | 17:54 | |
| *** masumotk has joined #openstack-meeting | 18:08 | |
| *** masumotk has quit IRC | 18:15 | |
| *** edconzel has quit IRC | 18:36 | |
| *** markvoelker has joined #openstack-meeting | 18:36 | |
| *** masumotok has joined #openstack-meeting | 18:39 | |
| *** jbryce has joined #openstack-meeting | 18:49 | |
| *** nati has joined #openstack-meeting | 18:59 | |
| mtaylor | k. who's ready to talk about CI and testing stuffs? | 19:00 |
|---|---|---|
| nati | Hi I am OK | 19:01 |
| *** dabo has joined #openstack-meeting | 19:01 | |
| mtaylor | great! we have someone other than me. :) | 19:01 |
| mtaylor | we'll give people a few to see who shows up | 19:01 |
| markwash | mtaylor: I'm here, sort of standing in for dan prince | 19:02 |
| mtaylor | sweet. good to have you | 19:02 |
| mtaylor | #startmeeting | 19:02 |
| openstack | Meeting started Tue Jun 14 19:02:42 2011 UTC. The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot. | 19:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 19:02 |
| termie | HOYOO | 19:02 |
| markwash | :-) | 19:03 |
| mtaylor | #info Added an agenda overview to the wiki | 19:03 |
| mtaylor | #link http://wiki.openstack.org/Meetings/CITeamMeeting | 19:03 |
| mtaylor | So - I guess let's get this puppy rolling | 19:04 |
| mtaylor | #topic Discuss/Present overall CIPlan as it currently stands | 19:04 |
| *** openstack changes topic to "Discuss/Present overall CIPlan as it currently stands" | 19:04 | |
| jaypipes | o/ | 19:04 |
| termie | so, starting with ciplan | 19:04 |
| mtaylor | yup. seemed like a good idea to start at the beginning | 19:05 |
| termie | which smoke testing are you referring to? | 19:05 |
| mtaylor | #link http://wiki.openstack.org/CIPlan | 19:05 |
| mtaylor | well, right now to the jenkins job which is useless | 19:05 |
| termie | the stuff in /smoketests only? | 19:05 |
| mtaylor | I was _actually_ just talking about the infrastructure to run it - but yes, to run the stuff in nova's /smoketests | 19:06 |
| *** dprince has joined #openstack-meeting | 19:06 | |
| termie | so, for those the general plan is: start a vm, provision with chef, point smoketests at them | 19:07 |
| termie | at the moment ex-anso has been using vagrant because it automates a good portion of the things we need to do to set up a multinode cluster | 19:07 |
| mtaylor | yup. although I'd say the general plan is "start a vm, install/provision with something, test them" | 19:08 |
| termie | but you seem to be set on using external cloud servers | 19:08 |
| termie | i am asking for a more concrete plan | 19:08 |
| mtaylor | indeed. | 19:08 |
| termie | "something" == chef scripts from openstack-recipes | 19:08 |
| termie | in my opinion | 19:08 |
| mtaylor | what I was going to say is that for now "install/provision with something" seems to be chef as a best practice | 19:08 |
| mtaylor | yes | 19:08 |
| termie | if there is no disagreement lets start saying htat | 19:08 |
| termie | instead of something | 19:08 |
| mtaylor | we were starting at the beginning here today, so I thought we'd be clear | 19:09 |
| termie | we are clarlifying | 19:09 |
| nati | Will chef scripts be standard openstack deployment tool? | 19:09 |
| termie | nati: i think they will be one of them, the puppet guys will also have a set of tools | 19:09 |
| mtaylor | nati: that's certainly a possibility | 19:09 |
| mtaylor | yeah - and getting in to chef v. puppet is certainly not something I care to do anytime in my personal near future | 19:10 |
| nati | I think OpenStack should have an official deployment tool, and Smoketesting tool should use the official one. | 19:10 |
| termie | nati: agreed, but we can't make the political statement right now | 19:10 |
| mtaylor | ++ | 19:10 |
| nati | Because we should test deployment tool also. | 19:10 |
| termie | nati: for now we are going to use the chef recipes | 19:10 |
| mtaylor | right. because they are what's there | 19:10 |
| termie | and our docs will describe the usage of those | 19:10 |
| termie | and our tools will depend on them | 19:11 |
| nati | agreed | 19:11 |
| termie | the puppet guys will do owrk to make those tools able to use puppet as well | 19:11 |
| *** medberry is now known as med_out | 19:11 | |
| termie | but that onus is on them | 19:11 |
| termie | we like them we just have more inertia on chef right now | 19:11 |
| termie | so, for the vm stuff, shall we say we use rackspace cloud servers? | 19:11 |
| termie | or vagrant? | 19:11 |
| mtaylor | yes. I think that gets us the best ability to do many of these in parallel | 19:12 |
| jaypipes | RCS. | 19:12 |
| termie | we also can get them more cheaply than amazon i assume | 19:12 |
| mtaylor | yes. yes we can :) | 19:12 |
| dprince | Chef cookbooks written properly should work on bare metal, cloud, or a personal VM on your laptop (vagrant). | 19:12 |
| mtaylor | which then gets us to getting the damn thing working | 19:12 |
| termie | dprince: yup, that's the goal | 19:12 |
| mtaylor | dprince: yes. agree | 19:12 |
| mtaylor | the two approaches on the table in my head for making this happen are: | 19:13 |
| dprince | So the way I see us collaboration working here is we collaborate on good config management practices. | 19:13 |
| mtaylor | openstack_vpc fired from jenkins - or just firing up a node and doing the chef bits on it by hand | 19:13 |
| *** joshuamckenty_ has joined #openstack-meeting | 19:13 | |
| termie | what is openstack_vpc? | 19:13 |
| mtaylor | I am, at this point, fine with either | 19:14 |
| mtaylor | openstack_vpc is the thing that powers smokestack | 19:14 |
| jaypipes | termie: https://github.com/dprince/openstack_vpc | 19:14 |
| termie | cool, will that kick of chef pieces? | 19:14 |
| mtaylor | yes | 19:14 |
| dprince | Yep. | 19:14 |
| *** joshuamckenty_ has quit IRC | 19:14 | |
| termie | perfect, lets use that | 19:14 |
| mtaylor | the main question I have for folks there is | 19:14 |
| termie | we can make dprince make it ddo what we want :)) | 19:14 |
| jaypipes | termie: https://github.com/rackspace/chef_vpc_toolkit | 19:14 |
| nati | Is there any limitations of VPC? | 19:14 |
| dprince | Termie, I forked the Anso cookbooks and have made a couple minor changes to get things working in the cloud. | 19:14 |
| *** joshuamckenty_ has joined #openstack-meeting | 19:15 | |
| dprince | nati: The limitations of VPC are the same limitations you'd hit on Cloud Servers. | 19:15 |
| mtaylor | is requires redis, which also is used in the nova unit tests - is there any reason to think that running openstack_vpc on the jenkins box will bork the unit tests | 19:15 |
| termie | dprince: bug xtoddx to get them integrated? | 19:15 |
| termie | where is the redis requirement? | 19:15 |
| termie | nova doesn't use redis anywhere anymore i thought | 19:15 |
| jaypipes | termie: smokestack does... | 19:16 |
| mtaylor | great! I just know that there were already redis processes on the jenkins box, and I didn't want to step on anything | 19:16 |
| dprince | termie: Smokestack uses --> Cloud Servers VPC. Both of these are Rails apps for which I'm using a Redis backed job queue (Resque). | 19:16 |
| markwash | mtaylor: I don't think openstack_vpc needs redis | 19:16 |
| markwash | mtaylor: just the stuff built on top of it | 19:16 |
| mtaylor | problem solved then - redis on jenkins box is historical and non-conflicting | 19:16 |
| dprince | mtaylor: I'm happy to let you have access to the Cloud Servers VPC instance we are using on Titan. | 19:16 |
| termie | dprince: so vpc is not a command-line tool | 19:16 |
| termie | ? | 19:16 |
| dprince | termie: openstack_vpc is a set of config files and rake tasks to spin up testing groups. | 19:17 |
| mtaylor | dprince: well - main thing is that I need for jenkins to be able to fire the commands - probably easier to just install it on the jenkins box, yeah? | 19:17 |
| dprince | termie: it is command line driven. | 19:17 |
| dprince | Smokestack scripts it. | 19:17 |
| termie | dprince: but we have to have a server running all the time that hits that server? | 19:17 |
| termie | erm | 19:17 |
| termie | and a cli that hits that server | 19:17 |
| dprince | termie: openstack_vpc uses Cloud Servers VPC to spin up cloud servers. | 19:18 |
| mtaylor | termie: Cloud Servers VPC is an always running rails app - so yes | 19:18 |
| termie | and what does its always running get us over having it just do a one-shot thing? | 19:19 |
| mtaylor | dprince: I couldn't figure out how to get openstack_vpc to talk to a cloud servers vpc on another box ... was I just missing something? | 19:19 |
| termie | the queuing and such can be handled by jenkins, is what i am getting at | 19:19 |
| mtaylor | termie: yes | 19:19 |
| mtaylor | so - eventually I want to just have jenkins spin up the servers and do the chef bits | 19:19 |
| *** creiht has joined #openstack-meeting | 19:20 | |
| termie | agreed, but i think we should be using a common tool for that | 19:20 |
| mtaylor | but having jenkins call openstack_vpc should get us further today | 19:20 |
| termie | and it sounds like vpc has the pieces for it | 19:20 |
| mtaylor | yes | 19:20 |
| termie | i just don't want another long running process to maintain | 19:20 |
| dprince | So I'm already running each trunk commit in SmokeStack (via a Jenkins). I'm happy to move that move that bit over to the public Jenkins now if you guys would like. | 19:20 |
| termie | that would be grand | 19:21 |
| mtaylor | ++ | 19:21 |
| termie | have mtaylor make you admin'y? | 19:21 |
| mtaylor | there are things I would like to do with that setup long term - but that gets us a thing we need today | 19:21 |
| mtaylor | and we can talk about the other long term things later | 19:21 |
| dprince | Yes. | 19:21 |
| mtaylor | dprince: are you dprince on launchpad? | 19:21 |
| termie | so | 19:21 |
| dprince | I'm dan-prince. | 19:21 |
| termie | we set up an openstackvpc instance (probably just steal titan's for now) | 19:21 |
| mtaylor | dprince: ok. you are now an admin on the openstack jenkins | 19:22 |
| dprince | Also. I'm happy to make Cloud Servers VPC available for anyone else to use as well. | 19:22 |
| termie | we deploy a single and multinode setup as per anso's old vagrant testing, and run the nova smoketests against ahtat | 19:22 |
| nati | Can we test VLANManager on VPC? | 19:22 |
| termie | smokestack is just doing openstack api, right>? | 19:22 |
| dprince | termie: I'm now running the nova smoketests too. | 19:23 |
| termie | ooo | 19:23 |
| mtaylor | great | 19:23 |
| termie | so | 19:23 |
| dprince | termie: minus volume tests. | 19:23 |
| termie | ah, do we think there is a way to integrate those? | 19:23 |
| dprince | The issue is I can't get iscsi-target to run on Cloud Servers. | 19:23 |
| termie | i'd say in that case lets just ditch the first section of CIPlan and replace it with smokestack | 19:23 |
| mtaylor | dprince: is it possible to run them with the xunit xml output and get those copied back to the jenkins box? | 19:23 |
| termie | ah | 19:24 |
| dprince | mtaylor: Sure. We can do that. | 19:24 |
| termie | it sounds like titan has a strong lead on most of this | 19:24 |
| mtaylor | termie: well - the whole thing here is that we want to get this integrated with jenkins so that we can eventually add it to the tarmac stuff | 19:24 |
| mtaylor | yup | 19:24 |
| dprince | So. On that front I actually have mixed feelings. | 19:24 |
| termie | mtaylor: right, just saying integrate smokestack instead of writing your own bits | 19:25 |
| mtaylor | totally | 19:25 |
| termie | dprince: oh? do tell :) | 19:25 |
| dprince | Is the idea that we would prevent (block the trunk commit) if the functional tests fail? | 19:25 |
| mtaylor | if he's already got that work done on a different jenkins | 19:25 |
| mtaylor | maybe - the idea is that I want to be able for us to make that choice | 19:25 |
| mtaylor | physically | 19:25 |
| mtaylor | so that the choice is policy and not lack of ability | 19:25 |
| dprince | The model we've been following on Titan is we run branches in merge prop. Heavily. Its kind of a review tool. | 19:25 |
| termie | dprince: i think that is a tarmac config issue rather than a jenkins config issue | 19:25 |
| termie | dprince: we want that as well | 19:26 |
| mtaylor | so on _that_ one _I_ have mixed feelings | 19:26 |
| termie | dprince: we == ansoy people at least | 19:26 |
| mtaylor | which is a security thing | 19:26 |
| mtaylor | running heavily on branches from known folks is one thing | 19:26 |
| termie | right | 19:26 |
| *** edconzel has joined #openstack-meeting | 19:26 | |
| mtaylor | running code from _any_ unreviewed merge prop is, well, fail | 19:26 |
| dprince | Right. But what I'm getting at is any time you have functional tests there is a chance it could fail due to an external dependency. Something like the network was down, launchpad, GitHub, etc. | 19:26 |
| mtaylor | totally | 19:26 |
| dprince | I'd hate to hold up a trunk commit if there is a long lived dependency failure. | 19:27 |
| mtaylor | I have no issues holding up a trunk committ | 19:27 |
| mtaylor | the whole idea is to keep trunk in good shape | 19:27 |
| termie | dprince: well, once we're on github some of those things will be a little bit easier to work around | 19:27 |
| mtaylor | but that's a whole other thing | 19:27 |
| termie | dprince: it is relatively easy to integrate things into your dev tree and take them back out later | 19:28 |
| mtaylor | I don't think any part of this has anything to do with github v. launchpad - but that's _also_ a different conversation | 19:28 |
| dprince | Sure. I just wanted to make sure everyone was on the same page. | 19:28 |
| mtaylor | yup. for now... | 19:28 |
| mtaylor | dprince: can I put you down with an action of getting smokestack jenkins job done? | 19:28 |
| dprince | Also the tests as is take 15 minutes. Is that everyone acceptable with that? | 19:28 |
| dprince | mtaylor: Sure. I can take that. | 19:29 |
| mtaylor | #action dprince make smokestack jenkins job | 19:29 |
| termie | for now we don't automatically run against merge props and will try gating merges on them with the option that we might need to turn that off | 19:29 |
| *** mrmartin has joined #openstack-meeting | 19:29 | |
| mtaylor | yes. | 19:29 |
| termie | titan can continue doing it for their own stuff, obvs | 19:29 |
| mtaylor | although gating merges will have to wait for now on some jenkins/tarmac work - but that should be done soon enough - for now, notification will be a huge win | 19:30 |
| termie | step 1, public smokestack, step 2, tarmac integration | 19:30 |
| mtaylor | yup | 19:30 |
| termie | want to move to baremetal bits? | 19:30 |
| dprince | Sure. So just to be clear. You want me to make a simple Jenkins job that runs each time we have a trunk commit. This gives you the indicator light on Jenkins you want? | 19:30 |
| mtaylor | yes | 19:31 |
| mtaylor | and | 19:31 |
| termie | dprince: we'll want to get nosexunit out | 19:31 |
| mtaylor | dprince: also - take a peek at the nova-sometest job at the nosexunit output stuff | 19:31 |
| mtaylor | because we want that too | 19:31 |
| dprince | Sure. | 19:31 |
| mtaylor | baller | 19:31 |
| * mtaylor will purchase for dan prince a beer | 19:31 | |
| dprince | One the bare metal thing. I've got 4 nodes that I'm working on getting integrated with XenServer testing. | 19:31 |
| termie | are we moving to baremetal now? | 19:32 |
| termie | meetingbot | 19:32 |
| mtaylor | #topic Jenkins job to integrate/fire bare metal testing | 19:32 |
| *** openstack changes topic to "Jenkins job to integrate/fire bare metal testing" | 19:32 | |
| termie | "< dprince> One the bare metal thing. I've got 4 nodes that I'm working on getting integrated with XenServer testing. | 19:32 |
| termie | i am wondering what rpath is offering | 19:33 |
| mtaylor | rpath is offereing something for this similar to what dprince just offered for functional | 19:33 |
| termie | we had a nicely working pxe + ubuntu bootstrap setup working already | 19:33 |
| termie | that only needed the chef provisioning bits on the client side | 19:33 |
| dprince | For bare metal testing I'm actually very interested in using Dells Crowbar project. | 19:33 |
| mtaylor | they currently have a jenkins running jobs that inject images in to cobbler and stuff | 19:33 |
| termie | dprince: everybody is but it doens't exist yet | 19:33 |
| *** sebastianstadil has joined #openstack-meeting | 19:33 | |
| mtaylor | I'm less interested in crowbar unless it's only one of the solutions | 19:34 |
| termie | dprince: and many of us are a bit tired of waiting on them | 19:34 |
| mtaylor | because just testing dell is mega uninteresting to me | 19:34 |
| dprince | termie: I'm asking for the bits as we speak... | 19:34 |
| dprince | (via emails, etc). | 19:34 |
| termie | the chef scripts would theoretically be the same | 19:34 |
| *** joshuamckenty_ has quit IRC | 19:34 | |
| dprince | Sure. | 19:34 |
| termie | so all we really need is a simple script to kick off chef clientside | 19:34 |
| *** dabo has left #openstack-meeting | 19:35 | |
| dprince | I'm working on a XenServer cookbook to help setup the dom0 and domu. | 19:35 |
| termie | cool | 19:35 |
| termie | our side doesn't know how to do that, we're still kvm-ville | 19:35 |
| termie | for the moment though i'd love to get what we already had nearly working finished | 19:36 |
| nati | cool | 19:36 |
| mtaylor | yup. and I can turn my attention to that now that we're considering functional done via smokestack | 19:36 |
| mtaylor | termie: did you have a reason for doing pxe stuff directly and not using cobbler or something similar? | 19:37 |
| termie | mtaylor: it was dead simple and didn't require learning much as we were already doing it for nasa | 19:37 |
| dprince | How many machines do you have access to? | 19:37 |
| termie | dprince: i think 20 | 19:37 |
| mtaylor | 10 | 19:37 |
| mtaylor | we have 10 machines | 19:37 |
| termie | you have 10 or we gave you 10? | 19:38 |
| dprince | Cool. Well we have 4 on titan. Not as many but they are big boys. 48 Gigs of memory, lots of disk. | 19:38 |
| mtaylor | someone gave me access to 10 | 19:38 |
| termie | mtaylor: was it us who gave you access? i am trying to ask whether you are uysing the ones we allotted or some other mystery set | 19:38 |
| mtaylor | termie: the ones from jesse - so probably | 19:38 |
| mtaylor | termie: "us" is very nebulous to me most of the time | 19:39 |
| *** joshuamckenty_ has joined #openstack-meeting | 19:39 | |
| termie | mtaylor: ex-anso is my usual us when i am acting as spokesperson | 19:39 |
| termie | we don't really have a good line of distinction | 19:39 |
| mtaylor | fair - I guess I should be more clear - that doesn't mean anything to me either ... but it's really not important right now | 19:40 |
| termie | but anso is the easiest | 19:40 |
| mtaylor | in any case- I have access to 10 machines in the equinix facility in the bay area- I believe these are from "you" | 19:40 |
| termie | okies | 19:40 |
| termie | so i will assume we can't give you any more | 19:41 |
| mtaylor | I'm also assuming that | 19:41 |
| mtaylor | the thing we talked about at ODS was eventually making a setup that had 5 machines allocated to swift, 4 to nova and 1 to glance which would also be the driver of the thing | 19:42 |
| mtaylor | that, obviously, will not be what we do in the short term - but that's the aim | 19:42 |
| dprince | Why so many to swift? | 19:42 |
| termie | i'd say 4 nova, 4 swift 1 glance and one orchestrator | 19:43 |
| dprince | I'd go for more nova myself. | 19:43 |
| termie | 4 swift just to test replication and have a separate proxy | 19:43 |
| dprince | Okay. I see. | 19:43 |
| mtaylor | there was a reason they said 5 instead of 4 - jaypipes do you remember what it was? | 19:43 |
| mtaylor | because I'd love to have the orchestrator be separate | 19:43 |
| termie | same here | 19:44 |
| termie | because the other machines hsould probably be in a different network config | 19:44 |
| mtaylor | ok. let's say for sake of argument that we do that until such a time as someone comes in and says "dear god! we have to have 5 for swift" | 19:44 |
| jaypipes | mtaylor: no, I can't remember why. | 19:45 |
| mtaylor | we also have, while we're on the subject, an offer of machines from the Novel/Microsoft Interoperability Lab to ensure that we have a deployment testing the hyperv stuff | 19:45 |
| mtaylor | should probably be easier to make use of that once we have the first set of these up and going | 19:46 |
| termie | so action items for monty? | 19:48 |
| mtaylor | so - actions coming out of this week on this topic are that I'm going to get a jenkins job that fires off termie's pxe boot work. we're waiting on proper multi-machine chef recipes, yeah? | 19:48 |
| termie | nope, we have those | 19:48 |
| termie | but they will probably have to be updated for baremtetal | 19:48 |
| termie | the stuff i gave you kicks off a chefserver in lxc | 19:48 |
| mtaylor | #action mtaylor jenkins job that fires off pxe | 19:48 |
| mtaylor | yup | 19:48 |
| mtaylor | saw that | 19:49 |
| termie | we have probably additional knowledge on some of that now | 19:49 |
| mtaylor | the key there then is getting the right chef stuff running on the machines once they are booted | 19:49 |
| mtaylor | great! | 19:49 |
| termie | so you can ask us questions | 19:49 |
| termie | yeah, but it sounds like dprince might know some of that | 19:49 |
| mtaylor | I'd love to - as chef makes me want to rip my arms off | 19:49 |
| termie | that was where i handed things to you | 19:49 |
| termie | so i don't know how to actually kick off a chef client | 19:49 |
| termie | it makes me want to rip my arms also | 19:50 |
| termie | although they claim it is getting better | 19:50 |
| mtaylor | dprince: I'll be coming at you for questions on that | 19:50 |
| dprince | mtaylor: Sure. Happy to help. | 19:50 |
| mtaylor | termie: I keep expecing something like a command line "chef nova-node" | 19:50 |
| termie | yeah me too | 19:50 |
| mtaylor | termie: but instead apparetnly I have to write json files :) | 19:50 |
| termie | but it is like, get this key from somewhere | 19:50 |
| mtaylor | ok. as long as it's not just me | 19:50 |
| termie | vagrant does it, too, if you want to read some ruby | 19:51 |
| mtaylor | for now, I'll make sure I get the first bits up and kicking, and then I'll bug dan on the next step | 19:51 |
| mtaylor | it does - and there's too much magic in the vagrant files to help me figure out what to do on the command line | 19:51 |
| mtaylor | darned "helpful" things | 19:51 |
| mtaylor | whatever - I'm sure I'll be a chef expert by the time this is all said and done | 19:52 |
| mtaylor | next agenda section probably shouldn't be its own section - but I just wanted to make sure to mention that at some point figuring out how we verify the chef and puppet stuff is probably a good idea - but I don't feel like solving that today | 19:53 |
| termie | i think we effectively punted that earlier | 19:53 |
| mtaylor | we're running short on time - anybody got anything else on bare metal for now? | 19:53 |
| termie | only thing i would asdd is due dilligence to see what loren has | 19:53 |
| mtaylor | loren? | 19:54 |
| termie | USC guy who has done a bunch of baremetal stuff | 19:54 |
| termie | actually probably not useful for now | 19:54 |
| termie | it is for provisioning baremetal from nova | 19:54 |
| termie | let's skip | 19:54 |
| mtaylor | ah. cool. | 19:54 |
| termie | i'll keep up with him | 19:54 |
| mtaylor | I'm going to combine a couple of topics real quick: | 19:55 |
| mtaylor | #topic Jenkins Plugins | 19:55 |
| *** openstack changes topic to "Jenkins Plugins" | 19:55 | |
| mtaylor | anybody want to do any Java hacking? | 19:55 |
| termie | we don't need any right now, right? | 19:55 |
| termie | you want to replace tarmac, i guess, but do we need to? | 19:55 |
| *** joshuamckenty_ has quit IRC | 19:55 | |
| mtaylor | well - we need some at some point - and I always want to ask if there's anyone lurking who wants to help | 19:55 |
| mtaylor | we're getting close to the point where we need to | 19:56 |
| termie | why do we need to? | 19:56 |
| mtaylor | as we add additional tests for things in Jenkins, as long as we're using tarmac or roundabout, we have to double implement those outside of jenkins if we want them as part of the gatekeeping | 19:56 |
| termie | what is being double implemented? | 19:56 |
| mtaylor | well, nothing right now - we're just not adding those things to the gatekeeper as of yet | 19:57 |
| mtaylor | but our friends at ntt wanted to add code coverage metric counts to the gatekeeping | 19:57 |
| mtaylor | and since we're already tracking that in jenkins - if dependent jobs worked for us, that would be a piece of cake | 19:57 |
| mtaylor | but the tarmac/roundabout is ignorant of jenkins | 19:58 |
| *** zns has joined #openstack-meeting | 19:59 | |
| termie | how is it ignorant of jenkins? | 19:59 |
| mtaylor | in any case - obviously not this week - but I wanted to check with folks. however, as is usually the case, there are not 100s of java devs clamoring to help out - so we'll get to it when we get to it | 19:59 |
| termie | it rungs the tests | 19:59 |
| termie | so, not that i want to | 19:59 |
| termie | but i can be a java devloper | 19:59 |
| mtaylor | it runs tests that are defined in a config file on the file system - the only interaction is that jenkins runs tarmac | 19:59 |
| termie | but i don't think we need it | 19:59 |
| *** dolphm has joined #openstack-meeting | 19:59 | |
| ttx | one minute left :) | 19:59 |
| mtaylor | tarmac can't pass/fail things based on the outcome of jenkins jobs | 19:59 |
| termie | really? i thought that was exactly what it did | 20:00 |
| mtaylor | nope | 20:00 |
| termie | that is what roundabout does | 20:00 |
| mtaylor | nope | 20:00 |
| mtaylor | or - is it really? | 20:00 |
| termie | ... yeah | 20:00 |
| termie | it runs the tests in jenkins and then if it fails it dumps info into th elof | 20:00 |
| termie | log | 20:00 |
| termie | s/log/issue | 20:00 |
| mtaylor | ok - I'll re-look at it - I thought it did the same thing that tarmac did | 20:01 |
| termie | pretty sure | 20:01 |
| termie | plz double check though | 20:01 |
| jbryce | time to wrap up? | 20:01 |
| mtaylor | I will | 20:01 |
| termie | yeah | 20:01 |
| mtaylor | #action mtaylor will look at roundabout jenkins triggering | 20:01 |
| mtaylor | ok guys - till next week | 20:01 |
| termie | okay wrap up | 20:01 |
| mtaylor | #endmeeting | 20:01 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 20:01 | |
| openstack | Meeting ended Tue Jun 14 20:01:29 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-19.02.html | 20:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-19.02.txt | 20:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-19.02.log.html | 20:01 |
| dendrobates | o/ | 20:01 |
| nati | o/ | 20:01 |
| jbryce | meetingpalooza continues....who's here for ppb? | 20:01 |
| jaypipes | o/ | 20:01 |
| eday | here | 20:02 |
| notmyname | i | 20:02 |
| termie | so, for the next meeting, i think i was supposed to talk about github movement? | 20:02 |
| termie | or is that a different meeting? | 20:02 |
| zns | me | 20:02 |
| jaypipes | termie: that's this one. | 20:02 |
| johnpur | o/ | 20:02 |
| jbryce | termie: honestly not sure we'll get to that, but you can hang around | 20:02 |
| *** jesse_ has joined #openstack-meeting | 20:02 | |
| *** med_out is now known as medberry | 20:02 | |
| termie | also, mtaylor: could you write shorter emails pls? kthx :D | 20:02 |
| mtaylor | termie: never! :) | 20:02 |
| termie | s/pls/plz/ | 20:02 |
| *** jesse_ is now known as anotherjesse1 | 20:03 | |
| jbryce | #startmeeting | 20:03 |
| openstack | Meeting started Tue Jun 14 20:03:14 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 20:03 |
| jbryce | http://wiki.openstack.org/Governance/PPB - agenda | 20:03 |
| termie | k, well i'll lurk, say my name (!!) if you get to githubbery | 20:03 |
| jbryce | termie: ok | 20:03 |
| jbryce | #topic previous action items | 20:03 |
| *** openstack changes topic to "previous action items" | 20:03 | |
| jbryce | looking back through the meeting logs, i think we're caught up on almost everything. one outstanding issue was a q&a system | 20:04 |
| jbryce | does anyone know where we stand on that? | 20:04 |
| ttx | o/ | 20:04 |
| devcamcar | o/ | 20:04 |
| johnpur | we have deferred it until the new tcm comes on board | 20:04 |
| notmyname | what's a tcm? | 20:05 |
| johnpur | since he/she will own it | 20:05 |
| jbryce | technical community manager | 20:05 |
| johnpur | technical community manager | 20:05 |
| johnpur | jinx! | 20:05 |
| jbryce | #info deferred implementation of q&a software, waiting for technical community manager | 20:05 |
| jbryce | sebastianstadil: you around sebastian? | 20:05 |
| sebastianstadil | jbryce: I am | 20:06 |
| * soren is here now, sorry, was distracted. | 20:06 | |
| jbryce | #topic Scalr incubation application | 20:06 |
| *** openstack changes topic to "Scalr incubation application" | 20:06 | |
| jbryce | http://wiki.openstack.org/Scalr - incubation application for scalr | 20:06 |
| sebastianstadil | *Rooting* | 20:06 |
| ttx | who starts ? :) | 20:07 |
| jbryce | did everyone get a chance to review the application? anyone have questions? | 20:07 |
| jbryce | i know one issue that's already been brought up is language choice | 20:07 |
| ttx | I have a few... | 20:07 |
| sebastianstadil | indeed | 20:07 |
| soren | I've not actually had a chance to read it. :( | 20:07 |
| * soren does so real quick. | 20:07 | |
| sebastianstadil | It's succint. | 20:07 |
| johnpur | i would like to know the state of the scalr dev community, contributors, activity outside of the core, etc. | 20:07 |
| johnpur | how it might mesh witht he current OS community | 20:08 |
| ttx | johnpur: yes, I find the source code repository to be a bit scary in that respect | 20:08 |
| mtaylor | google code -- | 20:08 |
| ttx | http://code.google.com/p/scalr/source/list shows no work since April 16, and code drops that show that the development is done behind closed doors and thrown over the wall in the open repo every once in a while | 20:08 |
| ttx | which clearly does not match our way of doing things | 20:09 |
| sebastianstadil | Agreed | 20:09 |
| sebastianstadil | Reason is that the Google code repo is super slow | 20:09 |
| ttx | sebastianstadil: does that mean you plan to change that in the incubation is accepted ? | 20:09 |
| ttx | if* | 20:10 |
| sebastianstadil | ttx: We plan on changing that regardless | 20:10 |
| notmyname | to what? | 20:10 |
| sebastianstadil | Github has our preference so far | 20:10 |
| johnpur | sebastianstadil: i assume that there is little to no outside community then? | 20:11 |
| sebastianstadil | About half a dozen community patches over the lifetime of the project | 20:11 |
| jaypipes | My question is really about whether Scalr should be *part* of OpenStack or simply *consume/use* OpenStack as a cloud compute infrastructure... I'm thinking it's more a user of OpenStack than part of OpenStack itself. | 20:11 |
| sebastianstadil | Minor fixes | 20:11 |
| dendrobates | sebastianstadil: what happens to the scalr name if scalr becomes part of openstack and you change your mind and want to leave? | 20:11 |
| ttx | jaypipes: +1 | 20:11 |
| ttx | as much as I find Scalr interesting as a project, I'm struggling to see how it fits with OpenStack, especially since it connects to multiple things | 20:12 |
| ttx | I mean, I see how it fits with OpenStack... but not as a core project withing OpenStack | 20:12 |
| ttx | and incubating projects are candidates for core in the end. | 20:12 |
| *** david has joined #openstack-meeting | 20:12 | |
| sebastianstadil | ttx: I believe that at the end of the day we want people to use this stuff. That's what Scalr helps with | 20:13 |
| johnpur | it gets to a point i brought up before, where are we drawing the line (IaaS, PaaS, etc.) Are there currently different rukes for "incubation" vs "core"? | 20:13 |
| johnpur | s/rules/rukes | 20:13 |
| sebastianstadil | ttx: We want people to be able to build complex applications, manage them, and gain all the agility that comes with the cloud | 20:14 |
| jaypipes | I very much likes the idea of Scalr as one choice for deployment of app stacks on top of OpenStack infrastructure. Just not sure it belongs as an "incubated" project... | 20:14 |
| soren | To be fair, Glance also interfaces with S3. | 20:14 |
| sebastianstadil | ttx: Right now it's still easier to use dedicated hardware and scale up then use the cloud | 20:15 |
| johnpur | it is clear that with the success of RightScale and projects like Scalr that folks that deploy on clouds benefit from these sorts of systems | 20:15 |
| soren | ...so there's certainly prior art to core projects being able to interact with stuff that isn't OpenStack. | 20:15 |
| sebastianstadil | johnpur: Precisely. | 20:15 |
| sebastianstadil | There's no way a Zynga would not use a RightScale / Scalr / other management suite | 20:16 |
| johnpur | jaypipes: can you elaborate? why not incubate? | 20:16 |
| jaypipes | soren: yes, but Nova uses Glance as its image store. I don't think you could say the same about Scalr, no? How would other OpenStack projects *use* Scalr? The answer is they wouldn't...Scalr would use other OpenStack projects, but not the other way around, right? | 20:16 |
| jaypipes | johnpur: ^^ | 20:16 |
| sebastianstadil | Just too hard to manage hundreds or thousands of servers and not go mad with the complexity | 20:16 |
| soren | jaypipes: That will always be the case in the beginning when you add stuff at the top of the dependency chain. | 20:16 |
| soren | jaypipes: ...and it's only true until the next thing comes along that builds on top of it. That's how stacks are built :) | 20:17 |
| sebastianstadil | jaypipes: In the beginning, it would indeed be one-way | 20:17 |
| sebastianstadil | jaypipes: but I think we should focus on users of OpenStack as well | 20:18 |
| jaypipes | soren: AFAICT, Scalr is kind of like a conglomeration of a whole bunch of things... load balancing, compute, config management, database replication management, application management... I'm finding it tough to see where Scalr's "niche" is. | 20:18 |
| sebastianstadil | jaypipes: auto-scaling | 20:18 |
| sebastianstadil | jaypipes: which requires a lot of different elements | 20:18 |
| jaypipes | sebastianstadil: right. But I don't see auto-scaling as a core OpenStack project. I see it as a consumer/manager of OpenStack core projects. | 20:18 |
| soren | jaypipes: I think the situation where new projects build upon existing one is ideal. | 20:19 |
| soren | s/one/ones/ | 20:19 |
| jbryce | i think soren's point is very good. these things expand and stacks build over time. i would expect there to be some sort of open source management/automation system that makes sense to have tied very closely to all openstack components. it does leave the question of when something like that should be brought in especially when the other core pieces (auth, networking, volume storage) are still forming | 20:19 |
| soren | In the sense that they consume their API's and provide more value that way. | 20:19 |
| johnpur | jbryce: hence incubation vs core | 20:20 |
| jaypipes | soren: then what is "core"? | 20:20 |
| dendrobates | jbryce: that is in fact the very idea of Donabe | 20:20 |
| sebastianstadil | Very much agree with soren | 20:20 |
| soren | jaypipes: Fantastic question. | 20:20 |
| soren | jaypipes: ..with many answers, clearly :) | 20:20 |
| jaypipes | sebastianstadil: I'm not disagreeing with you or soren :) just wondering where the "core" line is... | 20:20 |
| jaypipes | sebastianstadil: since incubated projects are intended to become core, that's the question we're trying to answer here ;) | 20:21 |
| sebastianstadil | jaypipes: Help us define it then! | 20:21 |
| jaypipes | sebastianstadil: OK, I'll give it a shot... | 20:21 |
| soren | jaypipes: I have some answers to what it doesn't mean :) | 20:21 |
| johnpur | jaypipes: core projects will have significant community interest and involvement | 20:21 |
| jaypipes | I think that core projects are the "building blocks" that other services and projects use to create an entire platform. | 20:21 |
| jaypipes | I can't see Scalr as a building block. I see it as a platform. | 20:22 |
| dendrobates | core projects require tight integration with the other core projects | 20:22 |
| johnpur | and be the "best" solution to a set of defined problems | 20:22 |
| jaypipes | sebastianstadil: that make sense? | 20:22 |
| ttx | sebastianstadil: I think it's a bit early for incubation... as in, the project needs to live as an open development project for a bit, potentially grow a community, for us to see where that community pushes it | 20:22 |
| johnpur | jaypipes: do you object to having a "PaaS" project in incubation? | 20:22 |
| soren | jaypipes: I think what we're seeing with Scalr is simply that they have a massive head start. | 20:22 |
| jaypipes | johnpur: yes. | 20:22 |
| johnpur | ttx: +1 | 20:22 |
| ttx | sebastianstadil: going straight from "company owning development behind closed doors" to "openstack core candidate" is a bit quick | 20:23 |
| *** joshuamckenty_ has joined #openstack-meeting | 20:23 | |
| soren | jaypipes: What would have happened with a more organic evolution is layers and layers and layers on top of the current core projects. | 20:23 |
| sebastianstadil | jaypipes: You should spend some time and use it, you'll see that the different components can and are often used to build higher level concepts that fit every particular application | 20:23 |
| ttx | Once you open it on github and as an openstack ecosystem project, you might realize people want to take it in other directions | 20:23 |
| soren | jaypipes: ...and eventually something like Scalr would turn up, combining it all into something really useful. | 20:23 |
| jaypipes | soren: sorry, I'm losing you. are you suggesting that that eventual solution would be a "core" project? | 20:24 |
| soren | jaypipes: ...it just so happens that Scalr has existed for years and so have managed to get to that final point already. | 20:24 |
| soren | jaypipes: Yes. | 20:24 |
| johnpur | sebastianstadil: you mentioned that you will be altering your community engagement processes. Can you make these changes, model after OpenStack, get more community involvement... and then come back with an incubation request | 20:24 |
| *** zns has quit IRC | 20:24 | |
| jaypipes | sebastianstadil: again, it's not that I don't see the value. I definitely do. I'm saying I don't consider PaaS stuff core OpenStack projects. | 20:24 |
| johnpur | jaypipes: for now | 20:24 |
| *** zns has joined #openstack-meeting | 20:24 | |
| soren | jaypipes: I don't have a problem accepting a project into OpenStack as a core project on the grounds that it build on top of and is a heavy consumer of the existing core projects. | 20:24 |
| sebastianstadil | ttx: Isn't that what incubation is for? To determine if all the processes can be established to guarantee a successful Core project? | 20:25 |
| soren | "core" doesn't imply self-containedness to me. | 20:25 |
| jaypipes | johnpur: are you saying "for now" as in "jay will change his mind later"? | 20:25 |
| jaypipes | soren: ok, I hear you. but it does to me. :) | 20:25 |
| soren | It's more along the lines of "this is the component that solves problem X that we as a project stand behind". | 20:25 |
| ttx | sebastianstadil: incubation is more to get in line with openstack processes than to "become open" | 20:25 |
| johnpur | i am saying that OpenStack will likely evolve and mature, evidence is that Cloud systems go "up the stack" | 20:25 |
| soren | I tend to build my stacks upwards, not sideways :) | 20:25 |
| eday | sebastianstadil: I've not used scalr before, but is it mainly config files and daemons running tasks, or is it tightly integrated into a UI as well? | 20:26 |
| sebastianstadil | ttx: People do want to take it in other directions, a company recently wanted to make the IaaS-interface modules OCCI compatible | 20:26 |
| ttx | we need to judge if the project fits, but going more open will chnage your project significantly | 20:26 |
| jbryce | soren: ++ | 20:26 |
| ttx | so I fear that what we judge today might not be what it becomes | 20:26 |
| soren | jaypipes: I can see how the term "core" suggests a sort of self-containedness. | 20:27 |
| ttx | sebastianstadil: saw dendrobates question above ? I think it's a good one too | 20:27 |
| jaypipes | soren: think of it this way: you don't consider Ubuntu to be a "core" Linux project do you? | 20:27 |
| ttx | <dendrobates> sebastianstadil: what happens to the scalr name if scalr becomes part of openstack and you change your mind and want to leave? | 20:27 |
| soren | jaypipes: I don't, no. I don't see the analogy, though. | 20:27 |
| ttx | would we use the name "scalr" as the name of the project ? | 20:27 |
| sebastianstadil | eday: sign up at scalr.net to get a quick idea of the interface | 20:27 |
| joshuamckenty_ | dendrobates: Presumably the same thing as the nova or OpenStack names. | 20:28 |
| ttx | it's more than just a codename like the others, it's a brand, and a company name :) | 20:28 |
| jaypipes | soren: or, even more inline with this discussion, you don't consider Ubuntu Enterprise Cloud to be a core linux project. I view Scalr in much the same way: a platform that uses core projects to deliver extended value | 20:28 |
| jbryce | ttx: i would guess we'd probably come up with an openstack generic name | 20:28 |
| johnpur | ttx: probably not, as Scalr will want to retain rights | 20:28 |
| joshuamckenty_ | sebastianstadil: I think eday was asking about tight coupling with the ui | 20:28 |
| soren | jaypipes: I don't think "core linux" makes any sense. | 20:28 |
| dendrobates | joshuamckenty_: except that scalr is also a company and all the core devs could leave. | 20:28 |
| joshuamckenty_ | Openstack is also a company | 20:29 |
| joshuamckenty_ | And a brand | 20:29 |
| dendrobates | joshuamckenty_: I just want to make sure that sebastianstadil understands the implications | 20:29 |
| soren | jaypipes: I think of this more like Gecko being a core part of the Mozilla project, but so is Firefox. | 20:29 |
| eday | sebastianstadil: I'm asking because if it is heavily UI driven (which I assume it is), it seems like the ideal outcome would be to have the Scalr features added to OpenStack Dashboard (which is Python based) so we don't have competing UIs with an overlap of functionality | 20:29 |
| joshuamckenty_ | So the parallel standa | 20:29 |
| jbryce | jaypipes: nova is a collection of functionality provided by iptables, kvm/xen/etc, filesystems....every piece of software aggregates functionality from others at some level | 20:29 |
| sebastianstadil | ttx: OpenStack Manager / Scalr / UI, I don't have any preference on the name to use | 20:29 |
| soren | jaypipes: ...even though it builds heavily upon another core project of Mozilla. | 20:29 |
| joshuamckenty_ | eday: +1 | 20:29 |
| sebastianstadil | dendrobates: We can sign a document giving you use of the Scalr name if that's what you are concerned about | 20:30 |
| johnpur | eday: you are suggesting that scalr could be decomposed into sets of services that can be driven by the UI? | 20:30 |
| jaypipes | soren: sorry, I still don't agree that a PaaS management interface should be a core project in OpenStack... | 20:30 |
| soren | jaypipes: It's less of a technical term (which would suggest self-containedness), and more of a "socially and bureaucratically accepted part of OpenStack" sort of thing to me. | 20:30 |
| jaypipes | soren: that is "related" projects in my mind. | 20:30 |
| joshuamckenty_ | johnpur: I think the scalr guest agent could be considered separately | 20:31 |
| sebastianstadil | joshuamckenty_: UI used to be tightly coupled, now it's just passing json to a js app on the client side | 20:31 |
| soren | jaypipes: Anyone can say they're related. Only one project solving problem X can be core. | 20:31 |
| johnpur | hmmm, sebastian, what do you think of that? | 20:31 |
| soren | jaypipes: -ish. | 20:31 |
| ttx | eday: I agree we should avoid overlap in core projects, so we have an issue with Dashboard | 20:31 |
| eday | johnpur: I'm not sure, I don't know the Scalr architecture well enough to suggest anything. I'm just looking at it from an end-user. If we did have both scalr and openstack dashboard, it seems a bit confusing on the UI front. Or perhaps we want multiple official UIs (which I can't say I would want to support) | 20:32 |
| joshuamckenty_ | jaypipes: I think of elasticity mgmt as iaas, modulo UI | 20:32 |
| soren | Ah! Dashboard! | 20:32 |
| soren | jaypipes: Do you thing the dashboard should be core? | 20:32 |
| ttx | soren: next topic :) | 20:32 |
| jaypipes | soren: no. | 20:32 |
| jbryce | ha | 20:32 |
| soren | ttx: I know :) | 20:32 |
| soren | jaypipes: Ok. | 20:32 |
| soren | jaypipes: Well, at least you're consistent. :) | 20:32 |
| joshuamckenty_ | Flights taking off, you have my votes. | 20:32 |
| jaypipes | soren: for the next ten minutes, sure ;) | 20:32 |
| jbryce | joshuamckenty_: thanks. good flight | 20:32 |
| soren | jaypipes: :) | 20:33 |
| jbryce | ok...can we pause for a minute to summarize the questions | 20:33 |
| jbryce | i'll take a stab at it | 20:33 |
| jaypipes | sebastianstadil: does Scalr expose a REST API that completely controls Scalr's components? | 20:33 |
| jbryce | #info has scalr built an open development process and community? does it need one before becoming incubated | 20:33 |
| sebastianstadil | http://wiki/scalr.net/API | 20:33 |
| jbryce | #info is the scalr architecture built in a way that it will provide reusable and recomposable functionality that may be used by other projects | 20:34 |
| sebastianstadil | The problem we're tackling is that building applications on Cloud resources is hard | 20:34 |
| johnpur | i think the issue of proving that the code can be opened and attract a viable community effort is key to accepting a project into incubation. | 20:34 |
| sebastianstadil | That's why OpenStack should have a Core project that addresses it | 20:34 |
| jbryce | #info should something that is primarily focused as a consumer and aggregator of other projects be in core | 20:34 |
| jaypipes | sebastianstadil: OK, so not a REST API. Would you be open to developing a REST API instead of a SOAP-y API? | 20:35 |
| jbryce | #info does being partially in php conflict with the existing openstack community, present potential problems around dev/testing/support of a new project | 20:35 |
| notmyname | johnpur: isn't one of the purposes of incubation to help grow the community around a project? | 20:35 |
| ttx | johnpur: so it should do "open development" and "open community" before applying ? | 20:35 |
| sebastianstadil | jbryce: Thanks, I'm still lagging behind on some questions | 20:35 |
| *** dabo has joined #openstack-meeting | 20:35 | |
| sebastianstadil | Doesn't the biological term incubation apply some sort of growth? | 20:36 |
| sebastianstadil | *imply | 20:36 |
| sebastianstadil | It's not really a test | 20:36 |
| johnpur | my rationale is that "incubated" projects will take up time and resources form the folks managing releases, packaging, CI, QA, etc. | 20:36 |
| jbryce | #info what issues does the scalr brand present if the company withdraws from involvement in openstack (on this i think we would probably have some other openstack name for the project) | 20:37 |
| *** joshuamckenty_ has quit IRC | 20:37 | |
| sebastianstadil | Regarding the dashboard, that's how Scalr started out: as an open source, web-based ElasticFox | 20:37 |
| jbryce | those seem to be the main ones that i've picked out...did i miss any? | 20:37 |
| *** User627 has joined #openstack-meeting | 20:38 | |
| sebastianstadil | But as people started using it, we found that a dashboard is in no way sufficient to manage an application. You need to be able to identify resources, commands to groups of them, orchestrate changes, etc. | 20:38 |
| *** Tushar has joined #openstack-meeting | 20:38 | |
| jaypipes | sebastianstadil: looking at the API, there seems to be a lot of overlap between Scalr's API and the OpenStack Compute API 1.1 (but looking more like EC2's API than Rackspace API) | 20:39 |
| sebastianstadil | jbryce: Scalr is python for the guest agent, php for the controller, and js for the gui | 20:39 |
| *** sandywalsh has joined #openstack-meeting | 20:39 | |
| ttx | sebastianstadil: I also have a question, why would *you* want ScalR to be an OpenStack core project someday ? | 20:40 |
| sebastianstadil | jaypipes: Correct, at the last summit I had a few discussions on how to address that | 20:40 |
| sebastianstadil | ttx: OpenStack is awesome, want to be part of it. | 20:40 |
| ttx | sebastianstadil: good :) | 20:40 |
| jbryce | = ) | 20:40 |
| johnpur | nice answer | 20:40 |
| jaypipes | sebastianstadil: nice bribe :) | 20:40 |
| jbryce | 20 minutes before team meeting | 20:40 |
| sebastianstadil | ttx: No technical reason, just a cool bunch that I like hanging out with | 20:40 |
| ttx | sebastianstadil: because that implies a lot of constraints on what was your company and your code | 20:41 |
| jaypipes | sebastianstadil: even better :) | 20:41 |
| sebastianstadil | the company is in service of the code | 20:41 |
| ttx | sebastianstadil: so it's not just a badge of honor or a club :) | 20:41 |
| sebastianstadil | had we been venture funded, the company would have been in service of the shareholders | 20:41 |
| sebastianstadil | ttx: I know :-) | 20:41 |
| ttx | (it's the first "established" project we consider for openstack incubation, hence the strange questions) | 20:42 |
| jbryce | do people want more discussion or should we call a vote and see where we stand? | 20:42 |
| johnpur | vote | 20:42 |
| sebastianstadil | ttx: Yeah, and we had to write a lot of code that solved problems from yesterday | 20:42 |
| sebastianstadil | ttx: Like how to manage failover on a db that doesn't use network block storage | 20:43 |
| soren | The answer to that being: "carefully" | 20:43 |
| sebastianstadil | soren: haha! | 20:43 |
| jaypipes | jbryce: to be sure, we are voting whether to accept Scalr into incubation -- which means that we will owe sebastianstadil a detailed map of what things need to change (code, community, process, etc) in order to be considered for core? | 20:43 |
| jbryce | time for the vote. should scalr be added as an incubated openstack project? | 20:43 |
| jbryce | jaypipes: correct. | 20:44 |
| johnpur | my vote is +1. i think this is the sort of existing project that can add a lot of value to the oepnstack ecosystem. going forward we should look at how the scalr functionality is merged into the openstack user experience. | 20:44 |
| soren | I'd actally like to talk aobut technical stuff. | 20:44 |
| soren | ..before voting. | 20:44 |
| *** markwash has quit IRC | 20:44 | |
| soren | Mostly the PHP thing. | 20:44 |
| ttx | soren: like, could we rewrite it in Python ? | 20:44 |
| soren | ttx: I'd have phrased it differently, but yes :) | 20:45 |
| jbryce | jaypipes: no guarantee of core, and i wouldn't be surprised if others in the community would like to see more merging between dashboard ui components and scalr automation components as well as the general aversion to php that we've already seen | 20:45 |
| ttx | jbryce: aversion comes from the packaging burden that PHP carries. Is ScalR shipped in any distribution ? | 20:46 |
| soren | ttx: I'm 97% done packaging it for Ubuntu. | 20:46 |
| soren | Sorry, 87%. | 20:46 |
| *** dprince has quit IRC | 20:46 | |
| johnpur | ttx: how "bad" is it? java scale? | 20:46 |
| soren | Just saying. | 20:46 |
| ttx | johnpur: of course not | 20:46 |
| soren | Nowhere near Java scale. | 20:46 |
| johnpur | lol | 20:46 |
| johnpur | just saying | 20:46 |
| sandywalsh | does scalr conflict with the direction dashboard wants to go? | 20:47 |
| soren | It's unpleasant, but certainly doable. | 20:47 |
| sebastianstadil | actual laughter was produced | 20:47 |
| ttx | johnpur: though security-wise, PHP is a bit of a nightmare, I'm giving Sebastian the benefit of doubt over his PHP code :) | 20:47 |
| ttx | jbryce: unfortunately it's difficult to vote without considering Dashboard in parallel | 20:48 |
| ttx | jbryce: If they overlap, we'll have to choose between the two ? | 20:48 |
| sebastianstadil | ttx: I think a successful Dashboard project will turn into a Scalr in 2-3 years | 20:48 |
| jbryce | ttx: choose or find ways to combine | 20:48 |
| soren | I don't enjoy php, but my primary concern at this point is really the divergence. | 20:49 |
| sebastianstadil | I've seen it with Scalarium, RightScale, and a few other projects | 20:49 |
| ttx | jbryce: so it seems unfair to vote on ScalR without giving Dashboard a chance ;) | 20:49 |
| soren | I think sharing something as core as programming language between all core projects is really, really useful. | 20:49 |
| johnpur | we should look at the opportunity to enhance the user experience by merging the two efforts where it makes sense | 20:49 |
| jbryce | ttx: so defer vote for discussion of dashboard? | 20:49 |
| sebastianstadil | Anyone used thrift here? | 20:50 |
| soren | Not directly, no. | 20:50 |
| ttx | sebastianstadil: aaaaaah | 20:50 |
| jbryce | sebastianstadil: unfortunately yes | 20:50 |
| soren | I talked to a Cassandra instance once, so sort of. :) | 20:50 |
| notmyname | soren: "In order to ensure that there is ubiquitous distribution of the core OpenStack projects the development languages/environments and libraries must be widely and freely available. (Specific languages/runtimes that are ubiquitously available can be proposed and will be considered by the PPB)." | 20:50 |
| sebastianstadil | jbryce: Doesn't work as intended? | 20:50 |
| jbryce | sebastianstadil: to be fair, this was 12+ months ago...but scars can last a long time | 20:51 |
| sebastianstadil | This doesn't go for the short term, but longer term the proportion of python to php will increase | 20:51 |
| devcamcar | sebastiansadil: are you more concerned about scalr's ui being a standard, or the interface to the orchestration layer being standard? | 20:51 |
| sebastianstadil | devcamcar: Not sure I understand | 20:51 |
| ttx | jbryce: maybe let devcamcar and sebastianstadil talk for a week and see if they can come up with something awesome ? | 20:51 |
| sandywalsh | Would there be sufficient community adoption if it's in a different language compared to what we would get by sharing code directly? | 20:52 |
| sebastianstadil | I'm more concerned about making an awesome product for people to build awesome applications | 20:52 |
| soren | I'm not a big fan of the actual look of the scalr UI (I've seen much, much worse though!), but the fact that it's all Javascript and just interacts with Scalr over HTTP+JSON is pretty nifty in my view. | 20:52 |
| johnpur | ttx: i like that | 20:52 |
| ttx | jbryce: like a django UI with autoscaling featurse. | 20:52 |
| jbryce | ttx: yep | 20:52 |
| ttx | otherwise I have to think about which one I should give my +1 too, and that involves hearing Dashboard side of the story. | 20:53 |
| sebastianstadil | ttx: It's actually more like Gmail | 20:53 |
| devcamcar | seabastiansadil: what about using just the python pieces? | 20:53 |
| sebastianstadil | devcamcar: Wouldn't help the end-users | 20:53 |
| jbryce | ttxdevcamcar, sebastianstadil: are you two opposed to talking about something like that? dashboard ui driving scalr automation? this is similar to what josh mckenty mentioned as well | 20:53 |
| devcamcar | i'm open to it but sebastian hasn't ever expressed interest in that when we've discussed it | 20:54 |
| devcamcar | anyway you guys just spent an hour talking about scalr so there's not much for me to say today | 20:54 |
| sebastianstadil | I think a fully js engine >> mvc | 20:54 |
| *** markwash has joined #openstack-meeting | 20:55 | |
| notmyname | wouldn't that imply that one of them will be incubated? isn't it possible that neither get accepted? | 20:55 |
| jbryce | devcamcar: sorry about that! | 20:55 |
| soren | i think this has been a very useful discussion, though. I'd hate to have cut it short. | 20:55 |
| jbryce | i agree | 20:56 |
| *** nati has quit IRC | 20:56 | |
| jbryce | sebastianstadil, devcamcar: you two are kind of are guinea pigs as this is are first pass at this | 20:56 |
| johnpur | jbryce: next steps? | 20:56 |
| sebastianstadil | Some brave enough to summarize the discussion? | 20:56 |
| jbryce | sure | 20:56 |
| ttx | notmyname: I would like to see one of them. Your opinion may differ. Jay's opinion differs. | 20:56 |
| jbryce | not everyone feels ready to have a firm vote on scalr without giving dashboard a full hearing | 20:57 |
| notmyname | ttx: ha! if you and I didn't differ, one of us is wrong ;-) | 20:57 |
| *** nati has joined #openstack-meeting | 20:57 | |
| ttx | notmyname: my.. head... hurts... | 20:58 |
| jbryce | i think there are some concerns about overlap between the two and incubating 2 of the same thing, splitting efforts, language differences and a desire to see if there is a chance for collaboration that would result in an automation/scaling project with a ui where more of the code is in python | 20:58 |
| jaypipes | jbryce: nice summary. | 20:59 |
| johnpur | i really like the idea of extending the dashboard functionality with scalr automation, can we have an action to have these discussions? | 20:59 |
| jbryce | next steps are to break for the day because we're out of time, see if devcamcar and sebastianstadil want to talk about combined efforts or not, and in any case come back again next week to discuss dashboard if devcamcar is available again | 20:59 |
| sandywalsh | is the scalr architecture intended to only operate at the public API level, or will it attempt to access the AMQP layer for faster decision making? | 20:59 |
| devcamcar | i'm available | 20:59 |
| *** ohnoimdead has joined #openstack-meeting | 21:00 | |
| soren | sandywalsh: If there's any sort of motivation to speak AMQP to anything, we're doing something wrong :) | 21:00 |
| *** mldennis has joined #openstack-meeting | 21:01 | |
| ttx | jbryce: #endmeeting ? | 21:01 |
| jbryce | devcamcar: sorry again for making you sit this one out. we will definitely give you your day in the hot seat | 21:01 |
| jbryce | thanks guys | 21:01 |
| jbryce | #endmeeting | 21:01 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 21:01 | |
| openstack | Meeting ended Tue Jun 14 21:01:12 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.html | 21:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.txt | 21:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.log.html | 21:01 |
| *** somik has joined #openstack-meeting | 21:01 | |
| jbryce | these back to back meetings are a little crazy | 21:01 |
| sandywalsh | soren, I agree, but just making sure. | 21:01 |
| ttx | nothing like back-to-back meetings. Who is here for the regular OpenStack meeting ? | 21:01 |
| sebastianstadil | devcamcar: Want to chat again? | 21:01 |
| heckj | o/ | 21:01 |
| glenc | \o | 21:02 |
| heckj | totally missed the CI meeting two hours ago... :-( | 21:02 |
| ttx | vishy: ? | 21:02 |
| eday | sandywalsh: I would say AMQP only if we decided AMQP is a fully supported public API (like the REST API is) | 21:02 |
| vishy | o/ | 21:02 |
| ttx | ok, let's get started | 21:02 |
| *** ameade has joined #openstack-meeting | 21:02 | |
| ttx | #startmeeting | 21:02 |
| openstack | Meeting started Tue Jun 14 21:02:27 2011 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:02 |
| vishy | can we do nova first today? | 21:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 21:02 |
| ttx | vishy: if you convince notmyname, yes. | 21:02 |
| ttx | Agenda for today: | 21:02 |
| ttx | #link http://wiki.openstack.org/Meetings/TeamMeeting | 21:02 |
| * notmyname defers to vishy | 21:02 | |
| ttx | #topic Actions from previous meeting | 21:03 |
| *** openstack changes topic to "Actions from previous meeting" | 21:03 | |
| ttx | * ttx to push update of Swift release PPA to 1.4.0 and creation of a common OpenStack release PPA | 21:03 |
| devcamcar | sebastiansadil: sure | 21:03 |
| vishy | notmyname: thx. I'm hoping to get some more sleep :) | 21:03 |
| sandywalsh | eday, makes sense | 21:03 |
| ttx | That's done. PPAs for common OpenStack releases are now under https://launchpad.net/~openstack-release | 21:03 |
| *** bcwaldon has joined #openstack-meeting | 21:03 | |
| ttx | You can see a map of the available PPAs at: http://wiki.openstack.org/PPAs | 21:03 |
| ttx | * ttx to consider untargeting/retrotarget Low specs to decrease noise | 21:03 |
| *** bcwaldon has left #openstack-meeting | 21:03 | |
| ttx | Not done, been busy sanitizing diablo-2 plans last week, postponing | 21:03 |
| ttx | #action ttx to consider untargeting/retrotarget Low specs to decrease noise | 21:04 |
| *** dolphm has quit IRC | 21:04 | |
| ttx | #topic Nova status | 21:04 |
| *** openstack changes topic to "Nova status" | 21:04 | |
| ttx | vishy: I worked last week to make sure diablo-2 specs were assigned to someone or postponed | 21:04 |
| ttx | #link https://launchpad.net/nova/+milestone/diablo-2 | 21:04 |
| ttx | I still have a few targeted specs without confirmation: | 21:04 |
| *** bcwaldon has joined #openstack-meeting | 21:04 | |
| ttx | * https://blueprints.launchpad.net/nova/+spec/integrate-nova-authn (anotherjesse ?) | 21:04 |
| ttx | * https://blueprints.launchpad.net/nova/+spec/extra-data (justinsb ?) | 21:05 |
| ttx | You just told me about the two you have | 21:05 |
| ttx | I suspect we should defer extra-data, couldn't get hold of Justin | 21:05 |
| vishy | yes, sounds good | 21:06 |
| ttx | #action ttx to defer extra-data to diablo-3 | 21:06 |
| ttx | #action vishy to get integrate-nova-authn status from anotherjesse | 21:06 |
| ttx | I also have two related ones without assignee: | 21:06 |
| ttx | * https://blueprints.launchpad.net/nova/+spec/configuration-drive | 21:06 |
| *** bcwaldon has quit IRC | 21:06 | |
| ttx | * https://blueprints.launchpad.net/nova/+spec/instance-transport | 21:06 |
| *** anotherjesse1 has quit IRC | 21:06 | |
| ttx | Anyone interested in them ? | 21:07 |
| ttx | Should we defer them to diablo-3 already ? | 21:07 |
| *** bcwaldon has joined #openstack-meeting | 21:07 | |
| *** jesse_ has joined #openstack-meeting | 21:07 | |
| vishy | 0x44 was working on prototyping configuration-drive | 21:08 |
| vishy | don't know what happened to it though... | 21:08 |
| vishy | probably makes sense to defer if we have no one actively working on them | 21:08 |
| *** Vek has joined #openstack-meeting | 21:08 | |
| ttx | vishy: yes | 21:08 |
| ttx | I'll send out an email asking for candidates, worked well last time | 21:08 |
| vishy | ok | 21:09 |
| ttx | #action ttx to defer configuration-drive and instance-transport | 21:09 |
| ttx | People still need to come back to me on openstack-api-floating-ips (reldan) and the testing-* ones (mtaylor) | 21:09 |
| ttx | The rest if pretty firm. | 21:09 |
| ttx | Quick status update on the essential stuff: | 21:09 |
| ttx | * https://blueprints.launchpad.net/nova/+spec/no-db-messaging (vishy) | 21:09 |
| _0x44 | vishy: I have code up on github for it, I showed anotherjesse yesterday. | 21:10 |
| vishy | oh there ya go, perhaps we should assign the config drive blueprint to _0x44 then | 21:10 |
| ttx | _0x44: would that work for you ? | 21:10 |
| _0x44 | Yes | 21:10 |
| vishy | no-db-messaging is a little bogged down. I'm going to take one more pass at the volume code and then start an ml thread about it | 21:11 |
| ttx | #action ttx to assign _0x44 to configuration-drive | 21:11 |
| ttx | * https://blueprints.launchpad.net/nova/+spec/nova-multi-nic (tr3buchet) | 21:11 |
| vishy | the main issue is solving that "problem "is creating some other ones | 21:12 |
| ttx | tr3buchet: any news ? | 21:12 |
| ttx | * https://blueprints.launchpad.net/nova/+spec/distributed-scheduler (sandywalsh) | 21:12 |
| ttx | sandywalsh: looks on track ? | 21:12 |
| tr3buchet | yes | 21:12 |
| tr3buchet | sorry, looked away | 21:13 |
| tr3buchet | i'm getting the tests running now | 21:13 |
| tr3buchet | physical test after then merge | 21:13 |
| sandywalsh | ttx, merging as we speak | 21:13 |
| ttx | tr3buchet, sandywalsh: cool, so still on track for diablo-2 delivery. | 21:13 |
| tr3buchet | ttx: yes | 21:13 |
| ttx | * https://blueprints.launchpad.net/nova/+spec/nova-instance-referencing (dabo) | 21:13 |
| sandywalsh | ttx yes | 21:13 |
| ttx | dabo: looking good ? | 21:13 |
| dabo | code is working, but broke lots of unit tests | 21:14 |
| sandywalsh | ttx, merge succeeded | 21:14 |
| dabo | we're fixing them now; should be on-track | 21:14 |
| ttx | dabo: thanks ! | 21:14 |
| ttx | vishy: anything else you wanted to mention ? | 21:14 |
| vishy | dabo: are you doing volumes too? | 21:14 |
| vishy | or just instances? | 21:14 |
| dabo | this pass is just instances | 21:14 |
| vishy | ok cool | 21:14 |
| dabo | volumes will need to be done, too | 21:14 |
| vishy | and are you doing ec2 mapping layer? | 21:15 |
| dabo | same as with scheduler - only instances work for now | 21:15 |
| ttx | dabo: needs to be done as in "sometime in diablo" ? Or "someday" ? | 21:15 |
| dabo | vishy: no, we're re-defining the ec2_id to be 'i-' + first 8 chars of UUID | 21:15 |
| dabo | ttx: as in 'next' | 21:15 |
| ttx | dabo: as part of the same blueprint, or another one ? Want to make sure we track that | 21:16 |
| vishy | dabo: hmm ok. That seems reasonable for the first pass I suppose | 21:16 |
| dabo | vishy: mapping layer would require shared db across zones | 21:16 |
| vishy | dabo: it is going to be annoying for existing deployments... | 21:16 |
| dabo | ttx: a new bp, since the original was instance-specific | 21:16 |
| ttx | dabo: ok, feel free to file and ping me to include | 21:16 |
| ttx | (or vishy) | 21:17 |
| dabo | vishy: yeah, I was thinking of how to convert when the uuid column is generated in the instances table | 21:17 |
| vishy | dabo: we can discuss offline | 21:17 |
| ttx | Other Nova questions ? | 21:17 |
| dabo | sure | 21:18 |
| vishy | (later...) | 21:18 |
| ttx | ok then, next topic | 21:18 |
| ttx | #topic Swift status | 21:18 |
| *** openstack changes topic to "Swift status" | 21:18 | |
| ttx | notmyname: could you announce your plans for 1.4.1 and 1.4.2 ? | 21:18 |
| notmyname | all kinds of stuff | 21:18 |
| notmyname | ok | 21:18 |
| notmyname | 1.4.1 is coming sooner than we all expected. It is scheduled for next week | 21:19 |
| notmyname | 1.4.2 won't be until mid-july at the earliest | 21:19 |
| jaypipes | notmyname: what is in 1.4.1? | 21:19 |
| notmyname | changelog for 1.4.1 is http://bazaar.launchpad.net/~hudson-openstack/swift/trunk/view/head:/CHANGELOG | 21:19 |
| ttx | So we should have a QA branch ready tomorrow, where potential release-critical bugfixes will be applied | 21:19 |
| notmyname | big things are swuath removed and renamed st | 21:20 |
| ttx | Release scheduled for Monday. | 21:20 |
| ttx | notmyname: Other announcements or comments ? | 21:20 |
| soren | What will be in 1.4.2? | 21:20 |
| notmyname | 1.4.2 should have container sync | 21:21 |
| *** glange has joined #openstack-meeting | 21:21 | |
| notmyname | change post to copy | 21:21 |
| *** glenc has quit IRC | 21:21 | |
| notmyname | and removing stats/logging | 21:21 |
| soren | Where is that going? | 21:22 |
| soren | (stats/logging, that is) | 21:22 |
| notmyname | into a separate project (like swauth did) | 21:22 |
| *** glenc has joined #openstack-meeting | 21:22 | |
| soren | Ok. | 21:22 |
| ttx | Other Swift questions / announcements ? | 21:22 |
| *** johnpur has quit IRC | 21:23 | |
| ttx | #topic Glance status | 21:23 |
| *** openstack changes topic to "Glance status" | 21:23 | |
| ttx | jaypipes: Hi! | 21:23 |
| jaypipes | https://launchpad.net/glance/+milestone/diablo-2 | 21:23 |
| ttx | Two weeks away from delivery | 21:23 |
| ttx | Looking at that URL I'd say you're a bit behind ? | 21:24 |
| jaypipes | ttx: we're doing OK. not great, but OK. Keystone integration is moving along a little slower than expected. bcwaldon is making great progress on wsgi refactoring. | 21:24 |
| jaypipes | ttx: yes. still on track for the 2 High BPs. Some of the Low priority ones may slip, but not too concerned. | 21:24 |
| ttx | right | 21:25 |
| ttx | jaypipes: Other announcements, comments ? | 21:25 |
| jaypipes | I *really* want to get the S3 bug out of the way... so I need some reviews from dprince, bcwaldon and others... | 21:25 |
| jaypipes | ttx: nothing more from me | 21:25 |
| ttx | jaypipes: link to review needed ? | 21:25 |
| jaypipes | ttx: https://code.launchpad.net/~jaypipes/glance/bug713154/+merge/59110 | 21:26 |
| ttx | thx! | 21:26 |
| *** dendrobates is now known as dendro-afk | 21:26 | |
| ttx | #action glance-core to review in priority https://code.launchpad.net/~jaypipes/glance/bug713154/+merge/59110 | 21:26 |
| ttx | if there is nothing else on Glance, let's go to our favorite topic | 21:27 |
| ttx | #topic Naming of E | 21:27 |
| *** openstack changes topic to "Naming of E" | 21:27 | |
| ttx | I came up with a list of candidates at: http://wiki.openstack.org/ReleaseNaming | 21:27 |
| ttx | Personally I like "Exeter" :) | 21:27 |
| creiht | how about Effing? | 21:28 |
| ttx | If you have other candidate names (that follow the rules described on the page), please edit the wiki | 21:28 |
| jaypipes | creiht: lol. ++ | 21:28 |
| ttx | creiht: does that even exist ? | 21:28 |
| *** mldennis has left #openstack-meeting | 21:28 | |
| heckj | heh | 21:28 |
| ameade | Egleston square is in the center of Boston | 21:28 |
| ttx | creiht: if you can make that a city or county near Boston, I'll take it | 21:28 |
| creiht | there is an Effingham, Illinois | 21:28 |
| markwash | creiht: that's an effing good ham | 21:29 |
| *** bcwaldon has quit IRC | 21:29 | |
| ttx | Do that soon because I'll throw a Launchpad poll (probably tomorrow) to pick the final name | 21:29 |
| *** ohnoimdead has quit IRC | 21:29 | |
| ttx | The Launchpad ~openstack group will be able to vote and it will last a week | 21:30 |
| *** ameade has quit IRC | 21:30 | |
| ttx | Comments ? | 21:31 |
| * ttx wonders if the Internet dropped. This discussion usually triggers comment frenzy. | 21:32 | |
| *** salv-orlando has joined #openstack-meeting | 21:32 | |
| * Vek shrugs | 21:32 | |
| ttx | then... | 21:32 |
| heckj | still here - just nothin' useful to add | 21:32 |
| ttx | #topic Open discussion | 21:32 |
| *** openstack changes topic to "Open discussion" | 21:32 | |
| * Vek will simply throw a dart at the list for the vote | 21:33 | |
| ttx | heckj: it doesn't have to be useful. | 21:33 |
| heckj | ttx: trying to be a little useful. | 21:33 |
| heckj | I rather like Exeter, but the poll will take care of it one way or another.. | 21:33 |
| ttx | Wow. Having vishy in Japan sounds like a good way to finish meetings early. | 21:34 |
| heckj | general question - is the packaging under the CI work? | 21:34 |
| heckj | (i.e. making deb's, rpm's etc) | 21:34 |
| ttx | heckj: it's completely integrated in Jenkins, if that's what you're asking | 21:34 |
| heckj | Its a tad inconsistent between the various official and side projects today. | 21:34 |
| ttx | (the deb's thing) | 21:35 |
| *** jesse_ has quit IRC | 21:35 | |
| heckj | monty has is set up to build RPM's as well? I knew deb's and PPA's | 21:35 |
| mtaylor | no. but he wants to | 21:35 |
| mtaylor | that's on my todo | 21:35 |
| mtaylor | list | 21:35 |
| heckj | mtaylor - sweet. | 21:35 |
| ttx | mtaylor: hooking OpenSuse build service ? | 21:35 |
| mtaylor | ttx: implementation as yet undecided | 21:35 |
| ttx | mtaylor: that's a long todo list. | 21:35 |
| mtaylor | I'm not a fan of the interface method for the OpenSuse build service - but it's not off the table | 21:36 |
| * heckj is installing most of the pieces from source control | 21:36 | |
| heckj | but I'm going to switch to using Chef shortly and the official PPAs we're creating through Jenkins | 21:36 |
| mtaylor | great! | 21:37 |
| ttx | anything else before we close this meeting ? | 21:37 |
| heckj | nope | 21:38 |
| mtaylor | heckj: so - this may be off topic - but the current set of howto's involving installing from chef without using something else to drive the chef install are ... lacking | 21:38 |
| ttx | #endmeeting | 21:38 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 21:38 | |
| openstack | Meeting ended Tue Jun 14 21:38:27 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:38 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-21.02.html | 21:38 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-21.02.txt | 21:38 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-21.02.log.html | 21:38 |
| ttx | thanks everyone | 21:38 |
| mtaylor | heckj: and I need to learn more about it anyway - so I'd love to be as much in the loop on that process as possible :) | 21:38 |
| *** glange has left #openstack-meeting | 21:39 | |
| heckj | mtaylor: happy to spam you with details, or otherwise shove them into a public wiki | 21:39 |
| mtaylor | heckj: either would be stellar | 21:39 |
| mtaylor | heckj: (I'm also doing something similar right now - just so far it's making me want to kill babies) | 21:40 |
| *** Vek has left #openstack-meeting | 21:40 | |
| heckj | mtaylor: i definitely know what you mean - tends to make one a bit "stabby" sometimes | 21:40 |
| *** nati has quit IRC | 21:40 | |
| *** masumotok has quit IRC | 21:41 | |
| *** creiht has left #openstack-meeting | 21:42 | |
| *** danwent has joined #openstack-meeting | 21:47 | |
| *** zns has quit IRC | 21:49 | |
| *** troytoman-away is now known as troytoman | 21:53 | |
| *** vladimir3p has quit IRC | 21:53 | |
| *** jlm^ has joined #openstack-meeting | 21:55 | |
| *** zns has joined #openstack-meeting | 21:55 | |
| *** ryu_ishimoto has joined #openstack-meeting | 21:57 | |
| danwent | hello netstack folks | 22:00 |
| salv-orlando | hello | 22:00 |
| danwent | tough crowd :) | 22:00 |
| danwent | FYI: dendrobates is out today | 22:01 |
| salv-orlando | it does not look like a busy meeting, does it? | 22:01 |
| salv-orlando | ok, so it me, Dan, and? | 22:01 |
| bhall | I'm here | 22:01 |
| somik | hey | 22:01 |
| danwent | ok...... | 22:02 |
| markvoelker | o/ | 22:02 |
| danwent | #startmeeting | 22:02 |
| openstack | Meeting started Tue Jun 14 22:02:08 2011 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. | 22:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 22:02 |
| ryu_ishimoto | i'm here | 22:02 |
| danwent | anyone we need to wait for? | 22:02 |
| danwent | (i.e., does anyone know of someone who is coming for sure but is not here yet?) | 22:02 |
| *** midodan has joined #openstack-meeting | 22:02 | |
| bmcconne | troy will likely turn back to his monitor at some point :) | 22:03 |
| danwent | #topic project status | 22:03 |
| *** openstack changes topic to "project status" | 22:03 | |
| danwent | #info dendrobates is beginning the process of applying for netstack to be an openstack incubation project | 22:03 |
| *** SumitNaiksatam has joined #openstack-meeting | 22:03 | |
| *** ecarlin has joined #openstack-meeting | 22:04 | |
| SumitNaiksatam | Hello! | 22:04 |
| danwent | I believe most of you saw this email, but we also switched from https://blueprints.launchpad.net/network-service to https://launchpad.net/quantum for quantum specific code | 22:04 |
| ecarlin | hello | 22:04 |
| *** eperdomo has joined #openstack-meeting | 22:04 | |
| danwent | if you have branches or bugs that are quantum specific, please move them to quantum. | 22:04 |
| danwent | I also see melange code on the network-service page. Troy, what is the long term plan for where this repo will live? | 22:05 |
| danwent | (anyone at rackspace that is close enough to kick troy? :P) | 22:05 |
| bmcconne | just got his attention | 22:05 |
| *** Jamey has joined #openstack-meeting | 22:05 | |
| danwent | ok, we'll come back to that. | 22:06 |
| *** romain_lenglet has joined #openstack-meeting | 22:06 | |
| danwent | #topic quantum update | 22:06 |
| *** openstack changes topic to "quantum update" | 22:06 | |
| danwent | we're continuing to do testing and bug finding on quantum. | 22:07 |
| troytoman | just caught up. we are working on a plan to have melange live within the Nova project. it looks like we can make that work | 22:07 |
| danwent | troytoman: great, thanks. so eventually the branches in network-service will go away? (no rush) | 22:07 |
| troytoman | yes. there are some issues with where the code lives and how we tie together running tests etc. I expect that will be settled within the week. | 22:08 |
| troytoman | then it will move out of network service | 22:08 |
| danwent | k, great | 22:08 |
| danwent | on quantum: we're will have a plugin that works with KVM soon, though it may require a tweaked version of nova | 22:08 |
| danwent | we're turning our focus more to how quantum will work with nova + melange. | 22:08 |
| danwent | on the topic of nova, ryu, can you provide an update on the nova refactoring? | 22:09 |
| *** RamD has joined #openstack-meeting | 22:09 | |
| danwent | (or anyone from midokura?) | 22:09 |
| midodan | hi there | 22:10 |
| midodan | i'll try to kick Ryu awake | 22:10 |
| danwent | ah, i thought I saw him join just a bit ago | 22:10 |
| ryu_ishimoto | yup i'm here, sorry | 22:10 |
| jlm^ | He is on channel. | 22:10 |
| midodan | :) | 22:10 |
| danwent | ryu, can you give a quick update? | 22:10 |
| danwent | particularly with respect to the vif-plugging side of things. We've had a couple questions on that from folks at Cisco as well. | 22:11 |
| ryu_ishimoto | sure, that's also where we are struggling a bit with | 22:11 |
| ryu_ishimoto | VIsh is here this week in Japan and we have been discussing how we should implmeent that part | 22:11 |
| SumitNaiksatam | is this discussion being captured/documented somewhere? | 22:12 |
| danwent | Ok. would be great to see a BP, so we can provide feedback. | 22:12 |
| *** dragondm has quit IRC | 22:12 | |
| midodan | yes, i agree. there have been several conversations about this issue going on in separate forums. we will write a doc and get some feedback. | 22:13 |
| danwent | Great, thanks. There's a lot of interest particularly around the flexibility of generating <interface> config for libvirt... | 22:13 |
| SumitNaiksatam | much appreciated...as with everything else, sooner would be better :-) | 22:13 |
| *** JordanRi1ke is now known as JordanRinke | 22:13 | |
| danwent | Ok, anything else on quantum? | 22:13 |
| SumitNaiksatam | at least at a high level as to where the discussion is heading... | 22:13 |
| midodan | danwent: you mentioned that there would soon be a version running with KVM | 22:14 |
| *** mrmartin has quit IRC | 22:14 | |
| midodan | how will that work? with libvirt? do you have a doc describing it? | 22:14 |
| danwent | midodan: the quantum service will be the same regardless, I more meant that at least the OVS plugin will be able to work with KVM (this is really more of a libvirt thing) | 22:14 |
| midodan | right right, that's the part i was wondering about, the ovs plugin | 22:15 |
| danwent | This will require changes to nova in the vif-plugging area, which is what we were asking about. | 22:15 |
| midodan | ok, we should have a discussion offline, perhaps later today, to sync up | 22:15 |
| danwent | Code will be up. At a high-level, its just using type="ethernet" instead of type="bridge" and making a couple ovs commands for setup/teardown | 22:15 |
| danwent | Its just a hack now, to demonstrate the flexibility we would need from the nova refactoring of libvirt. | 22:16 |
| ryu_ishimoto | danwent: right, that's how we implemented in our branch | 22:16 |
| danwent | and to let people play with quantum with a single server KVM setup. | 22:16 |
| danwent | ryu: yes, exactly | 22:16 |
| midodan | ok, sounds good, thanks. | 22:16 |
| ryu_ishimoto | danwent: ok let's keep the discussion going offline then. | 22:16 |
| danwent | ryu: when you mention a branch, are you referring to the original branch discussed at the summit? | 22:17 |
| ryu_ishimoto | danwent: no, the new branch, the one that's less disruptive | 22:17 |
| ryu_ishimoto | danwent: lp:~/midokura/nova/network-refactoring | 22:17 |
| danwent | ryu: great, thanks. | 22:17 |
| danwent | ok, anything else on quantum? | 22:18 |
| ryu_ishimoto | but the old branch does the same thing in regards to libvirt interfaces | 22:18 |
| *** adjohn has joined #openstack-meeting | 22:18 | |
| RamD | kvm related is of our interest too. | 22:18 |
| salv-orlando | on quantum API: I have implemented the changes proposed in last week's email | 22:18 |
| danwent | RamD: yup. you may want to do a similar hack with libvirt + the type="direct" to demonstrate the flexibility that you need, as I'm not sure the existing refactoring changes are sufficient. | 22:19 |
| *** vladimir3p has joined #openstack-meeting | 22:19 | |
| danwent | salv: can you quickly describe them? | 22:19 |
| salv-orlando | 1) removing orchestration operation for PUT attachment | 22:19 |
| danwent | ah, yes. now I remember. thanks. | 22:19 |
| salv-orlando | 2) using detail action for retrieving list of resources attached to network | 22:19 |
| danwent | Ok, does anyone want to give an update on melange or donabe? | 22:20 |
| salv-orlando | changes are in a branch I'm using to fix a couple of bugs I spotted as well. Will propose for merge into trunk ASAP | 22:20 |
| danwent | salv: awesome, great. | 22:20 |
| salv-orlando | before moving to other projects, did we reach a consensus on the semantics of the attach operation? | 22:21 |
| salv-orlando | I remember it was discussed two weeks ago, but I don't know whether we decided something | 22:21 |
| danwent | I believe the semantics are basically of plugging a cable, or was there a more specific point that the discussion was focused on? | 22:21 |
| salv-orlando | Sumit (if I'm not wrong) was proposing to remove the operation as it was beyond the scope of the quantum service | 22:22 |
| *** edconzel has quit IRC | 22:22 | |
| salv-orlando | basically If I remember it correctly, it was responsibility of the compute node to "plug the cable" | 22:23 |
| SumitNaiksatam | Salv: not I wasn't | 22:23 |
| danwent | ah, i think the distinction here is a "logical plug" vs. the "hypervisor plug". | 22:23 |
| salv-orlando | rigth | 22:23 |
| danwent | I think we're clear on that now. | 22:23 |
| danwent | Sumit? | 22:23 |
| SumitNaiksatam | Yeah, I guess based on the discussion we had the other day | 22:24 |
| danwent | Yup, we'll need to focus on the vif-plugging work in nova for that. | 22:24 |
| salv-orlando | sweet, just wanted to make sure of that | 22:24 |
| SumitNaiksatam | agreed | 22:24 |
| danwent | salv: yes, thanks for bringing it up. | 22:24 |
| danwent | #topic: open discussion | 22:24 |
| *** openstack changes topic to ": open discussion" | 22:24 | |
| danwent | speak now or hold you peace until next week :) | 22:25 |
| danwent | #endmeeting | 22:25 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 22:25 | |
| troytoman | just for reference, the multinic branch should merge prop in the next day or so | 22:25 |
| openstack | Meeting ended Tue Jun 14 22:25:46 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:25 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-22.02.html | 22:25 |
| salv-orlando | I have a question for Melange people... | 22:25 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-22.02.txt | 22:25 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-22.02.log.html | 22:25 |
| danwent | damn.... | 22:25 |
| troytoman | i know several are waiting on that. | 22:25 |
| somik | bye all! | 22:25 |
| danwent | troy: great news, thanks. | 22:26 |
| danwent | salv: please ask your question. | 22:26 |
| midodan | hey danwent can we chat about the libvirt stuff briefly? | 22:26 |
| danwent | midodan: sure | 22:26 |
| troytoman | salv-orlando: I'm available for a melange questions | 22:26 |
| salv-orlando | In old nova days we used to inject network info in flat mode. Will this still be possible with melange | 22:26 |
| salv-orlando | ? | 22:26 |
| danwent | midodan: want to chat now or via email? | 22:27 |
| midodan | danwent: now is good, i just type slow | 22:27 |
| danwent | :) | 22:27 |
| troytoman | yes. we are still planning to enable injection so we plan to integrate it in that way | 22:27 |
| troytoman | salv-orlando: ^ | 22:27 |
| midodan | danwent: so i have a question about the OVS plugin, with respect to xen. why is it that the Xen DB is used at all? rather than just putting in the required id into the ovsdb? | 22:28 |
| salv-orlando | troytoman: are we planning to use agents as we do for xenapi today? | 22:28 |
| danwent | midodan: that is just a work-around so that we can use it without any nova changes. With nova changes, we will be putting the id in the OVSDB, as you suggest. | 22:28 |
| troytoman | yes. that is the rackspace use case. | 22:28 |
| troytoman | we are exploring some other options such as a metadata service or a pluggable usb drive. but, those would be out in the future | 22:29 |
| danwent | midodan: in fact, that is exactly what our libvirt code does, so basically I have to update the OVS plugin to strip out the XAPI stuff for working with KVM. | 22:29 |
| midodan | ok, ic | 22:29 |
| troytoman | our plan is that you will still be able to get the network info before creating an instance and put the necessary data in the xenstore to get an instance up | 22:30 |
| midodan | danwent: ok, ic. so the question is, what should be communicated from compute to network. our model has been that compute agent communicates with the network agent, locally on the box, and passes over the tap name and the vif id. | 22:30 |
| midodan | midodan: however, we were chatting with Vish a couple of days ago, and he mentioned another use case that wouldn't be served by that model. | 22:31 |
| midodan | oops, talking to myself :) | 22:31 |
| danwent | no, i'm here :) | 22:31 |
| danwent | ah, i get it :) | 22:31 |
| danwent | too many dans | 22:31 |
| salv-orlando | troytoman: will there be an "official melange agent" or will we allow openstack deployers to bring their own agents? | 22:31 |
| midodan | for real, i'm getting confused | 22:31 |
| midodan | danwent: so, in case of using interface type direct, maybe that model doesn't work | 22:31 |
| danwent | midodan: he may be talking about the cisco use case. | 22:31 |
| midodan | right | 22:32 |
| danwent | midodan: yes | 22:32 |
| midodan | danwent: what are your thoughts about that? | 22:32 |
| midodan | danwent: open ended question, i know | 22:32 |
| danwent | midodan: I tend to think of it as nova + libvirt having a couple different ways it can do vif-plugging | 22:32 |
| troytoman | we are thinking this will use the nova-agent that is already in place. it will just get some of the info from melange as opposed to reading it from the networks table, for instance. | 22:32 |
| danwent | midodan: "nova agent", you mean the "compute service" that invokes libvirt? | 22:33 |
| troytoman | nova will handle the communication with Melange - not the agent directly | 22:33 |
| midodan | danwent: right, that's what i'm talking about. | 22:33 |
| salv-orlando | troytoman: I see. Thanks for the update. I have a few more questions, but I'll probably send an email to avoid confusion on IRC :-) | 22:34 |
| danwent | midodan: yes, I think the compute service will need to have some kind of configurable options to indicate exactly how it should generate the libvirt interface xml. | 22:34 |
| troytoman | salv-orlando: the format of the xenstore messages would remain the same. please send along your questions. | 22:34 |
| danwent | and communicate the "interface binding" to quantum (or equivalent) | 22:34 |
| midodan | danwent: that's fine, not a problem. can we assume that there is a network agent running on the same host as the compute service? | 22:34 |
| danwent | midodan: I wouldn't want to always assume that. | 22:35 |
| danwent | midodan: for example, with OVS, the nova compute service should just be able to set a value in the OVSDB and be done with it. | 22:35 |
| danwent | midodan: sometimes this discussion is hard because we all have slightly different definitions :) | 22:35 |
| midodan | midodan: don't get me started. everytime we talk about "ports", it's confusing as hell. :) | 22:36 |
| danwent | midodan: :) | 22:36 |
| midodan | danwent: oops, again, talking to self | 22:36 |
| danwent | :) | 22:36 |
| midodan | danwent: need more coffee | 22:36 |
| midodan | danwent: ok, so, in the example you mentioned, | 22:36 |
| midodan | the Nova side and the Quantum side know that they're using OVS, and they agree about the particular bridge they're using. | 22:37 |
| midodan | correct? | 22:37 |
| danwent | midodan: yes, that's definitely one model | 22:37 |
| danwent | midodan: essentially, the quantum plugin and nova need to share a "contract" | 22:38 |
| midodan | danwent: so we have a use case where we use a bridge per tenant | 22:38 |
| midodan | right | 22:38 |
| danwent | midodan: they have to agree where they meet | 22:38 |
| midodan | danwent: that sounds reasonable. so how to agree on that. | 22:39 |
| SumitNaiksatam | dan/midodan: it seems some discussion/thought has gone into how to implement this refactoring (albeit with resepect to OVS), any way to share that? | 22:39 |
| danwent | midodan: yes, so because the linux bridge is somewhat broken, you need a slightly different contract. This would likely require the quantum plugin to have an agent on the host, since the linux device -> bridge mapping depends on logical connectivity | 22:39 |
| midodan | SumitNaiksatam: sure, we'll write something up on an etherpad or wiki. | 22:39 |
| danwent | Sumit: this is part of what I'm trying to write-up | 22:39 |
| SumitNaiksatam | ok great | 22:39 |
| SumitNaiksatam | that way we can provide suggestions | 22:40 |
| danwent | sumit: Rick and I have been talking about a "Quantum design" document. | 22:40 |
| danwent | yes | 22:40 |
| SumitNaiksatam | cool | 22:40 |
| danwent | midodan: I think the key thing is that there does not need to be a single contract that works for all Quantum plugins | 22:40 |
| danwent | midodan: in fact, with SR-IOV vs. bridge vs. OVS the plugging (just the the libvirt XML) will be a bit different. | 22:41 |
| midodan | danwent: but in that case, there might be code that needs plugging into Nova as well | 22:41 |
| danwent | midodan: can you clarify? | 22:41 |
| midodan | danwent: meaning that depending on the 'contract' the Nova (compute service) side might have to do things a bit differently as well. | 22:42 |
| midodan | danwent: for example, | 22:42 |
| danwent | definitely | 22:42 |
| midodan | in one case Nova might create the tap interface and add it to an agreed upon bridge, and then set some id, and that's it | 22:42 |
| danwent | but I think that is already true with respect to how the libvirt xml is crafted, right? | 22:42 |
| danwent | I see this as a "vif-plugging-type=" flag for libvirt deployments. | 22:42 |
| midodan | maybe, but it adds more coordination complexity | 22:43 |
| danwent | not the most elegant approach, but seems pretty straightforward. | 22:43 |
| midodan | ok, so can we enumerate the high level ways to do this | 22:43 |
| midodan | 1) tap into bridge, one bridge for all VMs | 22:43 |
| midodan | 2) tap into bridge, bridge per tenant | 22:43 |
| midodan | 3) SR-IOV virtual PCI device (who manages virtual device lifecycle, Nova or Quantum?) | 22:44 |
| danwent | quick question: are you just focusing on libvirt? | 22:44 |
| midodan | no no, general question | 22:44 |
| midodan | 4) 'direct' interface, a la 802.1Qbg | 22:45 |
| danwent | then i think this gets a lot more complicated | 22:45 |
| salv-orlando | midodan: on case 3 do we still have a VEB? | 22:45 |
| danwent | with libvirt direct, I do not think so | 22:45 |
| midodan | salv-orlando: maybe the bridge is implemented on the NIC | 22:45 |
| midodan | i mean, in case 3 | 22:45 |
| danwent | though in theory you could use a SR-IOV device with a bridge | 22:46 |
| salv-orlando | midodan: that makes sense. so VFs are bridge ports and the PF is the uplink | 22:46 |
| midodan | salv-orlando: sure | 22:46 |
| danwent | salv: essentially, yes, that is how I think about it | 22:46 |
| *** RamD has quit IRC | 22:46 | |
| midodan | and dan is right, that SR-IOV could be used with a real bridge as well | 22:46 |
| salv-orlando | midodan: instead about case 4, I have the impression in that case nova should not do anything about networking | 22:47 |
| salv-orlando | as the interface would be plugged by the nearest edge physical switch | 22:47 |
| midodan | salv-orlando: i understand, but isn't Nova still concerned about the VIF id? | 22:47 |
| midodan | and whatever vport id that is plugged into? | 22:47 |
| danwent | midodan: agreed. | 22:47 |
| danwent | nova must ultimately pass XML to libvirt and communicate an "interface binding" | 22:48 |
| midodan | i'm actually not familiar with the 'direct' stuff in libvirt | 22:48 |
| midodan | what is the format with of the edge binding info? | 22:48 |
| midodan | ah | 22:49 |
| midodan | ic | 22:49 |
| midodan | <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> | 22:49 |
| danwent | midodan: this is really just part of the "contract". we could define a standard format and make an admin API for Quantum, but for right now it could be as simple as having nova set a value in the OVS db (which is the trick we're using right now). At the end of the day, its just a way of associating an ID with the quantum plugin's notion of a "port" | 22:49 |
| midodan | so that stuff is magically communicated to the next hop bridge? in band? | 22:50 |
| danwent | (and I mean a "physical" port, not a "logical port") | 22:50 |
| danwent | that is for VEPA | 22:50 |
| SumitNaiksatam | dont forget Qbh :-) | 22:50 |
| danwent | its slightly different for VN-link. | 22:50 |
| danwent | yes :) | 22:50 |
| midodan | argh! | 22:50 |
| SumitNaiksatam | that format is slightly different | 22:50 |
| SumitNaiksatam | dan: thanks :-) | 22:50 |
| danwent | midodan: yes, for VEPA is seems like libvirt takes care of communicating that to the switch | 22:50 |
| danwent | (I haven't use it myself though...) | 22:51 |
| midodan | ok, good to know | 22:51 |
| *** ecarlin has quit IRC | 22:51 | |
| midodan | looks like i got more self education to do | 22:51 |
| salv-orlando | Sumit: we'll say EVB, so you both guys will be happy :-) | 22:51 |
| danwent | midodan: yes, so in sum I think we're basically going to want the flexibility to have several different ways to generate the <interface> XML. | 22:51 |
| danwent | as we have no idea what might come down the pipe next, that again, is slightly different :) | 22:51 |
| midodan | danwent: ok, i'm getting the picture | 22:51 |
| *** markvoelker has quit IRC | 22:52 | |
| danwent | Let's make sure the nova refactoring blueprint has a seciton on this | 22:52 |
| midodan | danwent: even focusing mostly on software virtual bridge case, like using OVS, i still have something that needs clarification | 22:52 |
| danwent | and we can continue this discussion there. | 22:52 |
| danwent | midodan: ok | 22:52 |
| midodan | yeah, good point | 22:52 |
| danwent | midodan: did you have something you wanted to ask? | 22:53 |
| midodan | danwent: i type slow | 22:53 |
| danwent | :0 | 22:53 |
| danwent | :) | 22:53 |
| danwent | I type badly | 22:53 |
| midodan | danwent: let's say we don't use a single bridge per host, how could we agree on which bridge to use for each attachment? | 22:53 |
| midodan | that's one case | 22:53 |
| danwent | midodan: so you're talking about the scenario where the "contact" is that nova creates a linux device (e.g., with libvirt) but does not associated it with a bridge and leaves that to the quantum plugin? | 22:54 |
| danwent | "contact" -> "contract" | 22:54 |
| midodan | danwent: yes, that's about right. | 22:54 |
| danwent | in this case, the quantum plugin would seem to need an agent. | 22:55 |
| danwent | and there would have to be some way to communicate the "interface binding" of <iface-id, linux-dev, hypervisor-id> to quantum | 22:55 |
| midodan | right | 22:55 |
| danwent | where iface-id is the logical iface-id, and the linux-dev + hypervisor-id indicate the current binding for that interface | 22:55 |
| midodan | ok, starting to get the picature | 22:56 |
| midodan | why does hypervisor-id need to be in there btw? | 22:56 |
| danwent | if you have multiple hypervisors, the linux-dev name (e.g., tap0) is not unique globally | 22:56 |
| midodan | oh, ha, ok | 22:57 |
| danwent | so if the quantum plugin was managing several vswitches on different hypervisors, I think you would need to make a distinction | 22:57 |
| midodan | we've pretty much been using only kvm | 22:57 |
| midodan | so hadn't run into that | 22:57 |
| danwent | sorry, can you clarify? | 22:57 |
| midodan | ah, wait, i'm sorry, i totally misunderstood | 22:58 |
| midodan | of course, the tap0 is unique only per host | 22:58 |
| midodan | so you mean, hypervisor-id, is the host | 22:58 |
| midodan | ? | 22:58 |
| SumitNaiksatam | guys, this is a good point | 22:58 |
| SumitNaiksatam | i wanted to ask this | 22:58 |
| danwent | yes, sorry | 22:58 |
| midodan | my bad, thanks | 22:58 |
| danwent | np | 22:59 |
| danwent | Ok, I actually need to run for a 4pm meeting. | 22:59 |
| SumitNaiksatam | how does quantum know on which host the VM is being spawned? | 22:59 |
| danwent | Let's make sure that we get a section on the current refactoring blueprint on this. | 22:59 |
| midodan | ok, let's pick this up later, offline | 22:59 |
| midodan | ok | 22:59 |
| SumitNaiksatam | ok carry over the discussion | 22:59 |
| midodan | thanks | 22:59 |
| salv-orlando | let's try and start an email thread | 22:59 |
| danwent | Sumit: when it gets the "interface binding", this will be included, if this info is needed. | 22:59 |
| SumitNaiksatam | ok, will wait for the BP :-), guess that will make it clear | 23:00 |
| midodan | SumitNaiksatam: wishful thinking ;) | 23:00 |
| SumitNaiksatam | email thread is fine too, good idea salv | 23:00 |
| danwent | or etherpad? | 23:00 |
| danwent | link to the BP? got to run. thanks guys. | 23:00 |
| salv-orlando | I hate that etherpad does not notfy me when someone updates it | 23:00 |
| *** danwent has left #openstack-meeting | 23:00 | |
| salv-orlando | ok, dan has gone... | 23:01 |
| SumitNaiksatam | salv: +1 | 23:01 |
| salv-orlando | midodan, Sumit: email or etherpad? | 23:01 |
| SumitNaiksatam | salv: prefer emails | 23:01 |
| midodan | i'm fine either way | 23:01 |
| SumitNaiksatam | but either way fine | 23:01 |
| SumitNaiksatam | shall i start an email thread? | 23:02 |
| salv-orlando | Sumit: sure go ahead | 23:02 |
| midodan | go for it | 23:02 |
| SumitNaiksatam | ok will send | 23:02 |
| SumitNaiksatam | thanks guys! | 23:02 |
| salv-orlando | I will be glad to throw my $0.02 at it! | 23:02 |
| salv-orlando | bye, have a good night/evening/afternoon/morning | 23:03 |
| midodan | ciao | 23:03 |
| SumitNaiksatam | catch you on the email thread, bye! | 23:03 |
| *** midodan has left #openstack-meeting | 23:03 | |
| *** jlm^ has left #openstack-meeting | 23:03 | |
| *** salv-orlando has quit IRC | 23:03 | |
| *** eperdomo has quit IRC | 23:03 | |
| *** romain_lenglet has left #openstack-meeting | 23:08 | |
| *** Jamey has quit IRC | 23:13 | |
| *** Jamey has joined #openstack-meeting | 23:20 | |
| *** ryu_ishimoto has quit IRC | 23:22 | |
| *** SumitNaiksatam has quit IRC | 23:35 | |
| *** troytoman is now known as troytoman-away | 23:43 | |
| *** adjohn has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!