Tuesday, 2011-06-14

*** sebastianstadil has quit IRC00:17
*** heckj has quit IRC00:39
*** adjohn has joined #openstack-meeting01:11
*** zul has joined #openstack-meeting01:26
*** dendro-afk is now known as dendrobates01:37
*** sebastianstadil has joined #openstack-meeting02:05
*** dendrobates is now known as dendro-afk02:12
*** vladimir3p has joined #openstack-meeting02:38
*** dendro-afk is now known as dendrobates02:39
*** medberry is now known as med_out04:01
*** cbeck has quit IRC04:03
*** cbeck has joined #openstack-meeting04:03
*** santhosh has joined #openstack-meeting04:12
*** santhosh has quit IRC04:22
*** santhosh has joined #openstack-meeting04:22
*** santhosh has quit IRC04:25
*** Binbin has joined #openstack-meeting04:34
*** sebastianstadil has quit IRC04:38
*** sebastianstadil has joined #openstack-meeting04:59
*** Binbin has joined #openstack-meeting05:09
*** vladimir3p has quit IRC07:06
*** Binbin has quit IRC09:06
*** Binbin has joined #openstack-meeting09:07
*** Binbin has quit IRC09:29
*** Binbin has joined #openstack-meeting09:42
*** sebastianstadil has quit IRC09:47
*** chmouel has quit IRC09:49
*** chmouel has joined #openstack-meeting09:51
*** Binbin has quit IRC10:16
*** GasbaKid has joined #openstack-meeting10:18
*** adjohn has quit IRC10:39
*** adjohn has joined #openstack-meeting11:23
*** zul has quit IRC11:24
*** zul has joined #openstack-meeting11:24
*** GasbaKid has quit IRC11:38
*** adjohn has quit IRC11:39
*** adjohn has joined #openstack-meeting12:13
*** med_out is now known as medberry13:26
*** edconzel has joined #openstack-meeting13:43
*** jkoelker has joined #openstack-meeting14:24
*** vladimir3p has joined #openstack-meeting14:34
*** dragondm has joined #openstack-meeting14:40
*** adjohn has quit IRC14:52
*** dendrobates is now known as dendro-afk15:15
*** dendro-afk is now known as dendrobates15:16
*** heckj has joined #openstack-meeting15:30
*** johnpur has joined #openstack-meeting15:31
*** dendrobates is now known as dendro-afk15:35
*** dendro-afk is now known as dendrobates16:04
*** Tv has joined #openstack-meeting16:30
*** primeministerp has joined #openstack-meeting17:54
*** masumotk has joined #openstack-meeting18:08
*** masumotk has quit IRC18:15
*** edconzel has quit IRC18:36
*** markvoelker has joined #openstack-meeting18:36
*** masumotok has joined #openstack-meeting18:39
*** jbryce has joined #openstack-meeting18:49
*** nati has joined #openstack-meeting18:59
mtaylork. who's ready to talk about CI and testing stuffs?19:00
natiHi I am OK19:01
*** dabo has joined #openstack-meeting19:01
mtaylorgreat! we have someone other than me. :)19:01
mtaylorwe'll give people a few to see who shows up19:01
markwashmtaylor: I'm here, sort of standing in for dan prince19:02
mtaylorsweet. good to have you19:02
openstackMeeting started Tue Jun 14 19:02:42 2011 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.19:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.19:02
mtaylor#info Added an agenda overview to the wiki19:03
mtaylor#link http://wiki.openstack.org/Meetings/CITeamMeeting19:03
mtaylorSo - I guess let's get this puppy rolling19:04
mtaylor#topic Discuss/Present overall CIPlan as it currently stands19:04
*** openstack changes topic to "Discuss/Present overall CIPlan as it currently stands"19:04
termieso, starting with ciplan19:04
mtayloryup. seemed like a good idea to start at the beginning19:05
termiewhich smoke testing are you referring to?19:05
mtaylor#link http://wiki.openstack.org/CIPlan19:05
mtaylorwell, right now to the jenkins job which is useless19:05
termiethe stuff in /smoketests only?19:05
mtaylorI was _actually_ just talking about the infrastructure to run it - but yes, to run the stuff in nova's /smoketests19:06
*** dprince has joined #openstack-meeting19:06
termieso, for those the general plan is: start a vm, provision with chef, point smoketests at them19:07
termieat 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 cluster19:07
mtayloryup. although I'd say the general plan is "start a vm, install/provision with something, test them"19:08
termiebut you seem to be set on using external cloud servers19:08
termiei am asking for a more concrete plan19:08
termie"something" == chef scripts from openstack-recipes19:08
termiein my opinion19:08
mtaylorwhat I was going to say is that for now "install/provision with something" seems to be chef as a best practice19:08
termieif there is no disagreement lets start saying htat19:08
termieinstead of something19:08
mtaylorwe were starting at the beginning here today, so I thought we'd be clear19:09
termiewe are clarlifying19:09
natiWill chef scripts  be standard openstack deployment tool?19:09
termienati: i think they will be one of them, the puppet guys will also have a set of tools19:09
mtaylornati: that's certainly a possibility19:09
mtayloryeah - and getting in to chef v. puppet is certainly not something I care to do anytime in my personal near future19:10
natiI think OpenStack should have an official deployment tool, and Smoketesting tool should use the official one.19:10
termienati: agreed, but we can't make the political statement right now19:10
natiBecause we should test deployment tool also.19:10
termienati: for now we are going to use the chef recipes19:10
mtaylorright. because they are what's there19:10
termieand our docs will describe the usage of those19:10
termieand our tools will depend on them19:11
termiethe puppet guys will do owrk to make those tools able to use puppet as well19:11
*** medberry is now known as med_out19:11
termiebut that onus is on them19:11
termiewe like them we just have more inertia on chef right now19:11
termieso, for the vm stuff, shall we say we use rackspace cloud servers?19:11
termieor vagrant?19:11
mtayloryes. I think that gets us the best ability to do many of these in parallel19:12
termiewe also can get them more cheaply than amazon i assume19:12
mtayloryes. yes we can :)19:12
dprinceChef cookbooks written properly should work on bare metal, cloud, or a personal VM on your laptop (vagrant).19:12
mtaylorwhich then gets us to getting the damn thing working19:12
termiedprince: yup, that's the goal19:12
mtaylordprince: yes. agree19:12
mtaylorthe two approaches on the table in my head for making this happen are:19:13
dprinceSo the way I see us collaboration working here is we collaborate on good config management practices.19:13
mtayloropenstack_vpc fired from jenkins - or just firing up a node and doing the chef bits on it by hand19:13
*** joshuamckenty_ has joined #openstack-meeting19:13
termiewhat is openstack_vpc?19:13
mtaylorI am, at this point, fine with either19:14
mtayloropenstack_vpc is the thing that powers smokestack19:14
jaypipestermie: https://github.com/dprince/openstack_vpc19:14
termiecool, will that kick of chef pieces?19:14
*** joshuamckenty_ has quit IRC19:14
termieperfect, lets use that19:14
mtaylorthe main question I have for folks there is19:14
termiewe can make dprince make it ddo what we want :))19:14
jaypipestermie: https://github.com/rackspace/chef_vpc_toolkit19:14
natiIs there any limitations of VPC?19:14
dprinceTermie, 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-meeting19:15
dprincenati: The limitations of VPC are the same limitations you'd hit on Cloud Servers.19:15
mtayloris 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 tests19:15
termiedprince: bug xtoddx to get them integrated?19:15
termiewhere is the redis requirement?19:15
termienova doesn't use redis anywhere anymore i thought19:15
jaypipestermie: smokestack does...19:16
mtaylorgreat! I just know that there were already redis processes on the jenkins box, and I didn't want to step on anything19:16
dprincetermie: Smokestack uses --> Cloud Servers VPC. Both of these are Rails apps for which I'm using a Redis backed job queue (Resque).19:16
markwashmtaylor: I don't think openstack_vpc needs redis19:16
markwashmtaylor: just the stuff built on top of it19:16
mtaylorproblem solved then - redis on jenkins box is historical and non-conflicting19:16
dprincemtaylor: I'm happy to let you have access to the Cloud Servers VPC instance we are using on Titan.19:16
termiedprince: so vpc is not a command-line tool19:16
dprincetermie: openstack_vpc is a set of config files and rake tasks to spin up testing groups.19:17
mtaylordprince: 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
dprincetermie: it is command line driven.19:17
dprinceSmokestack scripts it.19:17
termiedprince: but we have to have a server running all the time that hits that server?19:17
termieand a cli that hits that server19:17
dprincetermie: openstack_vpc uses Cloud Servers VPC to spin up cloud servers.19:18
mtaylortermie: Cloud Servers VPC is an always running rails app - so yes19:18
termieand what does its always running get us over having it just do a one-shot thing?19:19
mtaylordprince: 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
termiethe queuing and such can be handled by jenkins, is what i am getting at19:19
mtaylortermie: yes19:19
mtaylorso - eventually I want to just have jenkins spin up the servers and do the chef bits19:19
*** creiht has joined #openstack-meeting19:20
termieagreed, but i think we should be using a common tool for that19:20
mtaylorbut having jenkins call openstack_vpc should get us further today19:20
termieand it sounds like vpc has the pieces for it19:20
termiei just don't want another long running process to maintain19:20
dprinceSo 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
termiethat would be grand19:21
termiehave mtaylor make you admin'y?19:21
mtaylorthere are things I would like to do with that setup long term - but that gets us a thing we need today19:21
mtaylorand we can talk about the other long term things later19:21
mtaylordprince: are you dprince on launchpad?19:21
dprinceI'm dan-prince.19:21
termiewe set up an openstackvpc instance (probably just steal titan's for now)19:21
mtaylordprince: ok. you are now an admin on the openstack jenkins19:22
dprinceAlso. I'm happy to make Cloud Servers VPC available for anyone else to use as well.19:22
termiewe deploy a single and multinode setup as per anso's old vagrant testing, and run the nova smoketests against ahtat19:22
natiCan we test VLANManager on VPC?19:22
termiesmokestack is just doing openstack api, right>?19:22
dprincetermie: I'm now running the nova smoketests too.19:23
dprincetermie: minus volume tests.19:23
termieah, do we think there is a way to integrate those?19:23
dprinceThe issue is I can't get iscsi-target to run on Cloud Servers.19:23
termiei'd say in that case lets just ditch the first section of CIPlan and replace it with smokestack19:23
mtaylordprince: is it possible to run them with the xunit xml output and get those copied back to the jenkins box?19:23
dprincemtaylor: Sure. We can do that.19:24
termieit sounds like titan has a strong lead on most of this19:24
mtaylortermie: 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 stuff19:24
dprinceSo. On that front I actually have mixed feelings.19:24
termiemtaylor: right, just saying integrate smokestack instead of writing your own bits19:25
termiedprince: oh? do tell :)19:25
dprinceIs the idea that we would prevent (block the trunk commit) if the functional tests fail?19:25
mtaylorif he's already got that work done on a different jenkins19:25
mtaylormaybe - the idea is that I want to be able for us to make that choice19:25
mtaylorso that the choice is policy and not lack of ability19:25
dprinceThe model we've been following on Titan is we run branches in merge prop. Heavily. Its kind of a review tool.19:25
termiedprince: i think that is a tarmac config issue rather than a jenkins config issue19:25
termiedprince: we want that as well19:26
mtaylorso on _that_ one _I_ have mixed feelings19:26
termiedprince: we == ansoy people at least19:26
mtaylorwhich is a security thing19:26
mtaylorrunning heavily on branches from known folks is one thing19:26
*** edconzel has joined #openstack-meeting19:26
mtaylorrunning code from _any_ unreviewed merge prop is, well, fail19:26
dprinceRight. 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
dprinceI'd hate to hold up a trunk commit if there is a long lived dependency failure.19:27
mtaylorI have no issues holding up a trunk committ19:27
mtaylorthe whole idea is to keep trunk in good shape19:27
termiedprince: well, once we're on github some of those things will be a little bit easier to work around19:27
mtaylorbut that's a whole other thing19:27
termiedprince: it is relatively easy to integrate things into your dev tree and take them back out later19:28
mtaylorI don't think any part of this has anything to do with github v. launchpad - but that's _also_ a different conversation19:28
dprinceSure. I just wanted to make sure everyone was on the same page.19:28
mtayloryup. for now...19:28
mtaylordprince: can I put you down with an action of getting smokestack jenkins job done?19:28
dprinceAlso the tests as is take 15 minutes. Is that everyone acceptable with that?19:28
dprincemtaylor: Sure. I can take that.19:29
mtaylor#action dprince make smokestack jenkins job19:29
termiefor 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 off19:29
*** mrmartin has joined #openstack-meeting19:29
termietitan can continue doing it for their own stuff, obvs19:29
mtayloralthough 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 win19:30
termiestep 1, public smokestack, step 2, tarmac integration19:30
termiewant to move to baremetal bits?19:30
dprinceSure. 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
termiedprince: we'll want to get nosexunit out19:31
mtaylordprince: also - take a peek at the nova-sometest job at the nosexunit output stuff19:31
mtaylorbecause we want that too19:31
* mtaylor will purchase for dan prince a beer19:31
dprinceOne the bare metal thing. I've got 4 nodes that I'm working on getting integrated with XenServer testing.19:31
termieare we moving to baremetal now?19:32
mtaylor#topic Jenkins job to integrate/fire bare metal testing19: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
termiei am wondering what rpath is offering19:33
mtaylorrpath is offereing something for this similar to what dprince just offered for functional19:33
termiewe had a nicely working pxe + ubuntu bootstrap setup working already19:33
termiethat only needed the chef provisioning bits on the client side19:33
dprinceFor bare metal testing I'm actually very interested in using Dells Crowbar project.19:33
mtaylorthey currently have a jenkins running jobs that inject images in to cobbler and stuff19:33
termiedprince: everybody is but it doens't exist yet19:33
*** sebastianstadil has joined #openstack-meeting19:33
mtaylorI'm less interested in crowbar unless it's only one of the solutions19:34
termiedprince: and many of us are a bit tired of waiting on them19:34
mtaylorbecause just testing dell is mega uninteresting to me19:34
dprincetermie: I'm asking for the bits as we speak...19:34
dprince(via emails, etc).19:34
termiethe chef scripts would theoretically be the same19:34
*** joshuamckenty_ has quit IRC19:34
termieso all we really need is a simple script to kick off chef clientside19:34
*** dabo has left #openstack-meeting19:35
dprinceI'm working on a XenServer cookbook to help setup the dom0 and domu.19:35
termieour side doesn't know how to do that, we're still kvm-ville19:35
termiefor the moment though i'd love to get what we already had nearly working finished19:36
mtayloryup. and I can turn my attention to that now that we're considering functional done via smokestack19:36
mtaylortermie: did you have a reason for doing pxe stuff directly and not using cobbler or something similar?19:37
termiemtaylor: it was dead simple and didn't require learning much as we were already doing it for nasa19:37
dprinceHow many machines do you have access to?19:37
termiedprince: i think 2019:37
mtaylorwe have 10 machines19:37
termieyou have 10 or we gave you 10?19:38
dprinceCool. Well we have 4 on titan. Not as many but they are big boys. 48 Gigs of memory, lots of disk.19:38
mtaylorsomeone gave me access to 1019:38
termiemtaylor: was it us who gave you access? i am trying to ask whether you are uysing the ones we allotted or some other mystery set19:38
mtaylortermie: the ones from jesse - so probably19:38
mtaylortermie: "us" is very nebulous to me most of the time19:39
*** joshuamckenty_ has joined #openstack-meeting19:39
termiemtaylor: ex-anso is my usual us when i am acting as spokesperson19:39
termiewe don't really have a good line of distinction19:39
mtaylorfair - I guess I should be more clear - that doesn't mean anything to me either ... but it's really not important right now19:40
termiebut anso is the easiest19:40
mtaylorin any case- I have access to 10 machines in the equinix facility in the bay area- I believe these are from "you"19:40
termieso i will assume we can't give you any more19:41
mtaylorI'm also assuming that19:41
mtaylorthe 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 thing19:42
mtaylorthat, obviously, will not be what we do in the short term - but that's the aim19:42
dprinceWhy so many to swift?19:42
termiei'd say 4 nova, 4 swift 1 glance and one orchestrator19:43
dprinceI'd go for more nova myself.19:43
termie4 swift just to test replication and have a separate proxy19:43
dprinceOkay. I see.19:43
mtaylorthere was a reason they said 5 instead of 4 - jaypipes do you remember what it was?19:43
mtaylorbecause I'd love to have the orchestrator be separate19:43
termiesame here19:44
termiebecause the other machines hsould probably be in a different network config19:44
mtaylorok. 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
jaypipesmtaylor: no, I can't remember why.19:45
mtaylorwe 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 stuff19:45
mtaylorshould probably be easier to make use of that once we have the first set of these up and going19:46
termieso action items for monty?19:48
mtaylorso - 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
termienope, we have those19:48
termiebut they will probably have to be updated for baremtetal19:48
termiethe stuff i gave you kicks off a chefserver in lxc19:48
mtaylor#action mtaylor jenkins job that fires off pxe19:48
mtaylorsaw that19:49
termiewe have probably additional knowledge on some of that now19:49
mtaylorthe key there then is getting the right chef stuff running on the machines once they are booted19:49
termieso you can ask us questions19:49
termieyeah, but it sounds like dprince might know some of that19:49
mtaylorI'd love to - as chef makes me want to rip my arms off19:49
termiethat was where i handed things to you19:49
termieso i don't know how to actually kick off a chef client19:49
termieit makes me want to rip my arms also19:50
termiealthough they claim it is getting better19:50
mtaylordprince: I'll be coming at you for questions on that19:50
dprincemtaylor: Sure. Happy to help.19:50
mtaylortermie: I keep expecing something like a command line "chef nova-node"19:50
termieyeah me too19:50
mtaylortermie: but instead apparetnly I have to write json files :)19:50
termiebut it is like, get this key from somewhere19:50
mtaylorok. as long as it's not just me19:50
termievagrant does it, too, if you want to read some ruby19:51
mtaylorfor now, I'll make sure I get the first bits up and kicking, and then I'll bug dan on the next step19:51
mtaylorit does - and there's too much magic in the vagrant files to help me figure out what to do on the command line19:51
mtaylordarned "helpful" things19:51
mtaylorwhatever - I'm sure I'll be a chef expert by the time this is all said and done19:52
mtaylornext 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 today19:53
termiei think we effectively punted that earlier19:53
mtaylorwe're running short on time - anybody got anything else on bare metal for now?19:53
termieonly thing i would asdd is due dilligence to see what loren has19:53
termieUSC guy who has done a bunch of baremetal stuff19:54
termieactually probably not useful for now19:54
termieit is for provisioning baremetal from nova19:54
termielet's skip19:54
mtaylorah. cool.19:54
termiei'll keep up with him19:54
mtaylorI'm going to combine a couple of topics real quick:19:55
mtaylor#topic Jenkins Plugins19:55
*** openstack changes topic to "Jenkins Plugins"19:55
mtayloranybody want to do any Java hacking?19:55
termiewe don't need any right now, right?19:55
termieyou want to replace tarmac, i guess, but do we need to?19:55
*** joshuamckenty_ has quit IRC19:55
mtaylorwell - we need some at some point - and I always want to ask if there's anyone lurking who wants to help19:55
mtaylorwe're getting close to the point where we need to19:56
termiewhy do we need to?19:56
mtayloras 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 gatekeeping19:56
termiewhat is being double implemented?19:56
mtaylorwell, nothing right now - we're just not adding those things to the gatekeeper as of yet19:57
mtaylorbut our friends at ntt wanted to add code coverage metric counts to the gatekeeping19:57
mtaylorand since we're already tracking that in jenkins - if dependent jobs worked for us, that would be a piece of cake19:57
mtaylorbut the tarmac/roundabout is ignorant of jenkins19:58
*** zns has joined #openstack-meeting19:59
termiehow is it ignorant of jenkins?19:59
mtaylorin 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 it19:59
termieit rungs the tests19:59
termieso, not that i want to19:59
termiebut i can be a java devloper19:59
mtaylorit runs tests that are defined in a config file on the file system - the only interaction is that jenkins runs tarmac19:59
termiebut i don't think we need it19:59
*** dolphm has joined #openstack-meeting19:59
ttxone minute left :)19:59
mtaylortarmac can't pass/fail things based on the outcome of jenkins jobs19:59
termiereally? i thought that was exactly what it did20:00
termiethat is what roundabout does20:00
mtayloror - is it really?20:00
termie... yeah20:00
termieit runs the tests in jenkins and then if it fails it dumps info into th elof20:00
mtaylorok - I'll re-look at it - I thought it did the same thing that tarmac did20:01
termiepretty sure20:01
termieplz double check though20:01
jbrycetime to wrap up?20:01
mtaylorI will20:01
mtaylor#action mtaylor will look at roundabout jenkins triggering20:01
mtaylorok guys - till next week20:01
termieokay wrap up20:01
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"20:01
openstackMeeting ended Tue Jun 14 20:01:29 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-19.02.html20:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-19.02.txt20:01
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-19.02.log.html20:01
jbrycemeetingpalooza continues....who's here for ppb?20:01
termieso, for the next meeting, i think i was supposed to talk about github movement?20:02
termieor is that a different meeting?20:02
jaypipestermie: that's this one.20:02
jbrycetermie: honestly not sure we'll get to that, but you can hang around20:02
*** jesse_ has joined #openstack-meeting20:02
*** med_out is now known as medberry20:02
termiealso, mtaylor: could you write shorter emails pls? kthx :D20:02
mtaylortermie: never! :)20:02
*** jesse_ is now known as anotherjesse120:03
openstackMeeting started Tue Jun 14 20:03:14 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.20:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.20:03
jbrycehttp://wiki.openstack.org/Governance/PPB - agenda20:03
termiek, well i'll lurk, say my name (!!) if you get to githubbery20:03
jbrycetermie: ok20:03
jbryce#topic previous action items20:03
*** openstack changes topic to "previous action items"20:03
jbrycelooking back through the meeting logs, i think we're caught up on almost everything. one outstanding issue was a q&a system20:04
jbrycedoes anyone know where we stand on that?20:04
johnpurwe have deferred it until the new tcm comes on board20:04
notmynamewhat's a tcm?20:05
johnpursince he/she will own it20:05
jbrycetechnical community manager20:05
johnpurtechnical community manager20:05
jbryce#info deferred implementation of q&a software, waiting for technical community manager20:05
jbrycesebastianstadil: you around sebastian?20:05
sebastianstadiljbryce: I am20:06
* soren is here now, sorry, was distracted.20:06
jbryce#topic Scalr incubation application20:06
*** openstack changes topic to "Scalr incubation application"20:06
jbrycehttp://wiki.openstack.org/Scalr - incubation application for scalr20:06
ttxwho starts ? :)20:07
jbrycedid everyone get a chance to review the application? anyone have questions?20:07
jbrycei know one issue that's already been brought up is language choice20:07
ttxI have a few...20:07
sorenI've not actually had a chance to read it. :(20:07
* soren does so real quick.20:07
sebastianstadilIt's succint.20:07
johnpuri would like to know the state of the scalr dev community, contributors, activity outside of the core, etc.20:07
johnpurhow it might mesh witht he current OS community20:08
ttxjohnpur: yes, I find the source code repository to be a bit scary in that respect20:08
mtaylorgoogle code --20:08
ttxhttp://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 while20:08
ttxwhich clearly does not match our way of doing things20:09
sebastianstadilReason is that the Google code repo is super slow20:09
ttxsebastianstadil: does that mean you plan to change that in the incubation is accepted ?20:09
sebastianstadilttx: We plan on changing that regardless20:10
notmynameto what?20:10
sebastianstadilGithub has our preference so far20:10
johnpursebastianstadil: i assume that there is little to no outside community then?20:11
sebastianstadilAbout half a dozen community patches over the lifetime of the project20:11
jaypipesMy 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
sebastianstadilMinor fixes20:11
dendrobatessebastianstadil: what happens to the scalr name if scalr becomes part of openstack and you change your mind and want to leave?20:11
ttxjaypipes: +120:11
ttxas 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 things20:12
ttxI mean, I see how it fits with OpenStack... but not as a core project withing OpenStack20:12
ttxand incubating projects are candidates for core in the end.20:12
*** david has joined #openstack-meeting20:12
sebastianstadilttx: I believe that at the end of the day we want people to use this stuff. That's what Scalr helps with20:13
johnpurit 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
sebastianstadilttx: We want people to be able to build complex applications, manage them, and gain all the agility that comes with the cloud20:14
jaypipesI 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
sorenTo be fair, Glance also interfaces with S3.20:14
sebastianstadilttx: Right now it's still easier to use dedicated hardware and scale up then use the cloud20:15
johnpurit is clear that with the success of RightScale and projects like Scalr that folks that deploy on clouds benefit from these sorts of systems20:15
soren...so there's certainly prior art to core projects being able to interact with stuff that isn't OpenStack.20:15
sebastianstadiljohnpur: Precisely.20:15
sebastianstadilThere's no way a Zynga would not use a RightScale / Scalr / other management suite20:16
johnpurjaypipes: can you elaborate? why not incubate?20:16
jaypipessoren: 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
jaypipesjohnpur: ^^20:16
sebastianstadilJust too hard to manage hundreds or thousands of servers and not go mad with the complexity20:16
sorenjaypipes: That will always be the case in the beginning when you add stuff at the top of the dependency chain.20:16
sorenjaypipes: ...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
sebastianstadiljaypipes: In the beginning, it would indeed be one-way20:17
sebastianstadiljaypipes: but I think we should focus on users of OpenStack as well20:18
jaypipessoren: 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
sebastianstadiljaypipes: auto-scaling20:18
sebastianstadiljaypipes: which requires a lot of different elements20:18
jaypipessebastianstadil: 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
sorenjaypipes: I think the situation where new projects build upon existing one is ideal.20:19
jbrycei 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 forming20:19
sorenIn the sense that they consume their API's and provide more value that way.20:19
johnpurjbryce: hence incubation vs core20:20
jaypipessoren: then what is "core"?20:20
dendrobatesjbryce: that is in fact the very idea of Donabe20:20
sebastianstadilVery much agree with soren20:20
sorenjaypipes: Fantastic question.20:20
sorenjaypipes: ..with many answers, clearly :)20:20
jaypipessebastianstadil: I'm not disagreeing with you or soren :) just wondering where the "core" line is...20:20
jaypipessebastianstadil: since incubated projects are intended to become core, that's the question we're trying to answer here ;)20:21
sebastianstadiljaypipes: Help us define it then!20:21
jaypipessebastianstadil: OK, I'll give it a shot...20:21
sorenjaypipes: I have some answers to what it doesn't mean :)20:21
johnpurjaypipes: core projects will have significant community interest and involvement20:21
jaypipesI think that core projects are the "building blocks" that other services and projects use to create an entire platform.20:21
jaypipesI can't see Scalr as a building block. I see it as a platform.20:22
dendrobatescore projects require tight integration with the other core projects20:22
johnpurand be the "best" solution to a set of defined problems20:22
jaypipessebastianstadil: that make sense?20:22
ttxsebastianstadil: 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 it20:22
johnpurjaypipes: do you object to having a "PaaS" project in incubation?20:22
sorenjaypipes: I think what we're seeing with Scalr is simply that they have a massive head start.20:22
jaypipesjohnpur: yes.20:22
johnpurttx: +120:22
ttxsebastianstadil: going straight from "company owning development behind closed doors" to "openstack core candidate" is a bit quick20:23
*** joshuamckenty_ has joined #openstack-meeting20:23
sorenjaypipes: What would have happened with a more organic evolution is layers and layers and layers on top of the current core projects.20:23
sebastianstadiljaypipes: 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 application20:23
ttxOnce you open it on github and as an openstack ecosystem project, you might realize people want to take it in other directions20:23
sorenjaypipes: ...and eventually something like Scalr would turn up, combining it all into something really useful.20:23
jaypipessoren: sorry, I'm losing you. are you suggesting that that eventual solution would be a "core" project?20:24
sorenjaypipes: ...it just so happens that Scalr has existed for years and so have managed to get to that final point already.20:24
sorenjaypipes: Yes.20:24
johnpursebastianstadil: 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 request20:24
*** zns has quit IRC20:24
jaypipessebastianstadil: 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
johnpurjaypipes: for now20:24
*** zns has joined #openstack-meeting20:24
sorenjaypipes: 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
sebastianstadilttx: 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
jaypipesjohnpur: are you saying "for now" as in "jay will change his mind later"?20:25
jaypipessoren: ok, I hear you. but it does to me. :)20:25
sorenIt's more along the lines of "this is the component that solves problem X that we as a project stand behind".20:25
ttxsebastianstadil: incubation is more to get in line with openstack processes than to "become open"20:25
johnpuri am saying that OpenStack will likely evolve and mature, evidence is that Cloud systems go "up the stack"20:25
sorenI tend to build my stacks upwards, not sideways :)20:25
edaysebastianstadil: 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
sebastianstadilttx: People do want to take it in other directions, a company recently wanted to make the IaaS-interface modules OCCI compatible20:26
ttxwe need to judge if the project fits, but going more open will chnage your project significantly20:26
jbrycesoren: ++20:26
ttxso I fear that what we judge today might not be what it becomes20:26
sorenjaypipes: I can see how the term "core" suggests a sort of self-containedness.20:27
ttxsebastianstadil: saw dendrobates question above ? I think it's a good one too20:27
jaypipessoren: 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
sorenjaypipes: I don't, no. I don't see the analogy, though.20:27
ttxwould we use the name "scalr" as the name of the project ?20:27
sebastianstadileday: sign up at scalr.net to get a quick idea of the interface20:27
joshuamckenty_dendrobates: Presumably the same thing as the nova or OpenStack names.20:28
ttxit's more than just a codename like the others, it's a brand, and a company name :)20:28
jaypipessoren: 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 value20:28
jbrycettx: i would guess we'd probably come up with an openstack generic name20:28
johnpurttx: probably not, as Scalr will want to retain rights20:28
joshuamckenty_sebastianstadil: I think eday was asking about tight coupling with the ui20:28
sorenjaypipes: I don't think "core linux" makes any sense.20:28
dendrobatesjoshuamckenty_: except that scalr is also a company and all the core devs could leave.20:28
joshuamckenty_Openstack is also a company20:29
joshuamckenty_And a brand20:29
dendrobatesjoshuamckenty_: I just want to make sure that sebastianstadil understands the implications20:29
sorenjaypipes: I think of this more like Gecko being a core part of the Mozilla project, but so is Firefox.20:29
edaysebastianstadil: 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 functionality20:29
joshuamckenty_So the parallel standa20:29
jbrycejaypipes: nova is a collection of functionality provided by iptables, kvm/xen/etc, filesystems....every piece of software aggregates functionality from others at some level20:29
sebastianstadilttx: OpenStack Manager / Scalr / UI, I don't have any preference on the name to use20:29
sorenjaypipes: ...even though it builds heavily upon another core project of Mozilla.20:29
joshuamckenty_eday: +120:29
sebastianstadildendrobates: We can sign a document giving you use of the Scalr name if that's what you are concerned about20:30
johnpureday: you are suggesting that scalr could be decomposed into sets of services that can be driven by the UI?20:30
jaypipessoren: sorry, I still don't agree that a PaaS management interface should be a core project in OpenStack...20:30
sorenjaypipes: 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
jaypipessoren: that is "related" projects in my mind.20:30
joshuamckenty_johnpur: I think the scalr guest agent could be considered separately20:31
sebastianstadiljoshuamckenty_:  UI used to be tightly coupled, now it's just passing json to a js app on the client side20:31
sorenjaypipes: Anyone can say they're related. Only one project solving problem X can be core.20:31
johnpurhmmm, sebastian, what do you think of that?20:31
sorenjaypipes: -ish.20:31
ttxeday: I agree we should avoid overlap in core projects, so we have an issue with Dashboard20:31
edayjohnpur: 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 UI20:32
sorenAh! Dashboard!20:32
sorenjaypipes: Do you thing the dashboard should be core?20:32
ttxsoren: next topic :)20:32
jaypipessoren: no.20:32
sorenttx: I know :)20:32
sorenjaypipes: Ok.20:32
sorenjaypipes: Well, at least you're consistent. :)20:32
joshuamckenty_Flights taking off, you have my votes.20:32
jaypipessoren: for the next ten minutes, sure ;)20:32
jbrycejoshuamckenty_: thanks. good flight20:32
sorenjaypipes: :)20:33
jbryceok...can we pause for a minute to summarize the questions20:33
jbrycei'll take a stab at it20:33
jaypipessebastianstadil: 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 incubated20: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 projects20:34
sebastianstadilThe problem we're tackling is that building applications on Cloud resources is hard20:34
johnpuri 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
sebastianstadilThat's why OpenStack should have a Core project that addresses it20:34
jbryce#info should something that is primarily focused as a consumer and aggregator of other projects be in core20:34
jaypipessebastianstadil: 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 project20:35
notmynamejohnpur: isn't one of the purposes of incubation to help grow the community around a project?20:35
ttxjohnpur: so it should do "open development" and "open community" before applying ?20:35
sebastianstadiljbryce: Thanks, I'm still lagging behind on some questions20:35
*** dabo has joined #openstack-meeting20:35
sebastianstadilDoesn't the biological term incubation apply some sort of growth?20:36
sebastianstadilIt's not really a test20:36
johnpurmy 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 IRC20:37
sebastianstadilRegarding the dashboard, that's how Scalr started out: as an open source, web-based ElasticFox20:37
jbrycethose seem to be the main ones that i've picked out...did i miss any?20:37
*** User627 has joined #openstack-meeting20:38
sebastianstadilBut 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-meeting20:38
jaypipessebastianstadil: 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
sebastianstadiljbryce: Scalr is python for the guest agent, php for the controller, and js for the gui20:39
*** sandywalsh has joined #openstack-meeting20:39
ttxsebastianstadil: I also have a question, why would *you* want ScalR to be an OpenStack core project someday ?20:40
sebastianstadiljaypipes: Correct, at the last summit I had a few discussions on how to address that20:40
sebastianstadilttx: OpenStack is awesome, want to be part of it.20:40
ttxsebastianstadil: good :)20:40
jbryce= )20:40
johnpurnice answer20:40
jaypipessebastianstadil: nice bribe :)20:40
jbryce20 minutes before team meeting20:40
sebastianstadilttx: No technical reason, just a cool bunch that I like hanging out with20:40
ttxsebastianstadil: because that implies a lot of constraints on what was your company and your code20:41
jaypipessebastianstadil: even better :)20:41
sebastianstadilthe company is in service of the code20:41
ttxsebastianstadil: so it's not just a badge of honor or a club :)20:41
sebastianstadilhad we been venture funded, the company would have been in service of the shareholders20:41
sebastianstadilttx: I know :-)20:41
ttx(it's the first "established" project we consider for openstack incubation, hence the strange questions)20:42
jbrycedo people want more discussion or should we call a vote and see where we stand?20:42
sebastianstadilttx: Yeah, and we had to write a lot of code that solved problems from yesterday20:42
sebastianstadilttx: Like how to manage failover on a db that doesn't use network block storage20:43
sorenThe answer to that being: "carefully"20:43
sebastianstadilsoren: haha!20:43
jaypipesjbryce: 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
jbrycetime for the vote. should scalr be added as an incubated openstack project?20:43
jbrycejaypipes: correct.20:44
johnpurmy 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
sorenI'd actally like to talk aobut technical stuff.20:44
soren..before voting.20:44
*** markwash has quit IRC20:44
sorenMostly the PHP thing.20:44
ttxsoren: like, could we rewrite it in Python ?20:44
sorenttx: I'd have phrased it differently, but yes :)20:45
jbrycejaypipes: 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 seen20:45
ttxjbryce: aversion comes from the packaging burden that PHP carries. Is ScalR shipped in any distribution ?20:46
sorenttx: I'm 97% done packaging it for Ubuntu.20:46
sorenSorry, 87%.20:46
*** dprince has quit IRC20:46
johnpurttx: how "bad" is it? java scale?20:46
sorenJust saying.20:46
ttxjohnpur: of course not20:46
sorenNowhere near Java scale.20:46
johnpurjust saying20:46
sandywalshdoes scalr conflict with the direction dashboard wants to go?20:47
sorenIt's unpleasant, but certainly doable.20:47
sebastianstadilactual laughter was produced20:47
ttxjohnpur: though security-wise, PHP is a bit of a nightmare, I'm giving Sebastian the benefit of doubt over his PHP code :)20:47
ttxjbryce: unfortunately it's difficult to vote without considering Dashboard in parallel20:48
ttxjbryce: If they overlap, we'll have to choose between the two ?20:48
sebastianstadilttx: I think a successful Dashboard project will turn into a Scalr in 2-3 years20:48
jbrycettx: choose or find ways to combine20:48
sorenI don't enjoy php, but my primary concern at this point is really the divergence.20:49
sebastianstadilI've seen it with Scalarium, RightScale, and a few other projects20:49
ttxjbryce: so it seems unfair to vote on ScalR without giving Dashboard a chance ;)20:49
sorenI think sharing something as core as programming language between all core projects is really, really useful.20:49
johnpurwe should look at the opportunity to enhance the user experience by merging the two efforts where it makes sense20:49
jbrycettx: so defer vote for discussion of dashboard?20:49
sebastianstadilAnyone used thrift here?20:50
sorenNot directly, no.20:50
ttxsebastianstadil: aaaaaah20:50
jbrycesebastianstadil: unfortunately yes20:50
sorenI talked to a Cassandra instance once, so sort of. :)20:50
notmynamesoren: "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
sebastianstadiljbryce: Doesn't work as intended?20:50
jbrycesebastianstadil: to be fair, this was 12+ months ago...but scars can last a long time20:51
sebastianstadilThis doesn't go for the short term, but longer term the proportion of python to php will increase20:51
devcamcarsebastiansadil: are you more concerned about scalr's ui being a standard, or the interface to the orchestration layer being standard?20:51
sebastianstadildevcamcar: Not sure I understand20:51
ttxjbryce: maybe let devcamcar and sebastianstadil talk for a week and see if they can come up with something awesome ?20:51
sandywalshWould there be sufficient community adoption if it's in a different language compared to what we would get by sharing code directly?20:52
sebastianstadilI'm more concerned about making an awesome product for people to build awesome applications20:52
sorenI'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
johnpurttx: i like that20:52
ttxjbryce: like a django UI with autoscaling featurse.20:52
jbrycettx: yep20:52
ttxotherwise I have to think about which one I should give my +1 too, and that involves hearing Dashboard side of the story.20:53
sebastianstadilttx: It's actually more like Gmail20:53
devcamcarseabastiansadil: what about using just the python pieces?20:53
sebastianstadildevcamcar: Wouldn't help the end-users20:53
jbrycettxdevcamcar, 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 well20:53
devcamcari'm open to it but sebastian hasn't ever expressed interest  in that when we've discussed it20:54
devcamcaranyway you guys just spent an hour talking about scalr so there's not much for me to say today20:54
sebastianstadilI think a fully js engine >> mvc20:54
*** markwash has joined #openstack-meeting20:55
notmynamewouldn't that imply that one of them will be incubated? isn't it possible that neither get accepted?20:55
jbrycedevcamcar: sorry about that!20:55
soreni think this has been a very useful discussion, though. I'd hate to have cut it short.20:55
jbrycei agree20:56
*** nati has quit IRC20:56
jbrycesebastianstadil, devcamcar: you two are kind of are guinea pigs as this is are first pass at this20:56
johnpurjbryce: next steps?20:56
sebastianstadilSome brave enough to summarize the discussion?20:56
ttxnotmyname: I would like to see one of them. Your opinion may differ. Jay's opinion differs.20:56
jbrycenot everyone feels ready to have a firm vote on scalr without giving dashboard a full hearing20:57
notmynamettx: ha! if you and I didn't differ, one of us is wrong ;-)20:57
*** nati has joined #openstack-meeting20:57
ttxnotmyname: my.. head... hurts...20:58
jbrycei 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 python20:58
jaypipesjbryce: nice summary.20:59
johnpuri really like the idea of extending the dashboard functionality with scalr automation, can we have an action to have these discussions?20:59
jbrycenext 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 again20:59
sandywalshis 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
devcamcari'm available20:59
*** ohnoimdead has joined #openstack-meeting21:00
sorensandywalsh: If there's any sort of motivation to speak AMQP to anything, we're doing something wrong :)21:00
*** mldennis has joined #openstack-meeting21:01
ttxjbryce: #endmeeting ?21:01
jbrycedevcamcar: sorry again for making you sit this one out. we will definitely give you your day in the hot seat21:01
jbrycethanks guys21:01
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"21:01
openstackMeeting ended Tue Jun 14 21:01:12 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.html21:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.txt21:01
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.log.html21:01
*** somik has joined #openstack-meeting21:01
jbrycethese back to back meetings are a little crazy21:01
sandywalshsoren, I agree, but just making sure.21:01
ttxnothing like back-to-back meetings. Who is here for the regular OpenStack meeting ?21:01
sebastianstadildevcamcar: Want to chat again?21:01
heckjtotally missed the CI meeting two hours ago... :-(21:02
ttxvishy: ?21:02
edaysandywalsh: I would say AMQP only if we decided AMQP is a fully supported public API (like the REST API is)21:02
ttxok, let's get started21:02
*** ameade has joined #openstack-meeting21:02
openstackMeeting started Tue Jun 14 21:02:27 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:02
vishycan we do nova first today?21:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:02
ttxvishy: if you convince notmyname, yes.21:02
ttxAgenda for today:21:02
ttx#link http://wiki.openstack.org/Meetings/TeamMeeting21:02
* notmyname defers to vishy21:02
ttx#topic Actions from previous meeting21: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 PPA21:03
devcamcarsebastiansadil: sure21:03
vishynotmyname: thx.  I'm hoping to get some more sleep :)21:03
sandywalsheday, makes sense21:03
ttxThat's done. PPAs for common OpenStack releases are now under https://launchpad.net/~openstack-release21:03
*** bcwaldon has joined #openstack-meeting21:03
ttxYou can see a map of the available PPAs at: http://wiki.openstack.org/PPAs21:03
ttx* ttx to consider untargeting/retrotarget Low specs to decrease noise21:03
*** bcwaldon has left #openstack-meeting21:03
ttxNot done, been busy sanitizing diablo-2 plans last week, postponing21:03
ttx#action ttx to consider untargeting/retrotarget Low specs to decrease noise21:04
*** dolphm has quit IRC21:04
ttx#topic Nova status21:04
*** openstack changes topic to "Nova status"21:04
ttxvishy: I worked last week to make sure diablo-2 specs were assigned to someone or postponed21:04
ttx#link https://launchpad.net/nova/+milestone/diablo-221:04
ttxI still have a few targeted specs without confirmation:21:04
*** bcwaldon has joined #openstack-meeting21: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
ttxYou just told me about the two you have21:05
ttxI suspect we should defer extra-data, couldn't get hold of Justin21:05
vishyyes, sounds good21:06
ttx#action ttx to defer extra-data to diablo-321:06
ttx#action vishy to get integrate-nova-authn status from anotherjesse21:06
ttxI also have two related ones without assignee:21:06
ttx* https://blueprints.launchpad.net/nova/+spec/configuration-drive21:06
*** bcwaldon has quit IRC21:06
ttx* https://blueprints.launchpad.net/nova/+spec/instance-transport21:06
*** anotherjesse1 has quit IRC21:06
ttxAnyone interested in them ?21:07
ttxShould we defer them to diablo-3 already ?21:07
*** bcwaldon has joined #openstack-meeting21:07
*** jesse_ has joined #openstack-meeting21:07
vishy0x44 was working on prototyping configuration-drive21:08
vishydon't know what happened to it though...21:08
vishyprobably makes sense to defer if we have no one actively working on them21:08
*** Vek has joined #openstack-meeting21:08
ttxvishy: yes21:08
ttxI'll send out an email asking for candidates, worked well last time21:08
ttx#action ttx to defer configuration-drive and instance-transport21:09
ttxPeople still need to come back to me on openstack-api-floating-ips (reldan) and the testing-* ones (mtaylor)21:09
ttxThe rest if pretty firm.21:09
ttxQuick status update on the essential stuff:21:09
ttx* https://blueprints.launchpad.net/nova/+spec/no-db-messaging (vishy)21:09
_0x44vishy: I have code up on github for it, I showed anotherjesse yesterday.21:10
vishyoh there ya go, perhaps we should assign the config drive blueprint to _0x44 then21:10
ttx_0x44: would that work for you ?21:10
vishyno-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 it21:11
ttx#action ttx to assign _0x44 to configuration-drive21:11
ttx* https://blueprints.launchpad.net/nova/+spec/nova-multi-nic (tr3buchet)21:11
vishythe main issue is solving that "problem "is creating some other ones21:12
ttxtr3buchet: any news ?21:12
ttx* https://blueprints.launchpad.net/nova/+spec/distributed-scheduler (sandywalsh)21:12
ttxsandywalsh: looks on track ?21:12
tr3buchetsorry, looked away21:13
tr3bucheti'm getting the tests running now21:13
tr3buchetphysical test after then merge21:13
sandywalshttx, merging as we speak21:13
ttxtr3buchet, sandywalsh: cool, so still on track for diablo-2 delivery.21:13
tr3buchetttx: yes21:13
ttx* https://blueprints.launchpad.net/nova/+spec/nova-instance-referencing (dabo)21:13
sandywalshttx yes21:13
ttxdabo: looking good ?21:13
dabocode is working, but broke lots of unit tests21:14
sandywalshttx, merge succeeded21:14
dabowe're fixing them now; should be on-track21:14
ttxdabo: thanks !21:14
ttxvishy: anything else you wanted to mention ?21:14
vishydabo: are you doing volumes too?21:14
vishyor just instances?21:14
dabothis pass is just instances21:14
vishyok cool21:14
dabovolumes will need to be done, too21:14
vishyand are you doing ec2 mapping layer?21:15
dabosame as with scheduler - only instances work for now21:15
ttxdabo: needs to be done as in "sometime in diablo" ? Or "someday" ?21:15
dabovishy: no, we're re-defining the ec2_id to be 'i-' + first 8 chars of UUID21:15
dabottx: as in 'next'21:15
ttxdabo: as part of the same blueprint, or another one ? Want to make sure we track that21:16
vishydabo: hmm ok.  That seems reasonable for the first pass I suppose21:16
dabovishy: mapping layer would require shared db across zones21:16
vishydabo: it is going to be annoying for existing deployments...21:16
dabottx: a new bp, since the original was instance-specific21:16
ttxdabo: ok, feel free to file and ping me to include21:16
ttx(or vishy)21:17
dabovishy: yeah, I was thinking of how to convert when the uuid column is generated in the instances table21:17
vishydabo: we can discuss offline21:17
ttxOther Nova questions ?21:17
ttxok then, next topic21:18
ttx#topic Swift status21:18
*** openstack changes topic to "Swift status"21:18
ttxnotmyname: could you announce your plans for 1.4.1 and 1.4.2 ?21:18
notmynameall kinds of stuff21:18
notmyname1.4.1 is coming sooner than we all expected. It is scheduled for next week21:19
notmyname1.4.2 won't be until mid-july at the earliest21:19
jaypipesnotmyname: what is in 1.4.1?21:19
notmynamechangelog for 1.4.1 is http://bazaar.launchpad.net/~hudson-openstack/swift/trunk/view/head:/CHANGELOG21:19
ttxSo we should have a QA branch ready tomorrow, where potential release-critical bugfixes will be applied21:19
notmynamebig things are swuath removed and renamed st21:20
ttxRelease scheduled for Monday.21:20
ttxnotmyname: Other announcements or comments ?21:20
sorenWhat will be in 1.4.2?21:20
notmyname1.4.2 should have container sync21:21
*** glange has joined #openstack-meeting21:21
notmynamechange post to copy21:21
*** glenc has quit IRC21:21
notmynameand removing stats/logging21:21
sorenWhere is that going?21:22
soren(stats/logging, that is)21:22
notmynameinto a separate project (like swauth did)21:22
*** glenc has joined #openstack-meeting21:22
ttxOther Swift questions / announcements ?21:22
*** johnpur has quit IRC21:23
ttx#topic Glance status21:23
*** openstack changes topic to "Glance status"21:23
ttxjaypipes: Hi!21:23
ttxTwo weeks away from delivery21:23
ttxLooking at that URL I'd say you're a bit behind ?21:24
jaypipesttx: 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
jaypipesttx: yes. still on track for the 2 High BPs. Some of the Low priority ones may slip, but not too concerned.21:24
ttxjaypipes: Other announcements, comments ?21:25
jaypipesI *really* want to get the S3 bug out of the way... so I need some reviews from dprince, bcwaldon and others...21:25
jaypipesttx: nothing more from me21:25
ttxjaypipes: link to review needed ?21:25
jaypipesttx: https://code.launchpad.net/~jaypipes/glance/bug713154/+merge/5911021:26
*** dendrobates is now known as dendro-afk21:26
ttx#action glance-core to review in priority https://code.launchpad.net/~jaypipes/glance/bug713154/+merge/5911021:26
ttxif there is nothing else on Glance, let's go to our favorite topic21:27
ttx#topic Naming of E21:27
*** openstack changes topic to "Naming of E"21:27
ttxI came up with a list of candidates at: http://wiki.openstack.org/ReleaseNaming21:27
ttxPersonally I like "Exeter" :)21:27
creihthow about Effing?21:28
ttxIf you have other candidate names (that follow the rules described on the page), please edit the wiki21:28
jaypipescreiht: lol. ++21:28
ttxcreiht: does that even exist ?21:28
*** mldennis has left #openstack-meeting21:28
ameadeEgleston square is in the center of Boston21:28
ttxcreiht: if you can make that a city or county near Boston, I'll take it21:28
creihtthere is an Effingham, Illinois21:28
markwashcreiht: that's an effing good ham21:29
*** bcwaldon has quit IRC21:29
ttxDo that soon because I'll throw a Launchpad poll (probably tomorrow) to pick the final name21:29
*** ohnoimdead has quit IRC21:29
ttxThe Launchpad ~openstack group will be able to vote and it will last a week21:30
*** ameade has quit IRC21:30
ttxComments ?21:31
* ttx wonders if the Internet dropped. This discussion usually triggers comment frenzy.21:32
*** salv-orlando has joined #openstack-meeting21:32
* Vek shrugs21:32
heckjstill here - just nothin' useful to add21:32
ttx#topic Open discussion21:32
*** openstack changes topic to "Open discussion"21:32
* Vek will simply throw a dart at the list for the vote21:33
ttxheckj: it doesn't have to be useful.21:33
heckjttx: trying to be a little useful.21:33
heckjI rather like Exeter, but the poll will take care of it one way or another..21:33
ttxWow. Having vishy in Japan sounds like a good way to finish meetings early.21:34
heckjgeneral question - is the packaging under the CI work?21:34
heckj(i.e. making deb's, rpm's etc)21:34
ttxheckj: it's completely integrated in Jenkins, if that's what you're asking21:34
heckjIts a tad inconsistent between the various official and side projects today.21:34
ttx(the deb's thing)21:35
*** jesse_ has quit IRC21:35
heckjmonty has is set up to build RPM's as well? I knew deb's and PPA's21:35
mtaylorno. but he wants to21:35
mtaylorthat's on my todo21:35
heckjmtaylor - sweet.21:35
ttxmtaylor: hooking OpenSuse build service ?21:35
mtaylorttx: implementation as yet undecided21:35
ttxmtaylor: that's a long todo list.21:35
mtaylorI'm not a fan of the interface method for the OpenSuse build service - but it's not off the table21:36
* heckj is installing most of the pieces from source control21:36
heckjbut I'm going to switch to using Chef shortly and the official PPAs we're creating through Jenkins21:36
ttxanything else before we close this meeting ?21:37
mtaylorheckj: 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 ... lacking21:38
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"21:38
openstackMeeting ended Tue Jun 14 21:38:27 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:38
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-21.02.html21:38
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-21.02.txt21:38
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-21.02.log.html21:38
ttxthanks everyone21:38
mtaylorheckj: 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-meeting21:39
heckjmtaylor: happy to spam you with details, or otherwise shove them into a public wiki21:39
mtaylorheckj: either would be stellar21:39
mtaylorheckj: (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-meeting21:40
heckjmtaylor: i definitely know what you mean - tends to make one a bit "stabby" sometimes21:40
*** nati has quit IRC21:40
*** masumotok has quit IRC21:41
*** creiht has left #openstack-meeting21:42
*** danwent has joined #openstack-meeting21:47
*** zns has quit IRC21:49
*** troytoman-away is now known as troytoman21:53
*** vladimir3p has quit IRC21:53
*** jlm^ has joined #openstack-meeting21:55
*** zns has joined #openstack-meeting21:55
*** ryu_ishimoto has joined #openstack-meeting21:57
danwenthello netstack folks22:00
danwenttough crowd :)22:00
danwentFYI: dendrobates is out today22:01
salv-orlandoit does not look like a busy meeting, does it?22:01
salv-orlandook, so it me, Dan, and?22:01
bhallI'm here22:01
openstackMeeting started Tue Jun 14 22:02:08 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.22:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.22:02
ryu_ishimotoi'm here22:02
danwentanyone 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-meeting22:02
bmcconnetroy will likely turn back to his monitor at some point :)22:03
danwent#topic project status22: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 project22:03
*** SumitNaiksatam has joined #openstack-meeting22:03
*** ecarlin has joined #openstack-meeting22:04
danwentI 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 code22:04
*** eperdomo has joined #openstack-meeting22:04
danwentif you have branches or bugs that are quantum specific, please move them to quantum.22:04
danwentI 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
bmcconnejust got his attention22:05
*** Jamey has joined #openstack-meeting22:05
danwentok, we'll come back to that.22:06
*** romain_lenglet has joined #openstack-meeting22:06
danwent#topic quantum update22:06
*** openstack changes topic to "quantum update"22:06
danwentwe're continuing to do testing and bug finding on quantum.22:07
troytomanjust caught up. we are working on a plan to have melange live within the Nova project. it looks like we can make that work22:07
danwenttroytoman: great, thanks.  so eventually the branches in network-service will go away? (no rush)22:07
troytomanyes. 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
troytomanthen it will move out of network service22:08
danwentk, great22:08
danwenton quantum: we're will have a plugin that works with KVM soon, though it may require a tweaked version of nova22:08
danwentwe're turning our focus more to how quantum will work with nova + melange.22:08
danwenton the topic of nova, ryu, can you provide an update on the nova refactoring?22:09
*** RamD has joined #openstack-meeting22:09
danwent(or anyone from midokura?)22:09
midodanhi there22:10
midodani'll try to kick Ryu awake22:10
danwentah, i thought I saw him join just a bit ago22:10
ryu_ishimotoyup i'm here, sorry22:10
jlm^He is on channel.22:10
danwentryu, can you give a quick update?22:10
danwentparticularly 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_ishimotosure, that's also where we are struggling a bit with22:11
ryu_ishimotoVIsh is here this week in Japan and we have been discussing how we should implmeent that part22:11
SumitNaiksatamis this discussion being captured/documented somewhere?22:12
danwentOk.  would be great to see a BP, so we can provide feedback.22:12
*** dragondm has quit IRC22:12
midodanyes, 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
danwentGreat, thanks.  There's a lot of interest particularly around the flexibility of generating <interface> config for libvirt...22:13
SumitNaiksatammuch appreciated...as with everything else, sooner would be better :-)22:13
*** JordanRi1ke is now known as JordanRinke22:13
danwentOk, anything else on quantum?22:13
SumitNaiksatamat least at a high level as to where the discussion is heading...22:13
midodandanwent: you mentioned that there would soon be a version running with KVM22:14
*** mrmartin has quit IRC22:14
midodanhow will that work?  with libvirt?  do you have a doc describing it?22:14
danwentmidodan: 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
midodanright right, that's the part i was wondering about, the ovs plugin22:15
danwentThis will require changes to nova in the vif-plugging area, which is what we were asking about.22:15
midodanok, we should have a discussion offline, perhaps later today, to sync up22:15
danwentCode will be up.  At a high-level, its just using type="ethernet" instead of type="bridge" and making a couple ovs commands for setup/teardown22:15
danwentIts just a hack now, to demonstrate the flexibility we would need from the nova refactoring of libvirt.22:16
ryu_ishimotodanwent: right, that's how we implemented in our branch22:16
danwentand to let people play with quantum with a single server KVM setup.22:16
danwentryu: yes, exactly22:16
midodanok, sounds good, thanks.22:16
ryu_ishimotodanwent: ok let's keep the discussion going offline then.22:16
danwentryu: when you mention a branch, are you referring to the original branch discussed at the summit?22:17
ryu_ishimotodanwent: no, the new branch, the one that's less disruptive22:17
ryu_ishimotodanwent:  lp:~/midokura/nova/network-refactoring22:17
danwentryu: great, thanks.22:17
danwentok, anything else on quantum?22:18
ryu_ishimotobut the old branch does the same thing in regards to libvirt interfaces22:18
*** adjohn has joined #openstack-meeting22:18
RamDkvm related is of our interest too.22:18
salv-orlandoon quantum API: I have implemented the changes proposed in last week's email22:18
danwentRamD: 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-meeting22:19
danwentsalv: can you quickly describe them?22:19
salv-orlando1) removing orchestration operation for PUT attachment22:19
danwentah, yes.  now I remember.  thanks.22:19
salv-orlando2) using detail action for retrieving list of resources attached to network22:19
danwentOk, does anyone want to give an update on melange or donabe?22:20
salv-orlandochanges are in a branch I'm using to fix a couple of bugs I spotted as well. Will propose for merge into trunk ASAP22:20
danwentsalv: awesome, great.22:20
salv-orlandobefore moving to other projects, did we reach a consensus on the semantics of the attach operation?22:21
salv-orlandoI remember it was discussed two weeks ago, but I don't know whether we decided something22:21
danwentI 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-orlandoSumit (if I'm not wrong) was proposing to remove the operation as it was beyond the scope of the quantum service22:22
*** edconzel has quit IRC22:22
salv-orlandobasically If I remember it correctly, it was responsibility of the compute node to "plug the cable"22:23
SumitNaiksatamSalv: not I wasn't22:23
danwentah, i think the distinction here is a "logical plug" vs. the "hypervisor plug".22:23
danwentI think we're clear on that now.22:23
SumitNaiksatamYeah, I guess based on the discussion we had the other day22:24
danwentYup, we'll need to focus on the vif-plugging work in nova for that.22:24
salv-orlandosweet, just wanted to make sure of that22:24
danwentsalv: yes, thanks for bringing it up.22:24
danwent#topic: open discussion22:24
*** openstack changes topic to ": open discussion"22:24
danwentspeak now or hold you peace until next week :)22:25
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"22:25
troytomanjust for reference, the multinic branch should merge prop in the next day or so22:25
openstackMeeting ended Tue Jun 14 22:25:46 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:25
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-22.02.html22:25
salv-orlando I have a question for Melange people...22:25
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-22.02.txt22:25
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-22.02.log.html22:25
troytomani know several are waiting on that.22:25
somik bye all!22:25
danwenttroy: great news, thanks.22:26
danwentsalv: please ask your question.22:26
midodanhey danwent can we chat about the libvirt stuff briefly?22:26
danwentmidodan: sure22:26
troytomansalv-orlando: I'm available for a melange questions22:26
salv-orlandoIn old nova days we used to inject network info in flat mode. Will this still be possible with melange22:26
danwentmidodan: want to chat now or via email?22:27
midodandanwent: now is good, i just type slow22:27
troytomanyes. we are still planning to enable injection so we plan to integrate it in that way22:27
troytomansalv-orlando: ^22:27
midodandanwent: 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-orlandotroytoman: are we planning to use agents as we do for xenapi today?22:28
danwentmidodan: 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
troytomanyes. that is the rackspace use case.22:28
troytomanwe are exploring some other options such as a metadata service or a pluggable usb drive. but, those would be out in the future22:29
danwentmidodan: 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
midodanok, ic22:29
troytomanour 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 up22:30
midodandanwent: 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
midodanmidodan: 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
midodanoops, talking to myself :)22:31
danwentno, i'm here :)22:31
danwentah, i get it :)22:31
danwenttoo many dans22:31
salv-orlandotroytoman: will there be an "official melange agent" or will we allow openstack deployers to bring their own agents?22:31
midodanfor real, i'm getting confused22:31
midodandanwent: so, in case of using interface type direct, maybe that model doesn't work22:31
danwentmidodan: he may be talking about the cisco use case.22:31
danwentmidodan: yes22:32
midodandanwent: what are your thoughts about that?22:32
midodandanwent: open ended question, i know22:32
danwentmidodan: I tend to think of it as nova + libvirt having a couple different ways it can do vif-plugging22:32
troytomanwe 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
danwentmidodan: "nova agent", you mean the "compute service" that invokes libvirt?22:33
troytomannova will handle the communication with Melange - not the agent directly22:33
midodandanwent: right, that's what i'm talking about.22:33
salv-orlandotroytoman: 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
danwentmidodan: 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
troytomansalv-orlando: the format of the xenstore messages would remain the same. please send along your questions.22:34
danwentand communicate the "interface binding" to quantum (or equivalent)22:34
midodandanwent: 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
danwentmidodan: I wouldn't want to always assume that.22:35
danwentmidodan: 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
danwentmidodan: sometimes this discussion is hard because we all have slightly different definitions :)22:35
midodanmidodan: don't get me started.  everytime we talk about "ports", it's confusing as hell. :)22:36
danwentmidodan: :)22:36
midodandanwent: oops, again, talking to self22:36
midodandanwent: need more coffee22:36
midodandanwent: ok, so, in the example you mentioned,22:36
midodanthe Nova side and the Quantum side know that they're using OVS, and they agree about the particular bridge they're using.22:37
danwentmidodan: yes, that's definitely one model22:37
danwentmidodan: essentially, the quantum plugin and nova need to share a "contract"22:38
midodandanwent: so we have a use case where we use a bridge per tenant22:38
danwentmidodan: they have to agree where they meet22:38
midodandanwent: that sounds reasonable. so how to agree on that.22:39
SumitNaiksatamdan/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
danwentmidodan: 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 connectivity22:39
midodanSumitNaiksatam: sure, we'll write something up on an etherpad or wiki.22:39
danwentSumit: this is part of what I'm trying to write-up22:39
SumitNaiksatamok great22:39
SumitNaiksatamthat way we can provide suggestions22:40
danwentsumit: Rick and I have been talking about a "Quantum design" document.22:40
danwentmidodan: I think the key thing is that there does not need to be a single contract that works for all Quantum plugins22:40
danwentmidodan: in fact, with SR-IOV vs. bridge vs. OVS the plugging (just the the libvirt XML) will be a bit different.22:41
midodandanwent: but in that case, there might be code that needs plugging into Nova as well22:41
danwentmidodan: can you clarify?22:41
midodandanwent: meaning that depending on the 'contract' the Nova (compute service) side might have to do things a bit differently as well.22:42
midodandanwent: for example,22:42
midodanin one case Nova might create the tap interface and add it to an agreed upon bridge, and then set some id, and that's it22:42
danwentbut I think that is already true with respect to how the libvirt xml is crafted, right?22:42
danwentI see this as a "vif-plugging-type=" flag for libvirt deployments.22:42
midodanmaybe, but it adds more coordination complexity22:43
danwentnot the most elegant approach, but seems pretty straightforward.22:43
midodanok, so can we enumerate the high level ways to do this22:43
midodan1) tap into bridge, one bridge for all VMs22:43
midodan2) tap into bridge, bridge per tenant22:43
midodan3) SR-IOV virtual PCI device (who manages virtual device lifecycle, Nova or Quantum?)22:44
danwentquick question: are you just focusing on libvirt?22:44
midodanno no, general question22:44
midodan4) 'direct' interface, a la 802.1Qbg22:45
danwentthen i think this gets a lot more complicated22:45
salv-orlandomidodan: on case 3 do we still have a VEB?22:45
danwentwith libvirt direct, I do not think so22:45
midodansalv-orlando: maybe the bridge is implemented on the NIC22:45
midodani mean, in case 322:45
danwentthough in theory you could use a SR-IOV device with a bridge22:46
salv-orlandomidodan: that makes sense. so VFs are bridge ports and the PF is the uplink22:46
midodansalv-orlando: sure22:46
danwentsalv: essentially, yes, that is how I think about it22:46
*** RamD has quit IRC22:46
midodanand dan is right, that SR-IOV could be used with a real bridge as well22:46
salv-orlandomidodan: instead about case 4, I have the impression in that case nova should not do anything about networking22:47
salv-orlandoas the interface would be plugged by the nearest edge physical switch22:47
midodansalv-orlando: i understand, but isn't Nova still concerned about the VIF id?22:47
midodanand whatever vport id that is plugged into?22:47
danwentmidodan: agreed.22:47
danwentnova must ultimately pass XML to libvirt and communicate an "interface binding"22:48
midodani'm actually not familiar with the 'direct' stuff in libvirt22:48
midodanwhat is the format with of the edge binding info?22:48
midodan<virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport>22:49
danwentmidodan: 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
midodanso 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
danwentthat is for VEPA22:50
SumitNaiksatamdont forget Qbh :-)22:50
danwentits slightly different for VN-link.22:50
danwentyes :)22:50
SumitNaiksatamthat format is slightly different22:50
SumitNaiksatamdan: thanks :-)22:50
danwentmidodan: yes, for VEPA is seems like libvirt takes care of communicating that to the switch22:50
danwent(I haven't use it myself though...)22:51
midodanok, good to know22:51
*** ecarlin has quit IRC22:51
midodanlooks like i got more self education to do22:51
salv-orlandoSumit: we'll say EVB, so you both guys will be happy :-)22:51
danwentmidodan: 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
danwentas we have no idea what might come down the pipe next, that again, is slightly different :)22:51
midodandanwent: ok, i'm getting the picture22:51
*** markvoelker has quit IRC22:52
danwentLet's make sure the nova refactoring blueprint has a seciton on this22:52
midodandanwent: even focusing mostly on software virtual bridge case, like using OVS, i still have something that needs clarification22:52
danwentand we can continue this discussion there.22:52
danwentmidodan: ok22:52
midodanyeah, good point22:52
danwentmidodan: did you have something you wanted to ask?22:53
midodandanwent: i type slow22:53
danwentI type badly22:53
midodandanwent: 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
midodanthat's one case22:53
danwentmidodan: 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
midodandanwent: yes, that's about right.22:54
danwentin this case, the quantum plugin would seem to need an agent.22:55
danwentand there would have to be some way to communicate the "interface binding" of <iface-id, linux-dev, hypervisor-id> to quantum22:55
danwentwhere iface-id is the logical iface-id, and the linux-dev + hypervisor-id indicate the current binding for that interface22:55
midodanok, starting to get the picature22:56
midodanwhy does hypervisor-id need to be in there btw?22:56
danwentif you have multiple hypervisors, the linux-dev name (e.g., tap0) is not unique globally22:56
midodanoh, ha, ok22:57
danwentso if the quantum plugin was managing several vswitches on different hypervisors, I think you would need to make a distinction22:57
midodanwe've pretty much been using only kvm22:57
midodanso hadn't run into that22:57
danwentsorry, can you clarify?22:57
midodanah, wait, i'm sorry, i totally misunderstood22:58
midodanof course, the tap0 is unique only per host22:58
midodanso you mean, hypervisor-id, is the host22:58
SumitNaiksatamguys, this is a good point22:58
SumitNaiksatami wanted to ask this22:58
danwentyes, sorry22:58
midodanmy bad, thanks22:58
danwentOk, I actually need to run for a 4pm meeting.22:59
SumitNaiksatamhow does quantum know on which host the VM is being spawned?22:59
danwentLet's make sure that we get a section on the current refactoring blueprint on this.22:59
midodanok, let's pick this up later, offline22:59
SumitNaiksatamok carry over the discussion22:59
salv-orlandolet's try and start an email thread22:59
danwentSumit:  when it gets the "interface binding", this will be included, if this info is needed.22:59
SumitNaiksatamok, will wait for the BP :-), guess that will make it clear23:00
midodanSumitNaiksatam: wishful thinking ;)23:00
SumitNaiksatamemail thread is fine too, good idea salv23:00
danwentor etherpad?23:00
danwentlink to the BP?  got to run.  thanks guys.23:00
salv-orlandoI hate that etherpad does not notfy me when someone updates it23:00
*** danwent has left #openstack-meeting23:00
salv-orlandook, dan has gone...23:01
SumitNaiksatamsalv: +123:01
salv-orlandomidodan, Sumit: email or etherpad?23:01
SumitNaiksatamsalv: prefer emails23:01
midodani'm fine either way23:01
SumitNaiksatambut either way fine23:01
SumitNaiksatamshall i start an email thread?23:02
salv-orlandoSumit: sure go ahead23:02
midodango for it23:02
SumitNaiksatamok will send23:02
SumitNaiksatamthanks guys!23:02
salv-orlandoI will be glad to throw my $0.02 at it!23:02
salv-orlandobye, have a good night/evening/afternoon/morning23:03
SumitNaiksatamcatch you on the email thread, bye!23:03
*** midodan has left #openstack-meeting23:03
*** jlm^ has left #openstack-meeting23:03
*** salv-orlando has quit IRC23:03
*** eperdomo has quit IRC23:03
*** romain_lenglet has left #openstack-meeting23:08
*** Jamey has quit IRC23:13
*** Jamey has joined #openstack-meeting23:20
*** ryu_ishimoto has quit IRC23:22
*** SumitNaiksatam has quit IRC23:35
*** troytoman is now known as troytoman-away23:43
*** adjohn has quit IRC23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!