Tuesday, 2011-05-24

*** carlp has joined #openstack-meeting00:09
*** adjohn has joined #openstack-meeting00:38
*** dragondm has quit IRC00:51
*** Binbin has joined #openstack-meeting00:56
*** mattray has joined #openstack-meeting01:15
*** pvo has quit IRC02:33
*** mattray has quit IRC03:54
*** murkk has quit IRC04:11
*** anotherj1sse has quit IRC04:39
*** adjohn has quit IRC09:10
*** Binbin is now known as Binbingone10:19
*** mancdaz has quit IRC11:04
*** mancdaz has joined #openstack-meeting11:05
*** mancdaz has quit IRC11:07
*** mancdaz has joined #openstack-meeting11:09
*** dprince has joined #openstack-meeting12:52
*** dendro-afk is now known as dendrobates13:28
*** edconzel has joined #openstack-meeting13:42
*** mattray has joined #openstack-meeting13:46
*** edconzel has quit IRC13:47
*** edconzel has joined #openstack-meeting13:47
*** pvoccio_ has joined #openstack-meeting14:08
*** johnpur has joined #openstack-meeting14:15
*** jkoelker has joined #openstack-meeting14:25
*** dragondm has joined #openstack-meeting14:50
*** pvoccio_ is now known as pvo15:08
*** pvo has quit IRC15:15
*** pvo has joined #openstack-meeting15:15
*** mancdaz has quit IRC16:11
*** mancdaz has joined #openstack-meeting16:13
*** mancdaz has quit IRC16:15
*** mattray1 has joined #openstack-meeting16:17
*** mattray has quit IRC16:18
*** anotherj1sse has joined #openstack-meeting16:24
*** hub_cap has joined #openstack-meeting16:32
*** dendrobates is now known as dendro-afk16:35
*** dendro-afk is now known as dendrobates17:25
*** littleidea has joined #openstack-meeting17:47
*** hub-cap has joined #openstack-meeting18:07
*** hub-cap has quit IRC18:08
*** markwash has quit IRC18:09
*** hub_cap has quit IRC18:10
*** creiht has joined #openstack-meeting18:11
*** markwash has joined #openstack-meeting18:16
*** BinaryBlob has joined #openstack-meeting18:32
*** colinnich has joined #openstack-meeting19:02
*** littleidea has quit IRC19:21
*** eperdomo has joined #openstack-meeting19:58
*** dprince has quit IRC19:58
*** RamD has joined #openstack-meeting20:00
*** RamD has left #openstack-meeting20:02
*** troytoman-away is now known as troytoman20:03
*** bhall has joined #openstack-meeting20:04
*** troytoman has quit IRC20:24
*** troytoman-away has joined #openstack-meeting20:25
*** troytoman-away is now known as troytoman20:25
*** AlexNeef has joined #openstack-meeting20:30
*** jamesurquhart has joined #openstack-meeting20:31
*** alandman has joined #openstack-meeting20:35
*** danwent has joined #openstack-meeting20:35
*** salv-orlando has joined #openstack-meeting20:36
*** dabo has joined #openstack-meeting20:37
*** bcwaldon has joined #openstack-meeting20:41
*** masumotok has joined #openstack-meeting20:46
*** primeministerp has joined #openstack-meeting20:52
primeministerpgreetings programs20:53
*** masumotok has quit IRC20:53
*** dtroyer_ has joined #openstack-meeting20:53
*** summer has joined #openstack-meeting20:55
*** jwilmes has joined #openstack-meeting20:55
*** spectorclan_ has joined #openstack-meeting20:55
*** ying has joined #openstack-meeting20:58
*** primeministerp has quit IRC20:58
*** ameade has joined #openstack-meeting20:59
* creiht bows21:00
* dabo waves to ttx21:00
* _0x44 21:00
*** User has joined #openstack-meeting21:00
*** User has joined #openstack-meeting21:00
*** User has quit IRC21:00
* soren says hello21:01
*** Tushar has joined #openstack-meeting21:01
*** jaypipes has joined #openstack-meeting21:01
johnpurhi Jay!21:01
jaypipesjohnpur: hey :)21:01
ttxok, all PTLs are here, let's start then21:01
openstackMeeting started Tue May 24 21:01:37 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:01
ttxWelcome to our weekly OpenStack meeting...21:01
ttxToday's agenda lives at:21:01
ttx#link http://wiki.openstack.org/Meetings21:01
ttx#topic Actions from previous meeting21:02
*** openstack changes topic to "Actions from previous meeting"21:02
ttx* jaypipes to confirm the nobottle unblocking21:02
ttxjaypipes: nothing like getting actions assigned to you while you're not here :)21:02
jaypipesttx: heh21:02
jaypipesttx: sorry, have not checked that one.21:02
*** Sumit has joined #openstack-meeting21:03
ttxjaypipes: ok, just wanted to make sure that was unblocked, please reraise it if it's not21:03
ttx* ttx to crosspost assignee search to ML: done21:03
jaypipesttx: I'll check into it.21:03
ttx* soren to raise a thread on the python-openstack.compute jacobian situation21:03
ttxThis was done, but the thread died...21:03
sorenOh, did I?21:03
sorenOh, right, I did!21:03
ttxI think the conclusion was, since the current client needs to evolve in parallel to exhibit new Nova features...21:04
*** sirp__ has joined #openstack-meeting21:04
ttx...it's difficult to have it live outside our direct and timely control21:04
ttxThat said it still sucks to have two nearly-identical confusing projects.21:04
ttxCould 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 code21:05
ttxWho knows Jacobian better and could help in bridging the gap ?21:05
daboI 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 communication21:05
daboI know Jacob, and could talk with him21:05
ttxdabo: we still need to make quick updates to the client to exhibit new features21:06
dabottx: true, but that could be something we coordinate with the jacobian version.21:06
daboI don't think he would object to having the utility kept up-to-date21:07
ttxdabo: could you take the action of starting to bridge the gap ?21:07
*** RamD has joined #openstack-meeting21:07
ttx#action dabo to bridge the gap with jacobian and work towards a common client21:08
*** carlp has quit IRC21:08
ttxok, moving on21:08
ttx#topic General release status21:08
*** openstack changes topic to "General release status"21:08
ttxThe 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
ttxIf you have any remark or correction, please talk to me or corresponding PTL.21:08
ttxI 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.html21:09
ttxShould get more interesting with a bit more data collected.21:09
vishyttx: nice!21:09
ttxQuestions before we move to per-project status ?21:09
johnpurttx: can we get standardized reports for all the projects?21:10
ttxjohnpur: we could. It was more pressing for nova, given the recent bug inflation that I'm trying to flight21:10
ttxfight, even21:10
johnpuragree on the priority21:11
ttxbut I can have the same webnumbr set up for the others, sure21:11
ttx#action ttx to create webnumbrs for all core projects21:11
ttx#topic Nova status21:11
*** openstack changes topic to "Nova status"21:11
ttxThe first milestone is diablo-1, scheduled for Thursday, June 2nd.21:11
ttxThe 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
ttxLooking at the milestone status it appears we are still quite far from the objective:21:12
*** carlp has joined #openstack-meeting21:12
ttxThe only feature that was proposed for merging so far is snapshot-volume, but it is missing reviews...21:12
ttxSo please give some love to: https://code.launchpad.net/~morita-kazutaka/nova/snapshot-volume/+merge/6107121:12
ttxi see Vish looked into it very recently :)21:13
ttxclone-volume is ready but needs snapshot-volume to land first.21:13
ttxxs-multi-nic, xs-ovs, administrative-vms, nova-virtual-storage-array, integrate-nova-authn and unittest-examples are all planned to be proposed very soon21:13
ttxreference-architectures is a design/documentation effort, should be completed it time21:13
vishyyes, tr3buchet says multinic won't make it21:14
ttxkvm-pause-suspend is blocked on legal issues, might still make it21:14
vishybut should be in early in diablo-221:14
ttxvishy: ok, please move milestone if you haven't already21:14
vishyi did21:14
* ttx refreshes21:14
vishymight be best that way, so we have time to fix the stuff that it breaks21:14
ttxvishy: makes sense indeed.21:15
*** midodan has joined #openstack-meeting21:15
ttxxtoddx: how is provider-firewall doing ?21:15
vishyi asked him to propose it asap so that we can all start helping21:15
xtoddxttx, vishy: there is a patch to move libvirt into a directory21:15
xtoddxis that going to land first, or should mine?  we're going to have to work around each other somehow21:15
vishyxtoddx: do you have a link?21:15
vishyjust propose and we'll see who wins! :)21:16
blamar_xtoddx: Doesn't matter to me :) It's my change21:16
*** somikbehera has joined #openstack-meeting21:16
ttxpropose early, propose often :)21:17
vishyblamar_: why hasn't that merged yet?21:17
ttxso yours is ready, or almost ready ?21:17
ttxxtoddx: ^21:17
vishyblamar_: 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
bcwaldonbut, jaypipes matters!21:18
xtoddxmine is ready, though i haven't merged trunk recently21:18
bcwaldonjaypipes: you do, I swear!21:18
ttxvishy: I'll probably tweak the scoring on http://wiki.openstack.org/reviewslist/ so that it prioritizes the features that are targeted to the next milestone21:19
*** masumotok has joined #openstack-meeting21:19
xtoddxi'll make sure mine is ready and propose, and we'll let the chips fall how they may21:19
ttxIf anyone still uses that ;)21:19
bcwaldonttx: I do!21:19
xtoddxttx: link from http://wiki.openstack.org/Nova/ReviewDays21:19
xtoddxand i'll use it21:19
ttxbcwaldon: cool !21:19
ttxxtoddx: good point21:19
ttxvishy: lots of stuff targeted to diablo-2 now21:19
ttxvishy: 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 be21:20
vishyttx: yes, we will probably have to move some of the dependent stuff21:20
ttxQuestions for the Nova PTL ?21:20
jaypipesvishy: hey, when is local image service going bye bye?21:20
markwashand when that happens, can we ditch the base class too?21:21
vishyblamar_: seems fine, I'm still annoyed by virt not using import_object but whatev21:21
vishyjaypipes: is it going away?21:21
vishyjaypipes: are we just going to default to glance?21:21
jaypipesvishy: well, Glance already has a local image service ;)21:21
jaypipesvishy: it's Filesystem backend...21:21
blamar_vishy: lots of good changes for libvirt coming once I can get some code separation21:22
xtoddxi think the issue would be ec2 compatibilty layer only being half-way complete then21:22
vishyxtoddx: no it works fine with glance21:22
jaypipesvishy: 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
vishyjaypipes: i'm just a little worried about having to configure glance to get it working, but as it is relatively easy I don't mind21:23
jaypipesvishy: no configuration besides the existin glance_host and glance_port.21:23
vishyjaypipes: it messes up venv install i think21:23
ttxsoren: we need to track that, since Ubuntu will want to default on Glance too21:23
jaypipesvishy: ok, we can take it offline. sounds like something we can work towards at a low priority.21:23
ttxjaypipes, vishy: do we need/want a blueprint for that migration ?21:23
vishyjaypipes: cool21:23
jaypipesttx: good idea, yes21:24
ttxcould help for downstream to track when it lands21:24
ttxjaypipes: you create it ?21:24
jaypipesttx: sure21:24
jaypipes#action jaypipes to create removal of local image service blueprint21:24
markwashvishy: the venv is for unit testing though, right?21:24
markwashvishy: so we shouldn't need a real image service anyway21:24
*** ryu_ishimoto has joined #openstack-meeting21:25
ttxcan we move to Glance and Swift ?21:25
markwashttx: sorry, sure21:25
* ttx thiks he should reorder the topics21:25
ttx#topic Glance status21:25
*** openstack changes topic to "Glance status"21:25
ttx(since glance and swift usually don't generate so much discussion)21:25
ttxYour first milestone (diablo-1, also June 2nd) looks in good shape: 2 merged, 1 proposed.21:25
jaypipeswe're on target to cut diablo-1 with the currently targeted features and bug fixes.21:26
jaypipeshammering out a couple remaining issues around results pagination, but I don't foresee too many issues in meeting June 2nd deadline21:26
jaypipesI'll be focusing entirely on bug fixes this coming week while bcwaldon finishes the little work left on pagination.21:26
ttxjaypipes: do you want a release branch cut on Wednesday morning ?21:27
jaypipesthere's a couple outstanding SQLalchemy migrate bugs that are annoying, as always.21:27
jaypipesttx: yes please21:27
ttxAnything else on/for Glance ?21:27
jaypipesother 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-meeting21:28
markwashjaypipes: did you see my email about pagination this afternoon?21:28
jaypipesmarkwash: yeppers. I'll ping you in a bit.21:28
markwashjaypipes: gotcha, thanks21:28
jaypipesttx: that's it for us.21:28
jaypipesanybody have any questions for us?21:29
ttx#topic Swift status21: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
jaypipesblamar_: it's integration around the API, so no... :)21:29
blamar_jaypipes: Good thing the API is stable and decided? :)21:30
blamar_ttx: apologies21:30
jaypipesblamar_: heh, well, you know what I mean...21:30
ttxno problem :)21:30
jaypipesblamar_: we focus on the spec versus the implementation.21:30
ttxnotmyname: Hi! So the first milestone for Swift is 1.4.0, on May 31.21:30
johnpuranotherj1sse: what is the progress on pushing the keystone project foward21:30
notmynameyes it is21:31
ttxjohnpur: please raise in open discussion21:31
ttx6 blueprints targeted: 5 merged and 1 proposed, looks good21:31
notmynamewe are currently doign QA work for 1.4.0. It should be ready21:31
notmynamethe one that hasn't merged yet will be removed21:31
ttxnotmyname: 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
notmynameand not be in 1.4.021:31
ttxoh, ok21:32
notmynameyes. we will bump the version to only have one 1.4.021:32
ttxnotmyname: any other announcements or comments ?21:32
notmynamefuture plans:21:32
notmynameprobably in this next milestone:21:32
notmynameto remove swauth and the stats/loggin stuff currently in swift to be in separate projects21:33
jaypipesnotmyname: can we get swift to make toast yet?21:33
notmynamethis will allow for independent release cycles and further show that they are good examples, not always recommended for every production use21:33
creihtjaypipes: for certain selections of server chassis, yes :)21:34
ttxOther questions for the Swift team ?21:34
*** mattray1 has quit IRC21:34
ttxThen raise you hand before I switch to next topic :)21:34
ttx#topic Open discussion21:35
*** openstack changes topic to "Open discussion"21:35
ttx<johnpur> anotherj1sse: what is the progress on pushing the keystone project foward21:35
* jaypipes would like to hear from mtaylor about CI21:35
johnpuror any of the keystone folks21:35
ttxjohnpur: from where I stand there is a first nova integration step targeted to diablo-1, assigned to Titan team21:35
johnpurttx: the reason i ask is the point that was brought up earlier21:36
johnpurthere is assumptions on integration21:36
ttxjaypipes: the magic QA setup that tests everything and ensures nothing ever breaks was targeted to diablo-1, but won't make it21:36
johnpurhowever, we need to get keystone recognized as a project21:36
ttxjaypipes: for more detail, see mtaylor :)21:37
jaypipesjohnpur: I think that is outside the scope of this meeting, to be fair.21:37
johnpurnova, swift, and glance should be integrated near the second miletsone21:37
blamar_johnpur: Isn't that just a vote somewhere?21:37
johnpurjaypipes: ok21:37
jaypipesblamar_: bit more involved than that :)21:37
johnpuri just get too excited, i guess :)21:37
jaypipesjohnpur: :)21:37
ttxany other topic / question ?21:38
*** Tv_ has joined #openstack-meeting21:39
jaypipesantonym: how's the racker setup testing going? comstud and soren seemed to have fixed the eventlet issues?21:39
jaypipesantonym: have we run into more concurrency issues?21:39
pvostill seeing some issues, not sure if they're eventlet or not.21:39
ttxnotmyname, 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
jaypipespvo: k21:39
notmynamettx: good with me21:39
jaypipesttx: no probs with me.21:39
antonymjaypipes: working on it right now, about to get some scale tests going again once i get past some hiccups with builds21:39
* vishy makes a note to show up at 2:3021:40
jaypipesantonym: cool, good to know.21:40
notmynamevishy: like I do now? ;-)21:40
mtaylorjaypipes: aroo?21:40
jaypipesmtaylor: just wondering on progress with the smoketesting stuff21:40
westmaasttx: do dev teams have any special responsibilities around milestone releases outside of getting things in before tuesday EOD?21:40
ttxwestmaas: no21:40
westmaasttx: cool, thanks21:41
ttxwestmaas: work on targeted bugs... but we haven't so many of them in the first milestone21:41
mtaylorjaypipes: first step "works" on jenkins... second step needs to clean up the first step (which is what I'm on right now)21:41
ttxwestmaas: and usually part of the milestone-targeting process is to ensure you have someone committed to fixing the bug21:41
jaypipesmtaylor: k. what about the hardware that you and letterj were working on?21:41
mtaylorjaypipes: 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 tarmac21:41
ttxwestmaas: 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
mtaylorjaypipes: 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 hardware21:42
westmaasttx: is that a bad thing?21:42
mtaylorjaypipes: (starting small and getting bigger)21:42
ttxwestmaas: it's surprisingly ineffective.21:42
jaypipesmtaylor: k. good to know. thx for the update.21:42
vishymtaylor: 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 failing21:42
sorenttx: lol21:42
mtaylorvishy: I can stop the script from deleting the cloud servers when it's done21:43
vishymtaylor: cool, i think it is probably just a couple of config changes21:43
mtaylorvishy: and then give you access to that21:43
*** spectorclan_ has quit IRC21:43
vishyis the stuff that provisions the cloud server and installs nova checked in somewhere?21:44
mtaylorvishy: sweet - I was also going to start working through the chef recipies to see what they are doing that I'm not doing21:44
vishyin case we need to edit it?21:44
mtaylorvishy: no, it's just in jenkins right now21:44
mtaylorvishy: it's all in the jenkins config page21:44
vishymtaylor: ok21:44
vishymtaylor: is that visible publicly? or do i need a login?21:44
mtaylorvishy: http://jenkins.openstack.org/job/nova-smoketests/configure21:45
mtaylorvishy: 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 that21:45
* mtaylor mutters about data on web forms..21:45
jaypipesmtaylor: I heard github can store code for you in a version control system.21:45
* jaypipes runs and hides21:46
ttxjaypipes: sounds cool21:46
sorenjaypipes: I see what you did there.21:46
markwashI'm really excited about the things we can do after multinic. . what's the progress there? anything we can help with?21:46
mtaylorjaypipes: sure it can - but can it store the sub chunk of an xml config file?21:46
jaypipestr3buchet: ^^21:46
mtaylorjaypipes: in a way that's sensible for the jenkins interface (/me may need to have to write yet-another jenkins plugin)21:47
ttxmtaylor strickes back jaypiipes using XML21:47
ttxoo, that went bad.21:47
* jaypipes lashes out with JSON fireball.21:47
jaypipesalright, this is getting out of control. :)21:47
* ttx uses a shield of YAML.21:48
* mtaylor just pukes on people21:48
jaypipesdo we have any more pressing business? I think the Network (quantum) folks may have a meeting next here?21:48
_0x44Did someone order this pile of CSV?21:48
ttxok, let's leave the room to the network dudes21:49
ttxand continue discussion on #openstack21:49
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"21:49
openstackMeeting ended Tue May 24 21:49:26 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:49
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-21.01.html21:49
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-21.01.txt21:49
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-21.01.log.html21:49
*** bcwaldon has left #openstack-meeting21:49
ttxdendrobates: room is yours.21:49
tr3buchetjaypipes, markwash: status is a few remaining api changes, following by getting the code coverage up and it's ready for some hellish nitpicking21:49
danwentttx: "network dudes"... I like that :)21:49
dendrobatesttx: thanks.  Sticking around?21:50
ttxdanwent: magic packets21:50
* tr3buchet puts on his wizard hat and robe21:50
ttxdendrobates: you know what time it is ?21:50
zultime to get ill?21:50
dendrobatesttx: I do21:50
ameadeHAMMER TIME21:50
dendrobatestime after time21:50
ttxit's well past beer time over here21:51
tr3buchetoh sweet, i've been needing to use the parachute pants for something21:51
ttxdendrobates: but I'll read the logs21:51
dendrobatesI don't think France celebrates Beer time.21:51
ttxdendrobates: consider I'm with you in spirit.21:51
Tv_wine time?21:51
*** alandman has left #openstack-meeting21:51
*** alandman has quit IRC21:51
markwashdendrobates: you should have some saison21:51
tr3buchetmarkwash: you can definitely give some constructive criticism when the merge prop gets out21:51
ttxTv_: it's about Cognac time.21:51
*** BinaryBlob has quit IRC21:51
Tv_true, true21:51
*** Tv_ is now known as Tv21:52
markwashtr3buchet: cool, I'd love to see a list of the "few remaining api changes" :-)21:52
dendrobatesmarkwash: I'll look for it on my next trip21:53
tr3buchetmarkwash: add extra IPs to instance, add additional network to project. actually a couple, not few. Both I plan on adding to compute API21:53
*** littleidea has joined #openstack-meeting21:54
* markwash races home before the networking meeting starts21:55
*** ameade has quit IRC21:56
*** ecarlin has joined #openstack-meeting21:58
dendrobatesI have to leave in 30 min.  Can someone else run meetbot?22:00
danwentis that how?22:00
danwentirc newbie :)22:00
*** masumotok has quit IRC22:00
openstackMeeting started Tue May 24 22:01:02 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.22:01
dendrobatesw/o the dash22:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.22:01
danwenthaha, thank god rick is running things :)22:01
*** adjohn has joined #openstack-meeting22:01
salv-orlandoHi everybody22:01
troytomanhello all22:01
dendrobatesthe agenda is here:  http://wiki.openstack.org/Network/Meetings22:01
somikbeherahi everybody22:01
*** romain_lenglet has joined #openstack-meeting22:01
AlexNeefhi all22:02
danwenthi folks.  want to introduce brad, a new guy on our team from nicira22:02
danwent(not new to nicira, but new to netstack)22:02
danwentbrad, you there?22:02
danwentmaybe i need to go over to his cube and kick him.22:02
dendrobatesattendance fail  :)22:02
bhallI'm here :)22:03
salv-orlandopoor brad22:03
danwentone more and its a fail hat trick for me22:03
bhall(no kicking necessary)22:03
bhallhi everyone..22:03
salv-orlandoI hope Dan does not kick like Chuck Norris22:03
danwentok, if rick needs to run in 30 mins, let's try to get things started, shall we?22:03
danwent#topic extensions22:03
*** openstack changes topic to "extensions"22:03
ecarlinstanford people don't kick like chuck norris :-)22:03
danwentso, I think the main question is how do we let plugins expose non base capabilities22:04
yingbefore talking about data extensions, shall we talk about data attributes in core API?22:04
danwentah, you mean like id, name, date_created?22:04
yingas the extension is something beyond that22:05
AlexNeefdid we agree to use the /cap/{key} mechanic in the api?22:05
danwentAlexNeef, let's save that for the next discussion (even if the core concept itself is not an extension)22:05
romain_lengletI don't think so22:05
danwentok, ying, are you proposing some additional fields for the base beyond what was in salvatore's spec on the wiki?22:06
danwentI think that included and id,name for networks, and an id for ports?22:06
AlexNeefok - I did update a lot of the base attirbutes22:06
yingnot put on the wiki yet,it here http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view&target=quantum_api_extension.pdf22:06
*** creiht has left #openstack-meeting22:06
yingyes, I saw Alex's updates22:06
AlexNeefI'm not sure people saw that: http://wiki.openstack.org/QuantumAPISpec22:07
*** markwash_ has joined #openstack-meeting22:07
AlexNeefI wanted to get the ball rolling thinking about the data attributes22:07
romain_lengletcan somebody explain me again why we have to replace API extensions with extensible data attributes?22:07
yingwe need to make sure that we agree all the base attributes in the core API22:07
yingthen, we can see what needed for extension22:07
danwentromain: I don't think we have to, but that is part of the next discussion.22:08
romain_lengletgood, let's discuss that22:08
salv-orlandoAgree 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
danwentthat is exactly what I was typing :)22:08
danwentin my mind, the entire API is still experimental22:08
*** summer has quit IRC22:09
danwentso 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
dendrobatesso everyone wants to discuss the extension mechanism now?22:09
danwentif ying is ok with it, I would suggest doing so.22:09
somikbeheramarkwash_ : some of us have and hopefully we are going to discuss nova/openstack extension mechanism here too and may use them22:10
yingso we are clear about the data attributes?22:10
danwentOk, extensions.22:10
danwentso I believe we are planning on using Openstack standard extension mechanisms.22:10
danwentor at least we'll work with jorge to identify whether they are suitable.22:10
dendrobatesI think we should use them and suggest modifications if we find shortfalls22:11
jamesurquhartJust to be clear, though, the "standard" hasn't been officially blessed yet, right?22:11
danwentOk, so it seems to me that openstack extensions let us add attributes to any of the network or port objects using the data extension mehcanism22:11
dendrobatesjamesurquhart: right, but nearly22:11
danwentjames: yes, we can still help improve the standard.22:12
danwentif it is lacking22:12
AlexNeefI'm not sure i understand what that really means tangibly22:12
danwentwe will also need to consider how to add additional API methods and API objects (i.e., go beyond data extension).22:12
AlexNeefis the standard extention model in some type of contradiction with yings model?22:12
danwentAlexNeef: clarify?22:12
ecarlina draft of the extensions guide is happening as we speak and will be submitted to the policy board soon for final approval22:12
danwentAlex: I don't think so.22:12
yingI think they are converging22:12
yingstandard mechanism defines how to define and discovery the extension22:13
danwentSo the work item I was proposing around quantum-extensions is not so much defining what is or is not an extension22:13
yingit has data extension part, we can use that for key value model22:13
romain_lengletdanwent: +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
danwentbut rather the mechanisms by which plugins can expose extensions.22:13
ecarlinif 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
danwentromain: I think that is an interesting point.  One could argue that data extension is not the right way to do at all.22:14
danwentthis is a good discussion to have.22:14
ecarlinthe extension model supports additional api operations22:14
markwash_so, I definitely like jorge's extensions model, but it didn't seem to be built for yings use case precisely22: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
yingyes, I agree. we can use it for my key value model22:15
danwentmark: yes22:15
dendrobatesdoes everyone understand ying's use case?22:15
somikbeheraI 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
danwentromain: where you advocating for an approach that limits what extensions are considered "valid" to only using new API objects + methods?22:15
jamesurquhartdendrobates: My question as well22:15
romain_lengletdanwent: both approaches are dual22:16
romain_lengletbut I feel we'll need extra methods in extensions anyway22:16
danwentromain: agreed.22:16
romain_lengletso we could just go all with extra methods22:16
danwentromain: would that be excluding the "data extension" approach?22:17
yingmy understanding is that extra methods go with the extended resources22:17
somikbeherai like that as then its clear from API who is adding those methods as they can be in a separate rest namespace22:17
yingby adding new resources, we can add new methods22:17
somikbeherawhile with data attributes, the namespace gets polluted with standard namespace.22:17
danwentying: can you define "resources" ?  you're not talking about a URI, are you?22:18
yingresource is the subject in the web service, like network, port ,etc22:18
danwentyes, ok.22:18
*** dtroyer_ has quit IRC22:18
romain_lengletwe'll need extra methods on ports, networks, etc.22:19
romain_lengletnot merely on new resources22:19
yingromain: could you give soem example?22:19
danwentI think adding new methods need to be in scope.22:19
danwentas well as adding new resources.22:19
AlexNeefwhats a new resource?22:20
jamesurquhartdanwent: But not new data attributes? (Just trying to get this debate clear in my head)22:20
danwentTo 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-meeting22:20
danwentport and network is a "resource"22:20
danwentin the base API.22:21
danwentJames: does that answer your question?22:21
AlexNeefSo I can create an extention with additonal types of resources like "MyPort"22:21
jamesurquhartdanwent: sort of. I'll "listen" further for a bit… ;)22:21
danwentI think the "data extension" mechanism would let you add new key-values to the existing Port object.22:21
salv-orlandoWhy 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
AlexNeefThat seems like we will break introperability quickly22:22
danwentI believe we are discussing whether this should be allowed.22:22
*** mattray has joined #openstack-meeting22:22
AlexNeefsalv: good idea i need to anchor this concept somewhere22:22
yingsalv: that's my initial question22:22
yingdo we need to have any cap in the base API?22:22
RamDSalv: this is more like port-profile in our proposal22:23
AlexNeefSo i vote for capabilties as a comonent of an existing resource22:23
AlexNeefi.e. port/cap/22:23
danwentI 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
danwentor the ability to put a port in "Admin down" state.22:23
RamDYes. port-profile kind of constructs provide "grouping" them eg ACL across # of Port resources22:24
yingAlex: you mean cap is attributes with base resource port?22:24
*** johnpur has quit IRC22:24
AlexNeefOne 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 with22:25
somikbeheraI think we can easily dop port profiles, cap etc. using Jorge's extension mechanism.22:25
salv-orlandoI 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 separate22:25
somikbehera*easily do22:25
danwentport-profile imply a template, no?22:25
danwenti.e., something that can be applied to many ports?22:26
salv-orlandodanwent: I think so...22:26
danwentto me that is a somewhat different discussion.22:26
AlexNeefagree - theres no implied coupling between an actual port22:26
yingone to many22:26
RamDport-profile is a set of attributes that can be applied to many ports22:26
RamDe.g. Same ACLs for # of ports22:27
dendrobatesying: should that exist in Donabe instead?22:27
danwentso the ACL itself is not an attribute of the port with a port-profile, is that correct?22:27
danwentdendrobates: I was thinking along similar lines.22:27
yingit's associated with port, hence, I think it belongs to quantum22:28
jamesurquhartdendrobates:  different than network container. more a "grouping" like a role22: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 time22:28
RamDYing +122:28
markwash_somikbehera: but we are all talking about these things like some set of quantum plugins will probably need to use them22:28
danwentcould we focus on a simpler use case for a second?22:29
AlexNeefying: i disagree, many other services will make use of quantum components without being owned in the base api22:29
danwentlike wanting to expose statistics on a port as an extension?22:29
salv-orlandodanwent: If you have it shoot!22:29
danwentthe port-profile case (while potentially valuable) actually conflates several unresolved issues in my mind.22:29
*** mattray has quit IRC22:30
somikbeheramarkwash_:  not all plugins but some plugins may use/implement the adavanced functionality22:30
salv-orlandoOk, let's analyze statistics use case, from an API user perspective22:30
danwentone way to do it would be to use data-extension to expose a "statistics" field in the port object itself.22:30
danwentanother way would be to add a new URL: /network/<id>/port</id>/stats22:31
salv-orlandoIf a user wrote a client app which fetches statics using /port/statistics that would be quite easy and natural22:31
AlexNeefstatistics are a good case because in addition to reading them i may also want to clear them22:31
somikbeheramarkwash_ : therefore we could have the advanced stuff be extensions22:31
danwentor /port-stats/<id>22:31
*** edconzel_ has joined #openstack-meeting22:31
yingalex: disagree with whether we need port profile here?22:31
*** edconzel_ has quit IRC22:31
salv-orlandobut the user would not be aware of the fact that "statistics" is an extension22:31
dendrobatesguys 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 webex22:31
ecarlinyou would do that as /v1/networks/{netid}/ports/{portid}/ext/{vendor-id}/statistics22:31
danwentby rick!22:32
ecarlinyou would know it's an extensions because of the URI22:32
ecarlinplus all extensions are queryable22:32
danwentin theory, i think all of those mechanisms would be supported using openstack extensions.22:32
salv-orlandoecarlin +122:32
markwash_danwent: I agree that they can be supported using the openstack extensions mechanism22:32
markwash_danwent: I think the question is, are they general enough to not require the extensions mechanism?22:33
danwentI 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
AlexNeefwhich would allow us a base set of stats with the option to extend by vendor if we want22:33
markwash_danwent: apologies if I'm off base22:33
salv-orlandoSame URI structure could be used also for new resources e.g.: v1/ext/{vendor-id}/strangeresource22:33
*** edconzel has quit IRC22:33
danwentmark: not sure I following your last question.  can you clarify?22:34
yinglet's take statistics use case, we first define an extension: statistics, then later we want to extend statistics by adding new stat attributes22:34
danwentErik, 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 api22:34
yingis 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 case22: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 down22:35
markwash_danwent: I love punting on fourth down22:35
markwash_danwent: but I'd rather see if it fits in core first22:35
ecarlinthe idea is to keep core universally applicable, i.e. it should work with every plugin22:35
ecarlinif everyone supported port statistics, we could make it core22:35
ecarlinif not, if would be an extensions22:35
danwentmark: Our motivation was to get the core L2 functionality out first.22:35
ecarlinover time, if that became "standard", it would get promoted to core22:36
danwentmark: then aggressively promote.22:36
markwash_ecarlin: so different vendor supplied statistics packages, with the same interface, would still have different urls?22:36
ecarlinwe should guard core and keep it universally applicable22:36
markwash_ecarlin: and different attribute names in existing objects?22:36
danwentmain goal is to get a simple "core" out, without months of discussion of what is or is not in core22:36
danwentL2 connectivity only seemed like a very simple line to draw.22:36
AlexNeefso 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 valuable22:36
AlexNeefeven if we only define a really small set of base stats or capabilities22:37
ecarlinmarkwash: no, there are multi-vendor extension prefixes so the URI can be the same22:37
somikbeheraAlexNeef: the same can be achieved via an extension till the exntension gets universally accepted.22:37
markwash_ecarlin: okay cool22:37
ecarlinthis is exactly how OpenGL works which is where Jorge derived this approach22:37
jamesurquhartdanwent: 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
danwentQoS, ACLs, etc.  all seemed to get people very excited and wanting to go in different directions.22:37
danwentWe had to spend a lot of time to get people to just settle on tackling L2 connectivity.22:38
danwentso we went with a model where people could go do anything they wanted, as long as it started out as an extension.22:38
jamesurquhartOK, 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 now22:38
danwentthen once we got the base in place (still as an experimental-only solution), we could tackle advanced APIs.22:39
ecarlinI 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 code22:39
ecarlinif people want to support more now, go for it, that's what extensions are for, but i would vote to keep core simple for starters22:39
ecarlini think this is much broader than quantum22:40
jamesurquhartecarlin: We should, however, acknowledge that there are tradeoffs for things we know are *likely* to be common in future22:40
AlexNeefecarlin: I agree in concept, but think there are some peices that are reqruired for basic cfunctionality that are missing22:40
ecarlinacross any service, plugins should be able to expose capablities in consistent ways22:40
ecarlinwe need a framework for that that all services can utilize22:40
AlexNeefstatic capabilities are an example22:40
yingso, what should we include in core? it's still my question?22:40
jamesurquhartecarlin: Sure. Not sure that is what is being debated at this point.22:40
danwentto 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 call22:42
jamesurquhartdanwent: +1, but once solved it quickly exposes base vs. extension issue22:42
danwentthe 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
somikbeheraying: salvateore has a core API spec up for review for a few weeks that defines the agreement on core from summit.22:42
RamDI 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
danwentI 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
RamDdanwent: Agree lots of unknown for me22:43
yingsomikbehera: 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
danwentI think in the absence of agreement here we have to stick to what we outlined at the summit.22:44
yingfor example, network has name, id, port has state22:44
salv-orlandoWe have two rather orthogonal discussion: properly defining the core and a mechanism for extending it22:44
*** sirp has left #openstack-meeting22:44
salv-orlandoWhile the former is pretty much "blurred" at the moment as mark pointed out we can start doing progress on the second22:44
jamesurquhartsalv-orlando: +122:45
danwentI think salv-orlando is very close to having a first cut of the base networks + port code ready.22:45
RamDYep..that's why Ying started it with that22:45
salv-orlandoWhile a team adds the extension middleware, we can all together discuss the nature of the core22:45
markwash_apologies if I have derailed things :-/22:45
danwentwe 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-orlandoand then what is core will be handled by the API I'm already implementing, and what is not core goes through the extension mechanism22:46
danwentmark: healthy discussion :)22:46
somikbeheraproperly 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-orlandomarkwash_: you were suggesting before your code (API serialization?) can be helpful for us. In which way?22:46
Sumitas far as the base spec is concerned, the point of discussion is more about what are the attributes of the resources22:47
ecarlinfolks, i'm talking to jorge on the phone.  he is going to join in a minute to address extensions questions.22:47
salv-orlandosomikbehera: +122:47
Sumiti dont think we nailed them down during the summit22:47
danwentecarlin: great, thanks22:47
Sumitif we know what the attributes are, we can accordingly definer relevant operations/API22:47
ecarlinhe said nova is working on a way to have plugins auto register api extensions22:48
salv-orlandoI suggest moving the discussion on attribute to etherpad, and then discuss it next week22:48
Sumitnot to say that what is being currently proposed is not correct22:48
danwentThe focus on L2 connectivity was a pretty strong theme of the summit22:48
markwash_salv-orlando: what ecarlin just said ^^22:48
danwentwhile 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-afk22:48
danwent(it was just that everyone's list of what else to add to the base was different)22:49
danwentecarlin: very cool.22:49
danwentso are we waiting on jorge?22:49
ecarlinhe is joining...22:50
*** sirp__ has quit IRC22:50
danwentI personally thing that extensions are a great way to "prototype" a proposal for base, as it is a very concrete proposal.22:50
*** jorgew has joined #openstack-meeting22:51
danwentother 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
danwenteverything is still completely experimemental, but you have to start somewhere :)22:51
danwenthi jorge :)22:52
jorgewHey guys22:52
somikbeheraanybody who has questions/confusion regarding the extension mechanism, should check jorge's presentation from the summit.22:52
yingJorgew:a question about extension mechanism? For data extension, can we use it to extend an existing extension?22:52
jorgewnot sure I follow — can you ellaborate22:53
yingFor 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
yingOr, 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 runs22:54
jorgewTypically Yes that means a different extension22:54
jorgewbut really22:54
jorgewit depends on what you client support is22:54
markwash_ying: to clarify I was answering "can we". whether or not it is the right choice probably depends on the specific situation22:55
jorgewthe correct thing to do is to define anothor one.22:55
ecarlinand would it supersede the previous extension?22:55
yingyou mean define another extension with the same name "statistics" to supersede previous one?22:56
jorgewRight. It can — you can have both extensions simultaneously though i'm not sure that makes sense22:56
RamDHow "versioning" is handled? more in lines of compat.22:56
ecarlinjorge: do you recommend putting a version in the extension name?22:57
*** jkoelker has quit IRC22:57
jorgewI would call it statistics2  that's whats typically done in gl22:57
jorgewbut that said it's a different extension22:57
yingif that's the case, does it mean we won't use "data extension" independently? It always come alone with an resource extension?22:57
RamDIs this where key-value pairs have value22:57
somikbeheraying: correct, as its cleaner and we know which extension added what22:58
jorgewying: no it doesnt mean that though — you can extend the data without adding new resources22:59
danwentOk, 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-orlandoSounds fair to me22:59
danwentI'm looking for "-1"'s at this point.  Anyone disagree?23:00
yingnot debating, just want make sure that we can use data extension independently23:00
jorgewKeep in mind that params are also valuable23:00
danwentjorge: can you clarify?23:00
danwentadding params to existing resources?23:00
markwash_GET /networks?rax-pie:extendedparam=foo23:00
jorgewfor example to implement queries and filters23:00
yingbecause to extend <key, value> list, we may not want to re-define the statistics again23:00
danwentMark: ah, great point23:01
danwentok, so add in the ability to handle extensions in parameters.23:01
danwentOk, so I think we're all on the same page.23:01
ecarlinjorge, am i correct that all extensions (data, resources, params, headers, mime-types, etc.) are independent23:01
danwentother than webex, which we'll handle via email, are there other topics to cover?23:02
yingthen, the discovery is independent, too.23:02
danwentwebex = discussing hold and recording meetings over webex23:02
yingthus, it's client to match them together?23:02
yingbased on version?23:03
ecarlinall extensions can be queried and have specific meaning23:03
salv-orlandodanwent: agenda says "Quantum dev status" and "Open discussion"23:03
jorgewright they are dependant on version23:03
ecarlinextensions are independent of the api version, afaik23:03
danwent# quantum-dev23:04
jorgewno extensions are at the vesion level23:04
danwent#topic quantum-dev23:04
*** openstack changes topic to "quantum-dev"23:04
danwentman, we need rick :)23:04
salv-orlandoyou had your hat-trick :-)23:04
ecarlinah, yes23:04
jamesurquhartCongrats, Dan ;)23:04
ecarlinbecause it's past version in the uri23:04
danwentI 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
danwentjames: one of my few talents :)23:05
danwentother quantum dev updates?23:05
jorgewright an extension in ver 1 may be a core feature in ver 223:05
danwent#topic open-discussion23:05
*** openstack changes topic to "open-discussion"23:05
salv-orlandoquantum dev update: API getting in space, code infrastructure "borrowed" from Openstack API23:05
AlexNeefI wanted to mention I added a port state concept to the wiki23:06
AlexNeefi was looking for feedback23:06
salv-orlandoYes Alex I saw that and I'm considering it globally accepted.23:06
troytomanjust want to highlight the etherpad on network flows: http://etherpad.openstack.org/network-flows23:06
salv-orlandoat least that what it looked like on the etherpad23:06
danwentAlex: 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
danwentto -> two23:06
SumitI wanted to bring up the topic semantics of "attachments/attach"23:07
troytomanI am concerned that we don't have a consistent picture of how Nova/Quantum/Melange interact and what data is passed between services23:07
salv-orlandoyeah I wanted to discuss that as well23:07
troytomanplease chime in there if you have some thoughts23:07
Sumithave posted the question on etherpad, may be we can continue the discussion there or over emails?23:07
salv-orlandotroytoman: Sure23:07
danwentsumit:  on API etherpad?23:07
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 nics23:08
danwentok, sounds good.23:08
salv-orlandoSumit: I'm ok with discussing it here, but we are already 8 minutes overtime23:08
Sumityeah no worries, we can take it offline23:08
troytomanI've also added a strawman flow for the 3 services at the use cases wiki: http://wiki.openstack.org/NetworkUsecases23:08
Sumitwould request input though23:09
troytomanposted it there so we could look at a diagram23:09
troytomanjust one idea - will look forward to the discussion throughout the week23:09
danwentok, sounds good troy23:09
danwentI will definitely take a look and give feedback.23:09
danwentany other topics for open discussion?23:10
salv-orlandoSilly question on code development:23:10
AlexNeefI had one other open topic: that I was trying to address through capabilities but maybe people have other ideas23:10
danwentsalv was first :)23:10
salv-orlandothis is quick23:10
salv-orlandoWe are borrowing a lot of code from nova. What about authorship and copyright?23:10
salv-orlandoif we take for instance nova.wsgi and make it quantum.common.wsgi should the file be still copyright of "Openstack LLC"?23:11
danwentalex: can you pre-type?23:11
danwentyeah, I had asked Rick about that earlier.23:11
danwenthe said there is no clear right answer.23:11
danwentmight thought is that if you borrow a whole file from someone, probably keep the copyright.23:12
danwentif you think you'll end up filling most of the file, change it.23:12
danwentthat is what I do, but is by no means legally informed23:12
danwentany lawyers on the channel?23:12
salv-orlandoI'm really not into legal things... I would not worry now about it. That's is something we can always sort out with sed23:13
danwentOk, alex?23:13
AlexNeefThere 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-meeting23:14
AlexNeefi will send an email on this topic, it's not a quick thing i guess23:14
danwentyeah, but an important point to tackle.  Sounds good Alex.23:14
salv-orlandoNot, and probably related to the "core" definition issue23:14
romain_lengletAlexNeef: isn't that possible with the current api proposal?23:14
AlexNeefI don't think so23:14
AlexNeefi need an indication from the VIFs of what their expected class of service is23:15
salv-orlandoNo, that's not possible. The current API only creates "dumb" networks :-)23:15
romain_lengletwhat's the limitation?23:15
ecarlini think that should be abstracted by the quantum service23:15
romain_lengletme too23:15
salv-orlandoan "extension"?23:15
ecarlinyou just get an l2 network, how the provider chooses to implement it is up to them23:15
danwentAlex: do you need more info from the remote-interface, it sounds like?23:15
AlexNeefyou can't abstract something like "lossless" over a lossy network23:15
ecarlinyou can't say give me a vmware or xenserver vm in nova23:15
ecarlinyou just get what the provider has set up23:16
danwentok, i think we've stumbled onto a bigger topic :)23:16
AlexNeefbut you can say give me a 4 core vm23:16
AlexNeefor give me 5 gigs of RAM right23:16
ecarlinok, so now we are talking about "flavors" of networks23:16
troytomanwe did talk, at the summit, about networks having capabilities and needing some way to ID what those are23:16
danwentAlex: 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
AlexNeefThe technical compute guys will say give me a lossless network23:17
troytomanyou would either have to do it through a flavors mechanism or a more granular attribute level, I think23:17
romain_lengletI think that can be expressed / controlled by extensions to the core api23:17
ecarlini think it can be an extension or just a property of a partcular quantum deployment23:17
AlexNeefyou can do anything in extentions right23:17
danwentAlex: that's the hope :)23:18
romain_lengletAlexNeef: yeah23:18
somikbeherayup, since you have to provide implementation backing it23:18
jorgewyea :-)23:18
danwentok, so I think we're good?23:18
ecarlinthe networks resource is L2 - that's all we are promising23:18
romain_lengletthe 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 extensions23:18
danwentromain: yup, i agree with that goal.23:18
romain_lengletand I think we meet that goal with the current proposal23:19
danwentok, 20 minutes over time... we good to go?23:19
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"23:19
somikbeheraagree there, i think we should freeze the current proposal to make progress on delivery23:19
openstackMeeting ended Tue May 24 23:19:29 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)23:19
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-22.01.html23:19
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-22.01.txt23:19
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-05-24-22.01.log.html23:19
danwentI did it!23:19
salv-orlandoShould we set up an etherpad for discussing thinks that did not made into today's meeting23:19
danwentAre the "topic" etherpads sufficient?23:20
salv-orlandolike attributes of core resources23:20
danwentcan that discussion happen on the core API etherpad?23:20
salv-orlandoit's already a bit messy :-)23:20
danwentI also created an etherpad for extension mechanism discussion: http://etherpad.openstack.org/quantum-extensions23:20
danwentYou can delete most of my stuff, as it has already been handled.  Or maybe just create a "clean" section at the bottom?23:21
ecarlinwhere is the quantum api etherpad?23:21
salv-orlandoOk, let's go for the clean section. No point to add a new bookmark23:21
danwentwith easy to remember name :)23:21
salv-orlandosorry I did not know how to create etherpads with human names23:22
danwentI believe it is linked from the blueprint23:22
salv-orlandoI believe that means quantum-api in klingon23:22
danwentyes, link is on: https://blueprints.launchpad.net/network-service/+spec/quantum-api23:22
danwentI will add a few copy/pastes from the meeting to the extensions etherpad.23:23
danwentsee you all later :)23:23
salv-orlandobye all!23:23
ecarlinbye everyone!23:24
*** Sumit has quit IRC23:24
yingsee you all23:24
somikbeheratake care all23:24
*** ecarlin has left #openstack-meeting23:24
*** jorgew has left #openstack-meeting23:24
*** romain_lenglet has left #openstack-meeting23:24
*** ying has quit IRC23:25
*** somikbehera has quit IRC23:26
*** markwash_ has left #openstack-meeting23:28
*** Jamey_ has quit IRC23:33
*** midodan has quit IRC23:34
*** troytoman is now known as troytoman-away23:36
*** adjohn has quit IRC23:39
*** ryu_ishimoto has left #openstack-meeting23:39
*** littleidea has quit IRC23:41
*** Tv has left #openstack-meeting23:42
*** namaqua has joined #openstack-meeting23:45
*** jwilmes has left #openstack-meeting23:58

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