| *** carlp has joined #openstack-meeting | 00:09 | |
| *** adjohn has joined #openstack-meeting | 00:38 | |
| *** dragondm has quit IRC | 00:51 | |
| *** Binbin has joined #openstack-meeting | 00:56 | |
| *** mattray has joined #openstack-meeting | 01:15 | |
| *** pvo has quit IRC | 02:33 | |
| *** mattray has quit IRC | 03:54 | |
| *** murkk has quit IRC | 04:11 | |
| *** anotherj1sse has quit IRC | 04:39 | |
| *** adjohn has quit IRC | 09:10 | |
| *** Binbin is now known as Binbingone | 10:19 | |
| *** mancdaz has quit IRC | 11:04 | |
| *** mancdaz has joined #openstack-meeting | 11:05 | |
| *** mancdaz has quit IRC | 11:07 | |
| *** mancdaz has joined #openstack-meeting | 11:09 | |
| *** dprince has joined #openstack-meeting | 12:52 | |
| *** dendro-afk is now known as dendrobates | 13:28 | |
| *** edconzel has joined #openstack-meeting | 13:42 | |
| *** mattray has joined #openstack-meeting | 13:46 | |
| *** edconzel has quit IRC | 13:47 | |
| *** edconzel has joined #openstack-meeting | 13:47 | |
| *** pvoccio_ has joined #openstack-meeting | 14:08 | |
| *** johnpur has joined #openstack-meeting | 14:15 | |
| *** jkoelker has joined #openstack-meeting | 14:25 | |
| *** dragondm has joined #openstack-meeting | 14:50 | |
| *** pvoccio_ is now known as pvo | 15:08 | |
| *** pvo has quit IRC | 15:15 | |
| *** pvo has joined #openstack-meeting | 15:15 | |
| *** mancdaz has quit IRC | 16:11 | |
| *** mancdaz has joined #openstack-meeting | 16:13 | |
| *** mancdaz has quit IRC | 16:15 | |
| *** mattray1 has joined #openstack-meeting | 16:17 | |
| *** mattray has quit IRC | 16:18 | |
| *** anotherj1sse has joined #openstack-meeting | 16:24 | |
| *** hub_cap has joined #openstack-meeting | 16:32 | |
| *** dendrobates is now known as dendro-afk | 16:35 | |
| *** dendro-afk is now known as dendrobates | 17:25 | |
| *** littleidea has joined #openstack-meeting | 17:47 | |
| *** hub-cap has joined #openstack-meeting | 18:07 | |
| *** hub-cap has quit IRC | 18:08 | |
| *** markwash has quit IRC | 18:09 | |
| *** hub_cap has quit IRC | 18:10 | |
| *** creiht has joined #openstack-meeting | 18:11 | |
| *** markwash has joined #openstack-meeting | 18:16 | |
| *** BinaryBlob has joined #openstack-meeting | 18:32 | |
| *** colinnich has joined #openstack-meeting | 19:02 | |
| *** littleidea has quit IRC | 19:21 | |
| *** eperdomo has joined #openstack-meeting | 19:58 | |
| *** dprince has quit IRC | 19:58 | |
| *** RamD has joined #openstack-meeting | 20:00 | |
| *** RamD has left #openstack-meeting | 20:02 | |
| *** troytoman-away is now known as troytoman | 20:03 | |
| *** bhall has joined #openstack-meeting | 20:04 | |
| *** troytoman has quit IRC | 20:24 | |
| *** troytoman-away has joined #openstack-meeting | 20:25 | |
| *** troytoman-away is now known as troytoman | 20:25 | |
| *** AlexNeef has joined #openstack-meeting | 20:30 | |
| *** jamesurquhart has joined #openstack-meeting | 20:31 | |
| *** alandman has joined #openstack-meeting | 20:35 | |
| *** danwent has joined #openstack-meeting | 20:35 | |
| *** salv-orlando has joined #openstack-meeting | 20:36 | |
| *** dabo has joined #openstack-meeting | 20:37 | |
| *** bcwaldon has joined #openstack-meeting | 20:41 | |
| *** masumotok has joined #openstack-meeting | 20:46 | |
| *** primeministerp has joined #openstack-meeting | 20:52 | |
| primeministerp | greetings programs | 20:53 |
|---|---|---|
| *** masumotok has quit IRC | 20:53 | |
| *** dtroyer_ has joined #openstack-meeting | 20:53 | |
| *** summer has joined #openstack-meeting | 20:55 | |
| *** jwilmes has joined #openstack-meeting | 20:55 | |
| *** spectorclan_ has joined #openstack-meeting | 20:55 | |
| *** ying has joined #openstack-meeting | 20:58 | |
| *** primeministerp has quit IRC | 20:58 | |
| *** ameade has joined #openstack-meeting | 20:59 | |
| ttx | \o | 21:00 |
| * creiht bows | 21:00 | |
| * dabo waves to ttx | 21:00 | |
| * _0x44 | 21:00 | |
| *** User has joined #openstack-meeting | 21:00 | |
| *** User has joined #openstack-meeting | 21:00 | |
| vishy | o/ | 21:00 |
| *** User has quit IRC | 21:00 | |
| spectorclan_ | hola | 21:01 |
| * soren says hello | 21:01 | |
| *** Tushar has joined #openstack-meeting | 21:01 | |
| *** jaypipes has joined #openstack-meeting | 21:01 | |
| notmyname | hi | 21:01 |
| johnpur | hi Jay! | 21:01 |
| jaypipes | johnpur: hey :) | 21:01 |
| ttx | ok, all PTLs are here, let's start then | 21:01 |
| ttx | #startmeeting | 21:01 |
| openstack | Meeting started Tue May 24 21:01:37 2011 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 21:01 |
| ttx | Welcome to our weekly OpenStack meeting... | 21:01 |
| ttx | Today's agenda lives at: | 21:01 |
| ttx | #link http://wiki.openstack.org/Meetings | 21:01 |
| ttx | #topic Actions from previous meeting | 21:02 |
| *** openstack changes topic to "Actions from previous meeting" | 21:02 | |
| ttx | * jaypipes to confirm the nobottle unblocking | 21:02 |
| ttx | jaypipes: nothing like getting actions assigned to you while you're not here :) | 21:02 |
| jaypipes | ttx: heh | 21:02 |
| jaypipes | ttx: sorry, have not checked that one. | 21:02 |
| *** Sumit has joined #openstack-meeting | 21:03 | |
| ttx | jaypipes: ok, just wanted to make sure that was unblocked, please reraise it if it's not | 21:03 |
| ttx | * ttx to crosspost assignee search to ML: done | 21:03 |
| jaypipes | ttx: I'll check into it. | 21:03 |
| ttx | * soren to raise a thread on the python-openstack.compute jacobian situation | 21:03 |
| ttx | This was done, but the thread died... | 21:03 |
| soren | Oh, did I? | 21:03 |
| soren | Oh, right, I did! | 21:03 |
| ttx | I think the conclusion was, since the current client needs to evolve in parallel to exhibit new Nova features... | 21:04 |
| soren | phew | 21:04 |
| *** sirp__ has joined #openstack-meeting | 21:04 | |
| ttx | ...it's difficult to have it live outside our direct and timely control | 21:04 |
| ttx | That said it still sucks to have two nearly-identical confusing projects. | 21:04 |
| ttx | Could the two projects be merged and both sides be committers ? | 21:04 |
| mtaylor | ++ - and just add support for new features to the library before they are added to the server code | 21:05 |
| ttx | Who knows Jacobian better and could help in bridging the gap ? | 21:05 |
| dabo | I think they should be separated. The jacobian part would work with the public API only, and we would maintain a separate library for inter-zone communication | 21:05 |
| dabo | I know Jacob, and could talk with him | 21:05 |
| ttx | dabo: we still need to make quick updates to the client to exhibit new features | 21:06 |
| dabo | ttx: true, but that could be something we coordinate with the jacobian version. | 21:06 |
| dabo | I don't think he would object to having the utility kept up-to-date | 21:07 |
| ttx | dabo: could you take the action of starting to bridge the gap ? | 21:07 |
| dabo | Sure. | 21:07 |
| *** RamD has joined #openstack-meeting | 21:07 | |
| ttx | #action dabo to bridge the gap with jacobian and work towards a common client | 21:08 |
| *** carlp has quit IRC | 21:08 | |
| ttx | ok, moving on | 21:08 |
| ttx | #topic General release status | 21:08 |
| *** openstack changes topic to "General release status" | 21:08 | |
| ttx | The release status page is now milestone-oriented, represents our always-evolving plan of record: | 21:08 |
| ttx | #link http://wiki.openstack.org/releasestatus/ | 21:08 |
| ttx | If you have any remark or correction, please talk to me or corresponding PTL. | 21:08 |
| ttx | I also created a few webnumbrs for Nova, to track open bugs, untriaged bugs and bugfixes committed: | 21:09 |
| ttx | #link http://wiki.openstack.org/releasestatus/nova.html | 21:09 |
| ttx | Should get more interesting with a bit more data collected. | 21:09 |
| vishy | ttx: nice! | 21:09 |
| ttx | Questions before we move to per-project status ? | 21:09 |
| johnpur | ttx: can we get standardized reports for all the projects? | 21:10 |
| ttx | johnpur: we could. It was more pressing for nova, given the recent bug inflation that I'm trying to flight | 21:10 |
| ttx | fight, even | 21:10 |
| johnpur | agree on the priority | 21:11 |
| ttx | but I can have the same webnumbr set up for the others, sure | 21:11 |
| johnpur | thx | 21:11 |
| ttx | #action ttx to create webnumbrs for all core projects | 21:11 |
| ttx | #topic Nova status | 21:11 |
| *** openstack changes topic to "Nova status" | 21:11 | |
| ttx | The first milestone is diablo-1, scheduled for Thursday, June 2nd. | 21:11 |
| ttx | The plan is to cut a milestone release branch early Wednesday morning, which means that diablo-1 features should get in before Tuesday EOD. | 21:11 |
| ttx | Looking at the milestone status it appears we are still quite far from the objective: | 21:12 |
| ttx | https://launchpad.net/nova/+milestone/diablo-1 | 21:12 |
| *** carlp has joined #openstack-meeting | 21:12 | |
| ttx | The only feature that was proposed for merging so far is snapshot-volume, but it is missing reviews... | 21:12 |
| ttx | So please give some love to: https://code.launchpad.net/~morita-kazutaka/nova/snapshot-volume/+merge/61071 | 21:12 |
| ttx | i see Vish looked into it very recently :) | 21:13 |
| ttx | clone-volume is ready but needs snapshot-volume to land first. | 21:13 |
| vishy | yes... | 21:13 |
| ttx | xs-multi-nic, xs-ovs, administrative-vms, nova-virtual-storage-array, integrate-nova-authn and unittest-examples are all planned to be proposed very soon | 21:13 |
| ttx | reference-architectures is a design/documentation effort, should be completed it time | 21:13 |
| vishy | yes, tr3buchet says multinic won't make it | 21:14 |
| ttx | kvm-pause-suspend is blocked on legal issues, might still make it | 21:14 |
| vishy | but should be in early in diablo-2 | 21:14 |
| markwash | :-( | 21:14 |
| ttx | vishy: ok, please move milestone if you haven't already | 21:14 |
| vishy | i did | 21:14 |
| * ttx refreshes | 21:14 | |
| vishy | might be best that way, so we have time to fix the stuff that it breaks | 21:14 |
| ttx | vishy: makes sense indeed. | 21:15 |
| *** midodan has joined #openstack-meeting | 21:15 | |
| ttx | xtoddx: how is provider-firewall doing ? | 21:15 |
| vishy | i asked him to propose it asap so that we can all start helping | 21:15 |
| xtoddx | ttx, vishy: there is a patch to move libvirt into a directory | 21:15 |
| xtoddx | is that going to land first, or should mine? we're going to have to work around each other somehow | 21:15 |
| vishy | xtoddx: do you have a link? | 21:15 |
| vishy | just propose and we'll see who wins! :) | 21:16 |
| xtoddx | finding | 21:16 |
| blamar_ | xtoddx: Doesn't matter to me :) It's my change | 21:16 |
| *** somikbehera has joined #openstack-meeting | 21:16 | |
| blamar_ | https://code.launchpad.net/~rackspace-titan/nova/libvirt-firewall-breakout | 21:16 |
| ttx | propose early, propose often :) | 21:17 |
| vishy | blamar_: why hasn't that merged yet? | 21:17 |
| ttx | so yours is ready, or almost ready ? | 21:17 |
| ttx | xtoddx: ^ | 21:17 |
| vishy | blamar_: it is well past monday :) | 21:17 |
| blamar_ | vishy: I'd like to get a core member to approve that isn't on my team :) | 21:18 |
| vishy | o | 21:18 |
| markwash | lol | 21:18 |
| bcwaldon | but, jaypipes matters! | 21:18 |
| xtoddx | mine is ready, though i haven't merged trunk recently | 21:18 |
| jaypipes | :( | 21:18 |
| bcwaldon | jaypipes: you do, I swear! | 21:18 |
| jaypipes | lol | 21:18 |
| ttx | vishy: I'll probably tweak the scoring on http://wiki.openstack.org/reviewslist/ so that it prioritizes the features that are targeted to the next milestone | 21:19 |
| *** masumotok has joined #openstack-meeting | 21:19 | |
| xtoddx | i'll make sure mine is ready and propose, and we'll let the chips fall how they may | 21:19 |
| ttx | If anyone still uses that ;) | 21:19 |
| bcwaldon | ttx: I do! | 21:19 |
| xtoddx | ttx: link from http://wiki.openstack.org/Nova/ReviewDays | 21:19 |
| xtoddx | and i'll use it | 21:19 |
| ttx | bcwaldon: cool ! | 21:19 |
| ttx | xtoddx: good point | 21:19 |
| ttx | vishy: lots of stuff targeted to diablo-2 now | 21:19 |
| ttx | vishy: once diablo-1 is out we'll have an early look at diablo-2 and make sure the plan is doable (and people know what they are assigned to), and push back to diablo-3 what needs to be | 21:20 |
| vishy | ttx: yes, we will probably have to move some of the dependent stuff | 21:20 |
| ttx | Questions for the Nova PTL ? | 21:20 |
| jaypipes | vishy: hey, when is local image service going bye bye? | 21:20 |
| markwash | and when that happens, can we ditch the base class too? | 21:21 |
| vishy | blamar_: seems fine, I'm still annoyed by virt not using import_object but whatev | 21:21 |
| vishy | jaypipes: is it going away? | 21:21 |
| vishy | jaypipes: are we just going to default to glance? | 21:21 |
| jaypipes | vishy: well, Glance already has a local image service ;) | 21:21 |
| jaypipes | vishy: it's Filesystem backend... | 21:21 |
| blamar_ | vishy: lots of good changes for libvirt coming once I can get some code separation | 21:22 |
| xtoddx | i think the issue would be ec2 compatibilty layer only being half-way complete then | 21:22 |
| vishy | xtoddx: no it works fine with glance | 21:22 |
| jaypipes | vishy: and the filesystem backend is Glance's default storage, so switching from local to glance by default would essentially be the same as we have now (only requiring the dependency on glance I guess) | 21:22 |
| vishy | jaypipes: i'm just a little worried about having to configure glance to get it working, but as it is relatively easy I don't mind | 21:23 |
| jaypipes | vishy: no configuration besides the existin glance_host and glance_port. | 21:23 |
| vishy | jaypipes: it messes up venv install i think | 21:23 |
| ttx | soren: we need to track that, since Ubuntu will want to default on Glance too | 21:23 |
| jaypipes | vishy: ok, we can take it offline. sounds like something we can work towards at a low priority. | 21:23 |
| soren | *nod* | 21:23 |
| ttx | jaypipes, vishy: do we need/want a blueprint for that migration ? | 21:23 |
| vishy | jaypipes: cool | 21:23 |
| jaypipes | ttx: good idea, yes | 21:24 |
| ttx | could help for downstream to track when it lands | 21:24 |
| ttx | jaypipes: you create it ? | 21:24 |
| jaypipes | ttx: sure | 21:24 |
| jaypipes | #action jaypipes to create removal of local image service blueprint | 21:24 |
| markwash | vishy: the venv is for unit testing though, right? | 21:24 |
| markwash | vishy: so we shouldn't need a real image service anyway | 21:24 |
| *** ryu_ishimoto has joined #openstack-meeting | 21:25 | |
| ttx | can we move to Glance and Swift ? | 21:25 |
| markwash | ttx: sorry, sure | 21:25 |
| * ttx thiks he should reorder the topics | 21:25 | |
| ttx | #topic Glance status | 21:25 |
| *** openstack changes topic to "Glance status" | 21:25 | |
| jaypipes | https://launchpad.net/glance/+milestone/diablo-1 | 21:25 |
| ttx | (since glance and swift usually don't generate so much discussion) | 21:25 |
| ttx | Your first milestone (diablo-1, also June 2nd) looks in good shape: 2 merged, 1 proposed. | 21:25 |
| jaypipes | we're on target to cut diablo-1 with the currently targeted features and bug fixes. | 21:26 |
| ttx | indeed | 21:26 |
| jaypipes | hammering out a couple remaining issues around results pagination, but I don't foresee too many issues in meeting June 2nd deadline | 21:26 |
| bcwaldon | seconded | 21:26 |
| jaypipes | I'll be focusing entirely on bug fixes this coming week while bcwaldon finishes the little work left on pagination. | 21:26 |
| ttx | jaypipes: do you want a release branch cut on Wednesday morning ? | 21:27 |
| jaypipes | there's a couple outstanding SQLalchemy migrate bugs that are annoying, as always. | 21:27 |
| jaypipes | ttx: yes please | 21:27 |
| ttx | ok | 21:27 |
| ttx | Anything else on/for Glance ? | 21:27 |
| jaypipes | other than that, diablo-2 is all about integration with keystone. waiting to see how termie and vishy's work around nova integration with keystone works out. we'll use what we can there to save time and give us more time to work on shared image groups (http://etherpad.openstack.org/GlanceSharedImageGroups) | 21:28 |
| *** primeministerp1 has joined #openstack-meeting | 21:28 | |
| markwash | jaypipes: did you see my email about pagination this afternoon? | 21:28 |
| jaypipes | markwash: yeppers. I'll ping you in a bit. | 21:28 |
| markwash | jaypipes: gotcha, thanks | 21:28 |
| jaypipes | np | 21:28 |
| jaypipes | ttx: that's it for us. | 21:28 |
| jaypipes | anybody have any questions for us? | 21:29 |
| ttx | #topic Swift status | 21:29 |
| *** openstack changes topic to "Swift status" | 21:29 | |
| blamar_ | jaypipes: Given that Keystone isn't an official OpenStack project, is integration premature? | 21:29 |
| ttx | ah! | 21:29 |
| jaypipes | blamar_: it's integration around the API, so no... :) | 21:29 |
| blamar_ | jaypipes: Good thing the API is stable and decided? :) | 21:30 |
| blamar_ | ttx: apologies | 21:30 |
| jaypipes | blamar_: heh, well, you know what I mean... | 21:30 |
| ttx | no problem :) | 21:30 |
| jaypipes | blamar_: we focus on the spec versus the implementation. | 21:30 |
| ttx | notmyname: Hi! So the first milestone for Swift is 1.4.0, on May 31. | 21:30 |
| johnpur | anotherj1sse: what is the progress on pushing the keystone project foward | 21:30 |
| notmyname | yes it is | 21:31 |
| ttx | johnpur: please raise in open discussion | 21:31 |
| ttx | 6 blueprints targeted: 5 merged and 1 proposed, looks good | 21:31 |
| notmyname | we are currently doign QA work for 1.4.0. It should be ready | 21:31 |
| notmyname | the one that hasn't merged yet will be removed | 21:31 |
| ttx | notmyname: so next Tuesday you'll bump the version number to 1.4.0, and then bump it again to 1.4.1-dev, so that we get one build versioned "1.4.0" ? | 21:31 |
| notmyname | and not be in 1.4.0 | 21:31 |
| ttx | oh, ok | 21:32 |
| notmyname | yes. we will bump the version to only have one 1.4.0 | 21:32 |
| ttx | cool. | 21:32 |
| ttx | notmyname: any other announcements or comments ? | 21:32 |
| notmyname | future plans: | 21:32 |
| notmyname | probably in this next milestone: | 21:32 |
| notmyname | to remove swauth and the stats/loggin stuff currently in swift to be in separate projects | 21:33 |
| jaypipes | notmyname: can we get swift to make toast yet? | 21:33 |
| notmyname | this will allow for independent release cycles and further show that they are good examples, not always recommended for every production use | 21:33 |
| creiht | jaypipes: for certain selections of server chassis, yes :) | 21:34 |
| ttx | Other questions for the Swift team ? | 21:34 |
| jaypipes | :) | 21:34 |
| *** mattray1 has quit IRC | 21:34 | |
| ttx | Then raise you hand before I switch to next topic :) | 21:34 |
| ttx | #topic Open discussion | 21:35 |
| *** openstack changes topic to "Open discussion" | 21:35 | |
| ttx | <johnpur> anotherj1sse: what is the progress on pushing the keystone project foward | 21:35 |
| * jaypipes would like to hear from mtaylor about CI | 21:35 | |
| johnpur | or any of the keystone folks | 21:35 |
| ttx | johnpur: from where I stand there is a first nova integration step targeted to diablo-1, assigned to Titan team | 21:35 |
| johnpur | ttx: the reason i ask is the point that was brought up earlier | 21:36 |
| johnpur | there is assumptions on integration | 21:36 |
| ttx | jaypipes: the magic QA setup that tests everything and ensures nothing ever breaks was targeted to diablo-1, but won't make it | 21:36 |
| johnpur | however, we need to get keystone recognized as a project | 21:36 |
| ttx | jaypipes: for more detail, see mtaylor :) | 21:37 |
| jaypipes | johnpur: I think that is outside the scope of this meeting, to be fair. | 21:37 |
| johnpur | nova, swift, and glance should be integrated near the second miletsone | 21:37 |
| blamar_ | johnpur: Isn't that just a vote somewhere? | 21:37 |
| johnpur | jaypipes: ok | 21:37 |
| jaypipes | blamar_: bit more involved than that :) | 21:37 |
| johnpur | i just get too excited, i guess :) | 21:37 |
| jaypipes | johnpur: :) | 21:37 |
| ttx | any other topic / question ? | 21:38 |
| *** Tv_ has joined #openstack-meeting | 21:39 | |
| jaypipes | antonym: how's the racker setup testing going? comstud and soren seemed to have fixed the eventlet issues? | 21:39 |
| jaypipes | antonym: have we run into more concurrency issues? | 21:39 |
| pvo | still seeing some issues, not sure if they're eventlet or not. | 21:39 |
| ttx | notmyname, vishy, jaypipes: do you agree to reorder the topics at the next meeting as [ 'swift', 'glance', 'nova'] ? Looks like the questions and nova and open discussion could better blend. | 21:39 |
| jaypipes | pvo: k | 21:39 |
| notmyname | ttx: good with me | 21:39 |
| jaypipes | ttx: no probs with me. | 21:39 |
| antonym | jaypipes: working on it right now, about to get some scale tests going again once i get past some hiccups with builds | 21:39 |
| vishy | sure | 21:39 |
| * vishy makes a note to show up at 2:30 | 21:40 | |
| vishy | :p | 21:40 |
| jaypipes | antonym: cool, good to know. | 21:40 |
| notmyname | vishy: like I do now? ;-) | 21:40 |
| mtaylor | jaypipes: aroo? | 21:40 |
| jaypipes | mtaylor: just wondering on progress with the smoketesting stuff | 21:40 |
| westmaas | ttx: do dev teams have any special responsibilities around milestone releases outside of getting things in before tuesday EOD? | 21:40 |
| ttx | westmaas: no | 21:40 |
| westmaas | ttx: cool, thanks | 21:41 |
| ttx | westmaas: work on targeted bugs... but we haven't so many of them in the first milestone | 21:41 |
| mtaylor | jaypipes: first step "works" on jenkins... second step needs to clean up the first step (which is what I'm on right now) | 21:41 |
| ttx | westmaas: and usually part of the milestone-targeting process is to ensure you have someone committed to fixing the bug | 21:41 |
| jaypipes | mtaylor: k. what about the hardware that you and letterj were working on? | 21:41 |
| mtaylor | jaypipes: then I need to get some jenkins goo sorted out so that results of this can be properly integrated in to what we're doing with tarmac | 21:41 |
| ttx | westmaas: otherwise it's like pissing in a violin, like we say in france. | 21:42 |
| * jaypipes away last week so trying to catch up with folks.. | 21:42 | |
| mtaylor | jaypipes: deferring on the hardware at this instant - getting the functional smoketests in a vm working properly before we sort out launching it all on actual hardware | 21:42 |
| westmaas | ttx: is that a bad thing? | 21:42 |
| mtaylor | jaypipes: (starting small and getting bigger) | 21:42 |
| ttx | westmaas: it's surprisingly ineffective. | 21:42 |
| jaypipes | mtaylor: k. good to know. thx for the update. | 21:42 |
| vishy | mtaylor: if you can get some of us access to the servers where the tests are actually running, we might be able to help debug why smoketests are failing | 21:42 |
| soren | ttx: lol | 21:42 |
| mtaylor | vishy: I can stop the script from deleting the cloud servers when it's done | 21:43 |
| vishy | mtaylor: cool, i think it is probably just a couple of config changes | 21:43 |
| mtaylor | vishy: and then give you access to that | 21:43 |
| *** spectorclan_ has quit IRC | 21:43 | |
| vishy | is the stuff that provisions the cloud server and installs nova checked in somewhere? | 21:44 |
| mtaylor | vishy: sweet - I was also going to start working through the chef recipies to see what they are doing that I'm not doing | 21:44 |
| vishy | in case we need to edit it? | 21:44 |
| mtaylor | vishy: no, it's just in jenkins right now | 21:44 |
| mtaylor | vishy: it's all in the jenkins config page | 21:44 |
| vishy | mtaylor: ok | 21:44 |
| vishy | mtaylor: is that visible publicly? or do i need a login? | 21:44 |
| mtaylor | vishy: http://jenkins.openstack.org/job/nova-smoketests/configure | 21:45 |
| mtaylor | vishy: you need jenkins login to see it most likely - although you know - I _REALLY_ should figure out a good way to version control the contents of that | 21:45 |
| * mtaylor mutters about data on web forms.. | 21:45 | |
| jaypipes | mtaylor: I heard github can store code for you in a version control system. | 21:45 |
| * jaypipes runs and hides | 21:46 | |
| ttx | jaypipes: sounds cool | 21:46 |
| soren | jaypipes: I see what you did there. | 21:46 |
| markwash | I'm really excited about the things we can do after multinic. . what's the progress there? anything we can help with? | 21:46 |
| jaypipes | hehe | 21:46 |
| mtaylor | jaypipes: sure it can - but can it store the sub chunk of an xml config file? | 21:46 |
| jaypipes | tr3buchet: ^^ | 21:46 |
| mtaylor | jaypipes: in a way that's sensible for the jenkins interface (/me may need to have to write yet-another jenkins plugin) | 21:47 |
| ttx | mtaylor strickes back jaypiipes using XML | 21:47 |
| ttx | oo, that went bad. | 21:47 |
| * jaypipes lashes out with JSON fireball. | 21:47 | |
| jaypipes | alright, this is getting out of control. :) | 21:47 |
| * ttx uses a shield of YAML. | 21:48 | |
| * mtaylor just pukes on people | 21:48 | |
| jaypipes | do we have any more pressing business? I think the Network (quantum) folks may have a meeting next here? | 21:48 |
| _0x44 | Did someone order this pile of CSV? | 21:48 |
| ttx | ok, let's leave the room to the network dudes | 21:49 |
| jaypipes | ack | 21:49 |
| ttx | and continue discussion on #openstack | 21:49 |
| ttx | #endmeeting | 21:49 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 21:49 | |
| openstack | Meeting ended Tue May 24 21:49:26 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:49 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-21.01.html | 21:49 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-21.01.txt | 21:49 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-21.01.log.html | 21:49 |
| *** bcwaldon has left #openstack-meeting | 21:49 | |
| ttx | dendrobates: room is yours. | 21:49 |
| tr3buchet | jaypipes, markwash: status is a few remaining api changes, following by getting the code coverage up and it's ready for some hellish nitpicking | 21:49 |
| danwent | ttx: "network dudes"... I like that :) | 21:49 |
| dendrobates | ttx: thanks. Sticking around? | 21:50 |
| ttx | danwent: magic packets | 21:50 |
| * tr3buchet puts on his wizard hat and robe | 21:50 | |
| ttx | dendrobates: you know what time it is ? | 21:50 |
| zul | time to get ill? | 21:50 |
| dendrobates | ttx: I do | 21:50 |
| ameade | HAMMER TIME | 21:50 |
| dendrobates | time after time | 21:50 |
| ttx | it's well past beer time over here | 21:51 |
| tr3buchet | oh sweet, i've been needing to use the parachute pants for something | 21:51 |
| ttx | dendrobates: but I'll read the logs | 21:51 |
| dendrobates | I don't think France celebrates Beer time. | 21:51 |
| ttx | dendrobates: consider I'm with you in spirit. | 21:51 |
| Tv_ | wine time? | 21:51 |
| *** alandman has left #openstack-meeting | 21:51 | |
| *** alandman has quit IRC | 21:51 | |
| markwash | dendrobates: you should have some saison | 21:51 |
| tr3buchet | markwash: you can definitely give some constructive criticism when the merge prop gets out | 21:51 |
| ttx | Tv_: it's about Cognac time. | 21:51 |
| *** BinaryBlob has quit IRC | 21:51 | |
| Tv_ | true, true | 21:51 |
| *** Tv_ is now known as Tv | 21:52 | |
| markwash | tr3buchet: cool, I'd love to see a list of the "few remaining api changes" :-) | 21:52 |
| dendrobates | markwash: I'll look for it on my next trip | 21:53 |
| tr3buchet | markwash: add extra IPs to instance, add additional network to project. actually a couple, not few. Both I plan on adding to compute API | 21:53 |
| *** littleidea has joined #openstack-meeting | 21:54 | |
| * markwash races home before the networking meeting starts | 21:55 | |
| *** ameade has quit IRC | 21:56 | |
| *** ecarlin has joined #openstack-meeting | 21:58 | |
| dendrobates | I have to leave in 30 min. Can someone else run meetbot? | 22:00 |
| danwent | #start-meeting | 22:00 |
| danwent | is that how? | 22:00 |
| tr3buchet | FAIL! | 22:00 |
| danwent | no! | 22:00 |
| danwent | irc newbie :) | 22:00 |
| dendrobates | http://wiki.debian.org/MeetBot | 22:00 |
| *** masumotok has quit IRC | 22:00 | |
| danwent | #startmeeting | 22:01 |
| openstack | Meeting started Tue May 24 22:01:02 2011 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. | 22:01 |
| dendrobates | w/o the dash | 22:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 22:01 |
| danwent | haha, thank god rick is running things :) | 22:01 |
| *** adjohn has joined #openstack-meeting | 22:01 | |
| salv-orlando | Hi everybody | 22:01 |
| troytoman | hello all | 22:01 |
| adjohn | Hey | 22:01 |
| dendrobates | the agenda is here: http://wiki.openstack.org/Network/Meetings | 22:01 |
| ecarlin | hello | 22:01 |
| somikbehera | hi everybody | 22:01 |
| RamD | Hello | 22:01 |
| *** romain_lenglet has joined #openstack-meeting | 22:01 | |
| jamesurquhart | hello | 22:02 |
| ying | hello | 22:02 |
| AlexNeef | hi all | 22:02 |
| danwent | hi folks. want to introduce brad, a new guy on our team from nicira | 22:02 |
| danwent | (not new to nicira, but new to netstack) | 22:02 |
| danwent | brad, you there? | 22:02 |
| danwent | maybe i need to go over to his cube and kick him. | 22:02 |
| dendrobates | attendance fail :) | 22:02 |
| bhall | I'm here :) | 22:03 |
| salv-orlando | poor brad | 22:03 |
| danwent | one more and its a fail hat trick for me | 22:03 |
| bhall | (no kicking necessary) | 22:03 |
| bhall | hi everyone.. | 22:03 |
| salv-orlando | I hope Dan does not kick like Chuck Norris | 22:03 |
| danwent | ok, if rick needs to run in 30 mins, let's try to get things started, shall we? | 22:03 |
| danwent | #topic extensions | 22:03 |
| *** openstack changes topic to "extensions" | 22:03 | |
| ecarlin | stanford people don't kick like chuck norris :-) | 22:03 |
| danwent | rough | 22:03 |
| danwent | so, I think the main question is how do we let plugins expose non base capabilities | 22:04 |
| ying | before talking about data extensions, shall we talk about data attributes in core API? | 22:04 |
| danwent | ah, you mean like id, name, date_created? | 22:04 |
| ying | as the extension is something beyond that | 22:05 |
| ying | yes | 22:05 |
| AlexNeef | did we agree to use the /cap/{key} mechanic in the api? | 22:05 |
| danwent | AlexNeef, let's save that for the next discussion (even if the core concept itself is not an extension) | 22:05 |
| romain_lenglet | I don't think so | 22:05 |
| danwent | ok, ying, are you proposing some additional fields for the base beyond what was in salvatore's spec on the wiki? | 22:06 |
| danwent | I think that included and id,name for networks, and an id for ports? | 22:06 |
| AlexNeef | ok - I did update a lot of the base attirbutes | 22:06 |
| ying | not put on the wiki yet,it here http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.pdf | 22:06 |
| *** creiht has left #openstack-meeting | 22:06 | |
| ying | yes, I saw Alex's updates | 22:06 |
| AlexNeef | I'm not sure people saw that: http://wiki.openstack.org/QuantumAPISpec | 22:07 |
| *** markwash_ has joined #openstack-meeting | 22:07 | |
| AlexNeef | I wanted to get the ball rolling thinking about the data attributes | 22:07 |
| romain_lenglet | can somebody explain me again why we have to replace API extensions with extensible data attributes? | 22:07 |
| ying | we need to make sure that we agree all the base attributes in the core API | 22:07 |
| ying | then, we can see what needed for extension | 22:07 |
| danwent | romain: I don't think we have to, but that is part of the next discussion. | 22:08 |
| romain_lenglet | good, let's discuss that | 22:08 |
| salv-orlando | Agree with ying, but I think the topic was for discussing a mechanism for extension API rather than defining what is "base" and what is "extension" | 22:08 |
| danwent | +1 | 22:08 |
| danwent | that is exactly what I was typing :) | 22:08 |
| somikbehera | agree. | 22:08 |
| danwent | in my mind, the entire API is still experimental | 22:08 |
| *** summer has quit IRC | 22:09 | |
| danwent | so I don't think we need to be making final calls here. | 22:09 |
| markwash_ | have you all taken a look at the instrumentation for extensions in nova? | 22:09 |
| dendrobates | so everyone wants to discuss the extension mechanism now? | 22:09 |
| danwent | if ying is ok with it, I would suggest doing so. | 22:09 |
| somikbehera | markwash_ : some of us have and hopefully we are going to discuss nova/openstack extension mechanism here too and may use them | 22:10 |
| ying | so we are clear about the data attributes? | 22:10 |
| ying | ok | 22:10 |
| danwent | Ok, extensions. | 22:10 |
| danwent | so I believe we are planning on using Openstack standard extension mechanisms. | 22:10 |
| danwent | or at least we'll work with jorge to identify whether they are suitable. | 22:10 |
| ecarlin | +1 | 22:11 |
| salv-orlando | +1 | 22:11 |
| somikbehera | +1 | 22:11 |
| johnpur | +1 | 22:11 |
| romain_lenglet | +1 | 22:11 |
| bhall | +1 | 22:11 |
| dendrobates | I think we should use them and suggest modifications if we find shortfalls | 22:11 |
| RamD | +1 | 22:11 |
| jamesurquhart | Just to be clear, though, the "standard" hasn't been officially blessed yet, right? | 22:11 |
| danwent | Ok, so it seems to me that openstack extensions let us add attributes to any of the network or port objects using the data extension mehcanism | 22:11 |
| dendrobates | jamesurquhart: right, but nearly | 22:11 |
| danwent | james: yes, we can still help improve the standard. | 22:12 |
| jamesurquhart | Cool. | 22:12 |
| danwent | if it is lacking | 22:12 |
| AlexNeef | I'm not sure i understand what that really means tangibly | 22:12 |
| danwent | we will also need to consider how to add additional API methods and API objects (i.e., go beyond data extension). | 22:12 |
| AlexNeef | is the standard extention model in some type of contradiction with yings model? | 22:12 |
| danwent | AlexNeef: clarify? | 22:12 |
| ecarlin | a draft of the extensions guide is happening as we speak and will be submitted to the policy board soon for final approval | 22:12 |
| danwent | Alex: I don't think so. | 22:12 |
| ying | I think they are converging | 22:12 |
| ying | standard mechanism defines how to define and discovery the extension | 22:13 |
| danwent | So the work item I was proposing around quantum-extensions is not so much defining what is or is not an extension | 22:13 |
| ying | it has data extension part, we can use that for key value model | 22:13 |
| romain_lenglet | danwent: +1 on supporting additional methods, that's necessary and that could be all that we need (i.e. no need for additional data attributes, we just need extra methods) | 22:13 |
| danwent | but rather the mechanisms by which plugins can expose extensions. | 22:13 |
| ecarlin | if ying feels there is a shortcoming with the proposed extension model, i suggest he get with jorge and adjust. if it's a shortcoming here, it will likely be elsewhere. let's make the standard extension model better vs. deviating. | 22:14 |
| danwent | romain: I think that is an interesting point. One could argue that data extension is not the right way to do at all. | 22:14 |
| danwent | this is a good discussion to have. | 22:14 |
| ecarlin | the extension model supports additional api operations | 22:14 |
| markwash_ | so, I definitely like jorge's extensions model, but it didn't seem to be built for yings use case precisely | 22:14 |
| markwash_ | from what I understand, the quantum api is looking for ways to expose plugin functionality that it doesn't necessarily know about ahead of time, right? | 22:15 |
| ying | yes, I agree. we can use it for my key value model | 22:15 |
| danwent | mark: yes | 22:15 |
| dendrobates | does everyone understand ying's use case? | 22:15 |
| somikbehera | I think jorge's extension model allows to extend the API with new methods for specific methods therefore not ncessarily requiring extensible data objects.. | 22:15 |
| danwent | romain: where you advocating for an approach that limits what extensions are considered "valid" to only using new API objects + methods? | 22:15 |
| jamesurquhart | dendrobates: My question as well | 22:15 |
| romain_lenglet | danwent: both approaches are dual | 22:16 |
| romain_lenglet | but I feel we'll need extra methods in extensions anyway | 22:16 |
| danwent | romain: agreed. | 22:16 |
| romain_lenglet | so we could just go all with extra methods | 22:16 |
| danwent | romain: would that be excluding the "data extension" approach? | 22:17 |
| ying | my understanding is that extra methods go with the extended resources | 22:17 |
| somikbehera | i like that as then its clear from API who is adding those methods as they can be in a separate rest namespace | 22:17 |
| ying | by adding new resources, we can add new methods | 22:17 |
| somikbehera | while with data attributes, the namespace gets polluted with standard namespace. | 22:17 |
| danwent | ying: can you define "resources" ? you're not talking about a URI, are you? | 22:18 |
| ying | resource is the subject in the web service, like network, port ,etc | 22:18 |
| danwent | yes, ok. | 22:18 |
| *** dtroyer_ has quit IRC | 22:18 | |
| romain_lenglet | we'll need extra methods on ports, networks, etc. | 22:19 |
| romain_lenglet | not merely on new resources | 22:19 |
| ying | romain: could you give soem example? | 22:19 |
| danwent | I think adding new methods need to be in scope. | 22:19 |
| danwent | as well as adding new resources. | 22:19 |
| salv-orlando | +1 | 22:20 |
| AlexNeef | whats a new resource? | 22:20 |
| jamesurquhart | danwent: But not new data attributes? (Just trying to get this debate clear in my head) | 22:20 |
| danwent | To me, the interesting question is do we want to limit what people can do by saying that they should not "extend" the "base" objects in the API (network, port). I don't have a strong feeling on this, but others may. | 22:20 |
| *** Jamey_ has joined #openstack-meeting | 22:20 | |
| danwent | port and network is a "resource" | 22:20 |
| danwent | in the base API. | 22:21 |
| danwent | James: does that answer your question? | 22:21 |
| AlexNeef | So I can create an extention with additonal types of resources like "MyPort" | 22:21 |
| ying | yes | 22:21 |
| jamesurquhart | danwent: sort of. I'll "listen" further for a bit… ;) | 22:21 |
| danwent | I think the "data extension" mechanism would let you add new key-values to the existing Port object. | 22:21 |
| salv-orlando | Why don't we reason around the "capability" feature? Is a capability an extended composite attribute of the port or is it a "Port_Capability" resource? | 22:22 |
| AlexNeef | That seems like we will break introperability quickly | 22:22 |
| danwent | I believe we are discussing whether this should be allowed. | 22:22 |
| *** mattray has joined #openstack-meeting | 22:22 | |
| AlexNeef | salv: good idea i need to anchor this concept somewhere | 22:22 |
| ying | salv: that's my initial question | 22:22 |
| ying | do we need to have any cap in the base API? | 22:22 |
| RamD | Salv: this is more like port-profile in our proposal | 22:23 |
| AlexNeef | So i vote for capabilties as a comonent of an existing resource | 22:23 |
| AlexNeef | i.e. port/cap/ | 22:23 |
| danwent | I think generally there is a need to associate new types of state + actions with existing types of resources (e.g., a set of ACLs on a port) | 22:23 |
| danwent | or the ability to put a port in "Admin down" state. | 22:23 |
| RamD | Yes. port-profile kind of constructs provide "grouping" them eg ACL across # of Port resources | 22:24 |
| ying | Alex: you mean cap is attributes with base resource port? | 22:24 |
| *** johnpur has quit IRC | 22:24 | |
| AlexNeef | One concenpt of a "capabilty" is that it's a static feature of a resource. It just describes it. things like ACL's are really features, that you interact with | 22:25 |
| somikbehera | I think we can easily dop port profiles, cap etc. using Jorge's extension mechanism. | 22:25 |
| salv-orlando | I think something like port_cap sound more natural but pollutes the namespace, whereas port_profile maybe is not as natural but keeps base and extended namespace separate | 22:25 |
| somikbehera | *easily do | 22:25 |
| danwent | port-profile imply a template, no? | 22:25 |
| danwent | i.e., something that can be applied to many ports? | 22:26 |
| ying | yes | 22:26 |
| salv-orlando | danwent: I think so... | 22:26 |
| danwent | to me that is a somewhat different discussion. | 22:26 |
| AlexNeef | agree - theres no implied coupling between an actual port | 22:26 |
| ying | one to many | 22:26 |
| RamD | port-profile is a set of attributes that can be applied to many ports | 22:26 |
| RamD | e.g. Same ACLs for # of ports | 22:27 |
| dendrobates | ying: should that exist in Donabe instead? | 22:27 |
| danwent | so the ACL itself is not an attribute of the port with a port-profile, is that correct? | 22:27 |
| danwent | dendrobates: I was thinking along similar lines. | 22:27 |
| ying | it's associated with port, hence, I think it belongs to quantum | 22:28 |
| jamesurquhart | dendrobates: different than network container. more a "grouping" like a role | 22:28 |
| markwash_ | somikbehera: my only point is that I feel like the extension mechanism is something you do when something really doesn't fit into core at this time | 22:28 |
| RamD | Ying +1 | 22:28 |
| markwash_ | somikbehera: but we are all talking about these things like some set of quantum plugins will probably need to use them | 22:28 |
| danwent | could we focus on a simpler use case for a second? | 22:29 |
| AlexNeef | ying: i disagree, many other services will make use of quantum components without being owned in the base api | 22:29 |
| danwent | like wanting to expose statistics on a port as an extension? | 22:29 |
| salv-orlando | danwent: If you have it shoot! | 22:29 |
| danwent | the port-profile case (while potentially valuable) actually conflates several unresolved issues in my mind. | 22:29 |
| *** mattray has quit IRC | 22:30 | |
| somikbehera | markwash_: not all plugins but some plugins may use/implement the adavanced functionality | 22:30 |
| salv-orlando | Ok, let's analyze statistics use case, from an API user perspective | 22:30 |
| danwent | one way to do it would be to use data-extension to expose a "statistics" field in the port object itself. | 22:30 |
| danwent | another way would be to add a new URL: /network/<id>/port</id>/stats | 22:31 |
| salv-orlando | If a user wrote a client app which fetches statics using /port/statistics that would be quite easy and natural | 22:31 |
| AlexNeef | statistics are a good case because in addition to reading them i may also want to clear them | 22:31 |
| somikbehera | markwash_ : therefore we could have the advanced stuff be extensions | 22:31 |
| danwent | or /port-stats/<id> | 22:31 |
| *** edconzel_ has joined #openstack-meeting | 22:31 | |
| ying | alex: disagree with whether we need port profile here? | 22:31 |
| *** edconzel_ has quit IRC | 22:31 | |
| salv-orlando | but the user would not be aware of the fact that "statistics" is an extension | 22:31 |
| dendrobates | guys I need to go to my kids school. I will catch up later. I will send an email out about my webex topic. | 22:31 |
| AlexNeef | +1 to using webex | 22:31 |
| ecarlin | you would do that as /v1/networks/{netid}/ports/{portid}/ext/{vendor-id}/statistics | 22:31 |
| danwent | by rick! | 22:32 |
| ecarlin | you would know it's an extensions because of the URI | 22:32 |
| ecarlin | plus all extensions are queryable | 22:32 |
| danwent | in theory, i think all of those mechanisms would be supported using openstack extensions. | 22:32 |
| ecarlin | yes | 22:32 |
| salv-orlando | ecarlin +1 | 22:32 |
| somikbehera | +1 | 22:32 |
| markwash_ | danwent: I agree that they can be supported using the openstack extensions mechanism | 22:32 |
| markwash_ | danwent: I think the question is, are they general enough to not require the extensions mechanism? | 22:33 |
| danwent | I think we are discussing whether the idea of adding a "statistics" field to the "base" port attribute should be discuraged. | 22:33 |
| AlexNeef | +1 that however we could also /v1/networks/{netid}/ports/{portid}/statistics/ext/{vendor-id} | 22:33 |
| AlexNeef | which would allow us a base set of stats with the option to extend by vendor if we want | 22:33 |
| markwash_ | danwent: apologies if I'm off base | 22:33 |
| salv-orlando | Same URI structure could be used also for new resources e.g.: v1/ext/{vendor-id}/strangeresource | 22:33 |
| *** edconzel has quit IRC | 22:33 | |
| danwent | mark: not sure I following your last question. can you clarify? | 22:34 |
| ying | let's take statistics use case, we first define an extension: statistics, then later we want to extend statistics by adding new stat attributes | 22:34 |
| danwent | Erik, you've put a lot of thought into extensions, what is your take? | 22:34 |
| markwash_ | danwent: so to me, I love extensions because when I have something that nobody else can use or support, I can still fit it into the api | 22:34 |
| ying | is that another extension based on existing extension: statistics? | 22:34 |
| markwash_ | danwent: but I don't love adding all the extra length to the urls and complicated namespaces if its actually a pretty general use case | 22:34 |
| danwent | :mark yes, that's the idea. extensions can then be "promoted" to base if people like them. | 22:34 |
| markwash_ | danwent: it seems like punting on first down | 22:35 |
| markwash_ | danwent: I love punting on fourth down | 22:35 |
| markwash_ | danwent: but I'd rather see if it fits in core first | 22:35 |
| ecarlin | the idea is to keep core universally applicable, i.e. it should work with every plugin | 22:35 |
| ecarlin | if everyone supported port statistics, we could make it core | 22:35 |
| ecarlin | if not, if would be an extensions | 22:35 |
| danwent | mark: Our motivation was to get the core L2 functionality out first. | 22:35 |
| ecarlin | over time, if that became "standard", it would get promoted to core | 22:36 |
| danwent | mark: then aggressively promote. | 22:36 |
| markwash_ | ecarlin: so different vendor supplied statistics packages, with the same interface, would still have different urls? | 22:36 |
| ecarlin | we should guard core and keep it universally applicable | 22:36 |
| markwash_ | ecarlin: and different attribute names in existing objects? | 22:36 |
| danwent | main goal is to get a simple "core" out, without months of discussion of what is or is not in core | 22:36 |
| danwent | L2 connectivity only seemed like a very simple line to draw. | 22:36 |
| AlexNeef | so i agree we need to get the "core" but having a place holder so software can know that there will be a mechaism for retreiving stats, capabilties, etc from the get go is valuable | 22:36 |
| AlexNeef | even if we only define a really small set of base stats or capabilities | 22:37 |
| ecarlin | markwash: no, there are multi-vendor extension prefixes so the URI can be the same | 22:37 |
| somikbehera | AlexNeef: the same can be achieved via an extension till the exntension gets universally accepted. | 22:37 |
| markwash_ | ecarlin: okay cool | 22:37 |
| ecarlin | this is exactly how OpenGL works which is where Jorge derived this approach | 22:37 |
| jamesurquhart | danwent: It seems that stats is a unique case to most people here. Is that right? Or are there other topics that would garner the same debate? | 22:37 |
| danwent | QoS, ACLs, etc. all seemed to get people very excited and wanting to go in different directions. | 22:37 |
| danwent | We had to spend a lot of time to get people to just settle on tackling L2 connectivity. | 22:38 |
| danwent | so we went with a model where people could go do anything they wanted, as long as it started out as an extension. | 22:38 |
| jamesurquhart | OK, so I guess I would agree that starting with simple base is best, but that comes with the cost of breaking backward compatibility as functions move from extensions to core over time. | 22:38 |
| markwash_ | ecarlin: I definitely buy the concept of extensions, I just worry that the cost of adding an extension is greater to the user and deployer than we are guessing now | 22:38 |
| danwent | then once we got the base in place (still as an experimental-only solution), we could tackle advanced APIs. | 22:39 |
| ecarlin | I think we should keep those out of core for now and keep it simple. We spent a lot of time at the summit paring things back to basic L2 connectivity. | 22:39 |
| markwash_ | ecarlin: perhaps we can reduce that cost however with our code | 22:39 |
| ecarlin | if people want to support more now, go for it, that's what extensions are for, but i would vote to keep core simple for starters | 22:39 |
| ecarlin | i think this is much broader than quantum | 22:40 |
| jamesurquhart | ecarlin: We should, however, acknowledge that there are tradeoffs for things we know are *likely* to be common in future | 22:40 |
| AlexNeef | ecarlin: I agree in concept, but think there are some peices that are reqruired for basic cfunctionality that are missing | 22:40 |
| ecarlin | across any service, plugins should be able to expose capablities in consistent ways | 22:40 |
| ecarlin | we need a framework for that that all services can utilize | 22:40 |
| AlexNeef | static capabilities are an example | 22:40 |
| ying | so, what should we include in core? it's still my question? | 22:40 |
| jamesurquhart | ecarlin: Sure. Not sure that is what is being debated at this point. | 22:40 |
| danwent | to me the first piece of the puzzle is making sure quantum can even support API extensions. | 22:41 |
| markwash_ | danwent: supporting extensions in the base case is no difficulty--slap a middleware or straight http proxy on top of the regular api, have it call what you need it to call | 22:42 |
| jamesurquhart | danwent: +1, but once solved it quickly exposes base vs. extension issue | 22:42 |
| danwent | the debate about what is or is not core will probably continue indefnitely, but I'd really like to get someone coding on supporting extensions :) | 22:42 |
| markwash_ | danwent: but perhaps your focus is on something more elegant? | 22:42 |
| somikbehera | ying: salvateore has a core API spec up for review for a few weeks that defines the agreement on core from summit. | 22:42 |
| RamD | I think the question is what is the must have that we need in base API...better to have it now rather than later. | 22:42 |
| AlexNeef | +1 | 22:43 |
| danwent | I actually think with our plugin infrastructure it will be a bit more complex. It will partially depend on whether we allow data extension or not. | 22:43 |
| RamD | danwent: Agree lots of unknown for me | 22:43 |
| ying | somikbehera: yes, I read through that spec. It defines the resources and operations associated with resources, but not defined the attributes associated with each resource. Alex added some later. | 22:44 |
| danwent | I think in the absence of agreement here we have to stick to what we outlined at the summit. | 22:44 |
| ying | for example, network has name, id, port has state | 22:44 |
| salv-orlando | We have two rather orthogonal discussion: properly defining the core and a mechanism for extending it | 22:44 |
| *** sirp has left #openstack-meeting | 22:44 | |
| danwent | +1 | 22:44 |
| salv-orlando | While the former is pretty much "blurred" at the moment as mark pointed out we can start doing progress on the second | 22:44 |
| jamesurquhart | salv-orlando: +1 | 22:45 |
| danwent | I think salv-orlando is very close to having a first cut of the base networks + port code ready. | 22:45 |
| RamD | Yep..that's why Ying started it with that | 22:45 |
| salv-orlando | While a team adds the extension middleware, we can all together discuss the nature of the core | 22:45 |
| markwash_ | apologies if I have derailed things :-/ | 22:45 |
| danwent | we can continue to iterate on that once it is out.... this API is still experimental, so no need to worry about what is or is not in it. | 22:46 |
| salv-orlando | and then what is core will be handled by the API I'm already implementing, and what is not core goes through the extension mechanism | 22:46 |
| danwent | mark: healthy discussion :) | 22:46 |
| somikbehera | properly defining core: we can first deliver what we defined at the summit, quickly iterate and add more, its all about being agile right? | 22:46 |
| salv-orlando | markwash_: you were suggesting before your code (API serialization?) can be helpful for us. In which way? | 22:46 |
| Sumit | as far as the base spec is concerned, the point of discussion is more about what are the attributes of the resources | 22:47 |
| ecarlin | folks, i'm talking to jorge on the phone. he is going to join in a minute to address extensions questions. | 22:47 |
| salv-orlando | somikbehera: +1 | 22:47 |
| Sumit | i dont think we nailed them down during the summit | 22:47 |
| danwent | ecarlin: great, thanks | 22:47 |
| Sumit | if we know what the attributes are, we can accordingly definer relevant operations/API | 22:47 |
| ecarlin | he said nova is working on a way to have plugins auto register api extensions | 22:48 |
| salv-orlando | I suggest moving the discussion on attribute to etherpad, and then discuss it next week | 22:48 |
| Sumit | not to say that what is being currently proposed is not correct | 22:48 |
| danwent | The focus on L2 connectivity was a pretty strong theme of the summit | 22:48 |
| markwash_ | salv-orlando: what ecarlin just said ^^ | 22:48 |
| danwent | while recognizing that there was a whole bug of other things that we will eventually add to the base. | 22:48 |
| *** dendrobates is now known as dendro-afk | 22:48 | |
| danwent | (it was just that everyone's list of what else to add to the base was different) | 22:49 |
| danwent | ecarlin: very cool. | 22:49 |
| danwent | so are we waiting on jorge? | 22:49 |
| ecarlin | he is joining... | 22:50 |
| *** sirp__ has quit IRC | 22:50 | |
| danwent | I personally thing that extensions are a great way to "prototype" a proposal for base, as it is a very concrete proposal. | 22:50 |
| ecarlin | exactly | 22:50 |
| *** jorgew has joined #openstack-meeting | 22:51 | |
| danwent | other topics while we're waiting: we're hoping to send the base quantum framework + some integration with Salvatore + an open vswitch plugin for review soon. | 22:51 |
| danwent | everything is still completely experimemental, but you have to start somewhere :) | 22:51 |
| danwent | hi jorge :) | 22:52 |
| jorgew | Hey guys | 22:52 |
| somikbehera | anybody who has questions/confusion regarding the extension mechanism, should check jorge's presentation from the summit. | 22:52 |
| ying | Jorgew:a question about extension mechanism? For data extension, can we use it to extend an existing extension? | 22:52 |
| jorgew | not sure I follow — can you ellaborate | 22:53 |
| ying | For example, we define an extension "statistics", which has 4 attributes? Later we want to add 5th attr to it, should we add another extension? | 22:53 |
| ying | Or, we just modify previous extension's schema file? | 22:54 |
| markwash_ | ying: from what I understand yes--the only difficulty is making sure the order of operations works out right for when the extensions' logic runs | 22:54 |
| jorgew | Typically Yes that means a different extension | 22:54 |
| jorgew | but really | 22:54 |
| jorgew | it depends on what you client support is | 22:54 |
| markwash_ | ying: to clarify I was answering "can we". whether or not it is the right choice probably depends on the specific situation | 22:55 |
| jorgew | the correct thing to do is to define anothor one. | 22:55 |
| ecarlin | and would it supersede the previous extension? | 22:55 |
| ying | you mean define another extension with the same name "statistics" to supersede previous one? | 22:56 |
| jorgew | Right. It can — you can have both extensions simultaneously though i'm not sure that makes sense | 22:56 |
| RamD | How "versioning" is handled? more in lines of compat. | 22:56 |
| ecarlin | jorge: do you recommend putting a version in the extension name? | 22:57 |
| *** jkoelker has quit IRC | 22:57 | |
| jorgew | I would call it statistics2 that's whats typically done in gl | 22:57 |
| jorgew | but that said it's a different extension | 22:57 |
| ying | if that's the case, does it mean we won't use "data extension" independently? It always come alone with an resource extension? | 22:57 |
| RamD | Is this where key-value pairs have value | 22:57 |
| somikbehera | ying: correct, as its cleaner and we know which extension added what | 22:58 |
| jorgew | ying: no it doesnt mean that though — you can extend the data without adding new resources | 22:59 |
| danwent | Ok, so it seems like were we are at is that plugins will be able to register API extensions of any type using the standard openstack mechanisms. This includes extending existing resources (data extension), adding new resources, and adding new methods to existing resources. Is that a fair statement or is this still something we are debating? | 22:59 |
| salv-orlando | Sounds fair to me | 22:59 |
| somikbehera | +1 | 22:59 |
| danwent | I'm looking for "-1"'s at this point. Anyone disagree? | 23:00 |
| ying | not debating, just want make sure that we can use data extension independently | 23:00 |
| jorgew | Keep in mind that params are also valuable | 23:00 |
| danwent | jorge: can you clarify? | 23:00 |
| danwent | adding params to existing resources? | 23:00 |
| markwash_ | GET /networks?rax-pie:extendedparam=foo | 23:00 |
| jorgew | for example to implement queries and filters | 23:00 |
| ying | because to extend <key, value> list, we may not want to re-define the statistics again | 23:00 |
| jorgew | right | 23:00 |
| danwent | Mark: ah, great point | 23:01 |
| danwent | ok, so add in the ability to handle extensions in parameters. | 23:01 |
| danwent | Ok, so I think we're all on the same page. | 23:01 |
| ecarlin | jorge, am i correct that all extensions (data, resources, params, headers, mime-types, etc.) are independent | 23:01 |
| jorgew | yes. | 23:02 |
| danwent | other than webex, which we'll handle via email, are there other topics to cover? | 23:02 |
| ying | then, the discovery is independent, too. | 23:02 |
| danwent | webex = discussing hold and recording meetings over webex | 23:02 |
| ying | thus, it's client to match them together? | 23:02 |
| ying | based on version? | 23:03 |
| ecarlin | all extensions can be queried and have specific meaning | 23:03 |
| salv-orlando | danwent: agenda says "Quantum dev status" and "Open discussion" | 23:03 |
| jorgew | right they are dependant on version | 23:03 |
| ecarlin | extensions are independent of the api version, afaik | 23:03 |
| danwent | # quantum-dev | 23:04 |
| jorgew | no extensions are at the vesion level | 23:04 |
| danwent | #topic quantum-dev | 23:04 |
| *** openstack changes topic to "quantum-dev" | 23:04 | |
| danwent | man, we need rick :) | 23:04 |
| salv-orlando | you had your hat-trick :-) | 23:04 |
| danwent | :) | 23:04 |
| ecarlin | ah, yes | 23:04 |
| jamesurquhart | Congrats, Dan ;) | 23:04 |
| ecarlin | because it's past version in the uri | 23:04 |
| danwent | I mentioned earlier, we're hoping to get something out for review by the next meeting. completely experimental, not a locked down API, but enough that someone could play with it. | 23:04 |
| danwent | james: one of my few talents :) | 23:05 |
| danwent | other quantum dev updates? | 23:05 |
| jorgew | right an extension in ver 1 may be a core feature in ver 2 | 23:05 |
| danwent | #topic open-discussion | 23:05 |
| *** openstack changes topic to "open-discussion" | 23:05 | |
| salv-orlando | quantum dev update: API getting in space, code infrastructure "borrowed" from Openstack API | 23:05 |
| AlexNeef | I wanted to mention I added a port state concept to the wiki | 23:06 |
| AlexNeef | i was looking for feedback | 23:06 |
| salv-orlando | Yes Alex I saw that and I'm considering it globally accepted. | 23:06 |
| troytoman | just want to highlight the etherpad on network flows: http://etherpad.openstack.org/network-flows | 23:06 |
| salv-orlando | at least that what it looked like on the etherpad | 23:06 |
| danwent | Alex: yup, I think that's a good idea (it already had to +1s on the etherpad, no dissent). Seems inline with L2 connectivity. | 23:06 |
| danwent | to -> two | 23:06 |
| Sumit | I wanted to bring up the topic semantics of "attachments/attach" | 23:07 |
| troytoman | I am concerned that we don't have a consistent picture of how Nova/Quantum/Melange interact and what data is passed between services | 23:07 |
| salv-orlando | yeah I wanted to discuss that as well | 23:07 |
| troytoman | please chime in there if you have some thoughts | 23:07 |
| Sumit | have posted the question on etherpad, may be we can continue the discussion there or over emails? | 23:07 |
| salv-orlando | troytoman: Sure | 23:07 |
| danwent | sumit: on API etherpad? | 23:07 |
| Sumit | yeah | 23:08 |
| markwash_ | troytoman: as a lazy nova dev :-), I'd love it if I didn't have to store as much state in my own db to query the status of my vms and their nics | 23:08 |
| danwent | ok, sounds good. | 23:08 |
| salv-orlando | Sumit: I'm ok with discussing it here, but we are already 8 minutes overtime | 23:08 |
| Sumit | yeah no worries, we can take it offline | 23:08 |
| troytoman | I've also added a strawman flow for the 3 services at the use cases wiki: http://wiki.openstack.org/NetworkUsecases | 23:08 |
| Sumit | would request input though | 23:09 |
| troytoman | posted it there so we could look at a diagram | 23:09 |
| troytoman | just one idea - will look forward to the discussion throughout the week | 23:09 |
| danwent | ok, sounds good troy | 23:09 |
| danwent | I will definitely take a look and give feedback. | 23:09 |
| danwent | any other topics for open discussion? | 23:10 |
| salv-orlando | Silly question on code development: | 23:10 |
| AlexNeef | I had one other open topic: that I was trying to address through capabilities but maybe people have other ideas | 23:10 |
| danwent | salv was first :) | 23:10 |
| salv-orlando | this is quick | 23:10 |
| AlexNeef | np | 23:10 |
| salv-orlando | We are borrowing a lot of code from nova. What about authorship and copyright? | 23:10 |
| salv-orlando | if we take for instance nova.wsgi and make it quantum.common.wsgi should the file be still copyright of "Openstack LLC"? | 23:11 |
| danwent | alex: can you pre-type? | 23:11 |
| danwent | yeah, I had asked Rick about that earlier. | 23:11 |
| danwent | he said there is no clear right answer. | 23:11 |
| danwent | might thought is that if you borrow a whole file from someone, probably keep the copyright. | 23:12 |
| danwent | if you think you'll end up filling most of the file, change it. | 23:12 |
| danwent | that is what I do, but is by no means legally informed | 23:12 |
| danwent | any lawyers on the channel? | 23:12 |
| salv-orlando | I'm really not into legal things... I would not worry now about it. That's is something we can always sort out with sed | 23:13 |
| danwent | agreed. | 23:13 |
| danwent | Ok, alex? | 23:13 |
| AlexNeef | There are different types of L2 we would like to support. Most obviously (for Mellanox) infiniband, but also people might what DCE/DCB to be able to do FCoE or other things. I need a mechaism to allow me to create a network with these capabilities. | 23:13 |
| *** RamD has left #openstack-meeting | 23:14 | |
| AlexNeef | i will send an email on this topic, it's not a quick thing i guess | 23:14 |
| danwent | yeah, but an important point to tackle. Sounds good Alex. | 23:14 |
| salv-orlando | Not, and probably related to the "core" definition issue | 23:14 |
| romain_lenglet | AlexNeef: isn't that possible with the current api proposal? | 23:14 |
| AlexNeef | I don't think so | 23:14 |
| AlexNeef | i need an indication from the VIFs of what their expected class of service is | 23:15 |
| salv-orlando | No, that's not possible. The current API only creates "dumb" networks :-) | 23:15 |
| romain_lenglet | and? | 23:15 |
| romain_lenglet | what's the limitation? | 23:15 |
| ecarlin | i think that should be abstracted by the quantum service | 23:15 |
| romain_lenglet | me too | 23:15 |
| salv-orlando | an "extension"? | 23:15 |
| ecarlin | you just get an l2 network, how the provider chooses to implement it is up to them | 23:15 |
| danwent | Alex: do you need more info from the remote-interface, it sounds like? | 23:15 |
| AlexNeef | you can't abstract something like "lossless" over a lossy network | 23:15 |
| ecarlin | you can't say give me a vmware or xenserver vm in nova | 23:15 |
| ecarlin | you just get what the provider has set up | 23:16 |
| danwent | ok, i think we've stumbled onto a bigger topic :) | 23:16 |
| AlexNeef | but you can say give me a 4 core vm | 23:16 |
| AlexNeef | or give me 5 gigs of RAM right | 23:16 |
| ecarlin | ok, so now we are talking about "flavors" of networks | 23:16 |
| troytoman | we did talk, at the summit, about networks having capabilities and needing some way to ID what those are | 23:16 |
| danwent | Alex: maybe try to handle this with extensions, or describe how extensions are insufficient? I don't think I fully understand the use case yet. | 23:16 |
| AlexNeef | The technical compute guys will say give me a lossless network | 23:17 |
| troytoman | you would either have to do it through a flavors mechanism or a more granular attribute level, I think | 23:17 |
| romain_lenglet | I think that can be expressed / controlled by extensions to the core api | 23:17 |
| somikbehera | +1 | 23:17 |
| AlexNeef | maybe | 23:17 |
| ecarlin | i think it can be an extension or just a property of a partcular quantum deployment | 23:17 |
| AlexNeef | you can do anything in extentions right | 23:17 |
| danwent | Alex: that's the hope :) | 23:18 |
| romain_lenglet | AlexNeef: yeah | 23:18 |
| somikbehera | yup, since you have to provide implementation backing it | 23:18 |
| jorgew | yea :-) | 23:18 |
| danwent | ok, so I think we're good? | 23:18 |
| ecarlin | the networks resource is L2 - that's all we are promising | 23:18 |
| romain_lenglet | the only thing at this stage is to make sure that the core api doesn't prevent anybody from implementing their own kind of networking, possibly with extensions | 23:18 |
| danwent | romain: yup, i agree with that goal. | 23:18 |
| romain_lenglet | and I think we meet that goal with the current proposal | 23:19 |
| danwent | ok, 20 minutes over time... we good to go? | 23:19 |
| danwent | #endmeeting | 23:19 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 23:19 | |
| somikbehera | agree there, i think we should freeze the current proposal to make progress on delivery | 23:19 |
| openstack | Meeting ended Tue May 24 23:19:29 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 23:19 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-22.01.html | 23:19 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-22.01.txt | 23:19 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-22.01.log.html | 23:19 |
| danwent | I did it! | 23:19 |
| danwent | :) | 23:19 |
| salv-orlando | Should we set up an etherpad for discussing thinks that did not made into today's meeting | 23:19 |
| danwent | Are the "topic" etherpads sufficient? | 23:20 |
| salv-orlando | like attributes of core resources | 23:20 |
| danwent | can that discussion happen on the core API etherpad? | 23:20 |
| salv-orlando | it's already a bit messy :-) | 23:20 |
| danwent | I also created an etherpad for extension mechanism discussion: http://etherpad.openstack.org/quantum-extensions | 23:20 |
| danwent | You can delete most of my stuff, as it has already been handled. Or maybe just create a "clean" section at the bottom? | 23:21 |
| ecarlin | where is the quantum api etherpad? | 23:21 |
| salv-orlando | Ok, let's go for the clean section. No point to add a new bookmark | 23:21 |
| danwent | http://etherpad.openstack.org/PbTpgXnnZZ | 23:21 |
| danwent | with easy to remember name :) | 23:21 |
| salv-orlando | sorry I did not know how to create etherpads with human names | 23:22 |
| danwent | I believe it is linked from the blueprint | 23:22 |
| salv-orlando | I believe that means quantum-api in klingon | 23:22 |
| danwent | yes, link is on: https://blueprints.launchpad.net/network-service/+spec/quantum-api | 23:22 |
| danwent | I will add a few copy/pastes from the meeting to the extensions etherpad. | 23:23 |
| danwent | see you all later :) | 23:23 |
| salv-orlando | bye all! | 23:23 |
| Sumit | bye | 23:24 |
| ecarlin | bye everyone! | 23:24 |
| *** Sumit has quit IRC | 23:24 | |
| ying | see you all | 23:24 |
| somikbehera | take care all | 23:24 |
| *** ecarlin has left #openstack-meeting | 23:24 | |
| *** jorgew has left #openstack-meeting | 23:24 | |
| romain_lenglet | bye | 23:24 |
| *** romain_lenglet has left #openstack-meeting | 23:24 | |
| *** ying has quit IRC | 23:25 | |
| *** somikbehera has quit IRC | 23:26 | |
| *** markwash_ has left #openstack-meeting | 23:28 | |
| *** Jamey_ has quit IRC | 23:33 | |
| *** midodan has quit IRC | 23:34 | |
| *** troytoman is now known as troytoman-away | 23:36 | |
| *** adjohn has quit IRC | 23:39 | |
| *** ryu_ishimoto has left #openstack-meeting | 23:39 | |
| *** littleidea has quit IRC | 23:41 | |
| *** Tv has left #openstack-meeting | 23:42 | |
| *** namaqua has joined #openstack-meeting | 23:45 | |
| *** jwilmes has left #openstack-meeting | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!