21:00:18 <danwent> #startmeeting
21:00:19 <openstack> Meeting started Mon Jul 30 21:00:18 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:22 <marktvoelker> o/
21:00:31 <danwent> #link Agenda: http://wiki.openstack.org/Network/Meetings
21:00:49 <danwent> #link Folsom-3 status: https://launchpad.net/quantum/+milestone/folsom-3
21:01:11 <danwent> #info we are one week out from the point where all F-3 "features" should be ready to be proposed for review
21:01:11 <rkukura> hi
21:01:33 <danwent> (can be WIP review, but we at least want early feedback on major issues)
21:01:47 <arosen> o/
21:01:55 <salv-orlando> hi all!
21:02:03 <danwent> if you have an item targeted for F-3 and think that it won't be ready for review by next tuesday, please ping me (can be via email or irc)
21:02:06 <zhuadl> hello:)
21:02:31 <danwent> #topic F-3 Reviews
21:02:39 <danwent> we have a set of key reviews that i'd like to highlight
21:02:54 <danwent> we recently switched to keystone being enabled by default in quantum
21:03:12 <danwent> this is the review to update devstack, which hasn't landed yet: https://review.openstack.org/#/c/10269/
21:03:31 <danwent> not sure if Akihiro is here
21:04:00 <danwent> we also have issues with the linux bridge plugin and DHCP, which markmcclain has addressed here: https://review.openstack.org/#/c/10369/
21:04:16 <danwent> would be good to get that reviewed quickly so it doesn't block people who develop with the LB plugin.
21:04:49 <danwent> we also have a few bigger reviews that have been through a lot of cycles and I think we need to get them merged.
21:05:02 <danwent> so if there are blockers related to any of these reviews, we should bring them up
21:05:03 <danwent> https://review.openstack.org/#/c/9591/
21:05:20 <danwent> garyk's patch to avoid polling in the LB-plugin using RPC
21:05:32 <danwent> garyk is on vacation this week and can't defend himself.
21:05:46 <danwent> salv-orlando: are we close on this one? I think you've reviewed it recently
21:06:23 <salv-orlando> I will have another stab at it tomorrow to look at the last details. Looked good last time I had a look at it.
21:06:36 <salv-orlando> Unless major issues come up, it's a +2 for me.
21:06:44 <danwent> salv-orlando: ok, thanks.  I've reviewed it fairly recently as well, so I will try to be the second core review on that one
21:06:55 <danwent> gongys: https://review.openstack.org/#/c/9835/
21:06:59 <danwent> notifications stuff.
21:07:17 <danwent> I've reviewed this branch and had no issues code wise.  Are the questions garyk had worked out?
21:07:30 <danwent> looks like it, as he is +2
21:07:48 <danwent> I should be able to re-review this one soon.
21:08:25 <danwent> salv-orlando: https://review.openstack.org/#/c/9845/
21:08:46 <danwent> any blocking issues, or just needs eyeballs?
21:09:08 <salv-orlando> I had reviews this morning which I will address in the next hours.
21:09:30 <danwent> ok, looks like since garyk is out, we'll need someone to take it review slot on this one.
21:09:31 <salv-orlando> Nothing to be worried about - some clarifications I need to give, and a few minor adjustments
21:09:34 <zhuadl> about quantum-horizon integration, I have a question about the user panel.
21:10:21 <danwent> zhuadl:ok, we can talk about horizon stuff (I had it on the agenda below, but now is fine)
21:10:53 <danwent> for reference, quantum/horizon WIP review is here: https://review.openstack.org/#/c/10116/
21:11:03 <rkukura> danwent: I'll look at the public networks patch by Wednesday
21:11:10 <danwent> rkukura: great thanks.
21:11:34 <danwent> rkukura: that reminds me, are we still waiting on one more review for provider-nets?
21:11:38 <salv-orlando> rkukura: thanks
21:11:58 <rkukura> danwent: waiting on code 1st - should be ready by Monday at the latest
21:12:23 <danwent> rkukura: ok, just wanted to confirm, as LP issue was in code review.  perhaps we swap it back to 'good progress'
21:12:55 <danwent> zhuadl: did you have a question about quantum/horizon?
21:12:59 <rkukura> danwent: should have OVS vlan table bug fix ready to review tomorrow, which is prereq for provider phase 2
21:13:03 <zhuadl> my question is: the current user panel looks very similar to sys panel(CRD networks/subnets/ports in one page) .
21:13:05 <rkukura> danwent: confirmed
21:13:09 <danwent> rkukura: great, thanks
21:13:55 <zhuadl> will that be accetable for next F-3 release?
21:14:29 <danwent> zhuadl: I've been meaning to take a look at that.  I will try to do so soon.
21:14:37 <zhuadl> ok, thanks.
21:14:44 <danwent> is there anything useful someone can do with a port they have created in Horizon?
21:14:59 <danwent> I wasn't expecting that we'd even do the work to expose port creation in F-3
21:15:33 <danwent> (we're planning on allowing someone to pass a port-id into nova instead of a net-id when booting a VM, but I don't think that's implemented yet)
21:15:50 <danwent> gongys: please correct me if I'm wrong, but I think you split that out into a separate patch, right?
21:16:09 <nati_ueno> I can take port-id implementation for nova
21:16:14 <gongys> not yet.
21:16:32 <gongys> ok, thanks nati_ueno.
21:16:40 <danwent> nati_ueno:  great, thanks
21:16:46 <zhuadl> Launching VM with specified network(s) is supported newly.
21:16:52 <nati_ueno> Should I write bug report or blueprint for portid one?
21:17:12 <danwent> nati_ueno: up to you, but should be a pretty small change, so bug is probably fine
21:17:20 <nati_ueno> danwent: I got it
21:17:20 <salv-orlando> nati_ueno: a big should be fine, but ultimately it's up to you
21:17:28 <jkoelker> this will be done as an extention correct?
21:17:29 <danwent> besides, people are more likely to be concern if someone proposes a new blueprint this late in a release cycle
21:18:01 <danwent> jkoelker: yes.  I assume it would just be an addition to the existing extension that allows you to pass in network ids
21:18:03 <gongys> Yes. that bug will be on nova side.
21:18:31 <jkoelker> there is no existing extension, its in the core api, just wanted to make sure that we were not talking about changing the comput api
21:18:51 <nati_ueno> Yes it will be extension
21:19:19 <gongys> We just need ext the --nic with --nic port-id=xxx
21:19:32 <gongys> currently, it has --nic net-id=
21:19:42 <danwent> zhuadl: ok, great.  perhaps we could tweak that panel a bit to optionally pass in a port-id instead of a net-id in Horizon
21:19:50 <danwent> gongys: yes, that's what I was thinking
21:20:07 <zhuadl> ok
21:20:47 <gongys> so, we will do it following the --nic net-id path do finish the task.
21:21:05 <danwent> gongys: great
21:21:22 <danwent> #topic discussion topics
21:21:26 <danwent> ok, back to the agenda
21:21:54 <danwent> #info we've switched the webservice pipeline logic to mirror glance
21:22:16 <danwent> #info which means that you set the pipeline now by setting authstrategy = keystone
21:22:38 <danwent> we're also updating devstack to use this.  This should mirror how people will actually use quantum, so its important that we make the change.
21:22:41 <gongys> Dan: I think that is mirroring nova
21:22:49 <danwent> gongys: both, I thought
21:22:56 <danwent> but perhaps not… all blurs together
21:23:19 <danwent> also, wanted to point out that there are two overlapping devstack reviews
21:23:36 <danwent> for quantum.sh : https://review.openstack.org/#/c/8642/ and https://review.openstack.org/#/c/8369/
21:23:43 <danwent> looks like debo isn't here.
21:23:45 <PotHix> danwent: just for the record, what happens when you're not using keystone?
21:23:56 <PotHix> authstrategy = keystone
21:24:16 <salv-orlando> Glance is slightly different, as they use a "flavor" option in conf file which can be set to "keystone". Concept is the same, though
21:24:18 <danwent> same as happens before this change.
21:24:23 <danwent> salv-orlando: ah, good point
21:24:43 <danwent> PotHix: I believe all requests are treated as admin
21:25:02 <PotHix> danwent: ok :)
21:25:05 <danwent> and you need to specify --tenant-id when creating items
21:25:23 <salv-orlando> PotHixK nokeystone = noauth (ie: anarchy)
21:25:46 <danwent> salv-orlando: i think they use it for internal, i.e., non-tenant facing automation
21:25:58 <danwent> and hence don't use keystone
21:26:13 <PotHix> salv-orlando: :P
21:26:28 <danwent> #info the v1 and v1.1 related code will be being removed probably later this week or early next week, per our past decision
21:26:33 <danwent> just wanted to give people a heads up.
21:26:55 <danwent> if you think something that is v1 only needs to stay in the codebase, let me know.  I will also clean out people's plugins, unless they tell me otherwise.
21:27:05 <danwent> (i'm happy to let you do it yourself, if you prefer)
21:27:34 <danwent> #topic Community Topics / Open Discussion
21:27:40 <gongys> extensions path too.
21:28:06 <gongys> What is the progress about L3 features?
21:28:13 <danwent> gongys: can you clarify about extensions?
21:28:36 <danwent> gongys:  finaly got a good chunk of time to work on L3 over the weekend.  updated the page with a spec, and have made it probably 1/4 of the way through the core impl
21:28:37 <gongys> the quantum/extensions/ path, we have many ext for v1.
21:28:55 <danwent> gongys: so you're saying remove extensions that are v1-only.  that makes sense.
21:29:12 <danwent> we can always restore things from a previous version of the repo, if someone later decides to update them.
21:29:20 <gongys> Dan: Yes.
21:29:46 <danwent> ok, anything else to talk about?
21:30:08 <rkukura> any conclusion on tenant vs project?
21:30:17 <danwent> rkukura: ah, thanks for mentioning that.
21:30:18 <nati_ueno> Do we have time to discuss quantum-schduler ?
21:30:37 <gongys> I have an idea about refactor ip/mac allocation algorithm parts into a replaceable module.
21:30:41 <danwent> nati_ueno: let's handle rkukura's question first, then come back to that.
21:30:49 <nati_ueno> danwent: I got it
21:31:19 <danwent> rkukura: to give other people some context, the keystone v3 api, which apparently will not land until grizzly is switching from using the term tenant to the term project
21:31:57 <danwent> since we obviously don't want to be changing the quantum API in a non-backward compat way, we could consider making the official API v2 Quantum API use project_id instead of tenant_id.
21:32:07 <danwent> the only problem is that its out of sync with the keystone terminology for Folsom
21:32:16 <danwent> all in all, a pretty yucky situation if you ask me...
21:32:28 <rkukura> what's nova's terminology for folsom?
21:32:30 <salv-orlando> I am happy with renaming
21:32:53 <PotHix> +1 for renaming for folsom.
21:32:59 <danwent> rkukura: that's a good question.  not sure if nova ever updated from project_id (their original term) to tenant_id
21:33:02 <PotHix> Avoid rework later.
21:33:02 * salv-orlando and then, in an unprecedented u-turn, keystone v3 will keep "tenant_id"
21:33:07 <danwent> haha
21:33:14 <PotHix> LOL
21:33:28 <danwent> yeah, my slight preference is for switching to project_id now
21:33:30 <gongys> hello, where did we use the project_id in quantum?
21:33:37 <salv-orlando> what if we decide for tenant_id or project_id and then keep it like that forever, regardless of nova and keystone?
21:33:45 <danwent> gongys:  each v2 object has a tenant_id
21:33:47 <nati_ueno> s/project_id/tenant_id/ ?
21:34:00 <nati_ueno> woops wrong direction s/tenant_id/project_id/
21:34:07 <carlp> What if we make them synonyms in the API?
21:34:14 * salv-orlando "forever" means 12 months at least
21:34:17 <danwent> salv-orlando: yeah, either way, I don't want to change moving forward.
21:34:26 <gongys> Yes, I know,  why do we use project_id in quantum?
21:34:39 <danwent> gongys:  this tracks who "owns" an object
21:34:40 <PotHix> A new change will need a new API IMHO
21:34:43 <PotHix> not a good thing
21:34:47 <danwent> and therefore can edit/delete the object
21:35:21 <danwent> I'm probably against changing it moving forward once v2 if FINAL, so i guess the real question is whether we should change it to project_id now and leave it that, or just leave it as tenant_id
21:36:06 <gongys> all the components are using tenant_id, why do we switch project_id?
21:36:20 <gongys> Am I missing something?
21:36:21 <salv-orlando> Well, carp suggested to use aliasing in order to not be bothered by this issue at all. Is there any reason for not doing that?
21:36:22 <rkukura> if nova native API is using project_id in folsom, then we should too
21:36:55 <danwent> gongys:  the uuid that someone should pass in for tenant_id in quantum is a UUID from keystone.  If keystone calls that a "project_id", I think it woudl cause unecessary confusion
21:37:01 <zhuadl> We should align it with nova.
21:37:09 <danwent> I'd rather have the names be the same across projects
21:37:28 <danwent> salv-orlando: ok, can you look into what nova does, then we make a call based on that?
21:37:35 <gongys> I don't think so, nova has to keep it because it has the yucky legacy.
21:37:37 <salv-orlando> IMHO if we try and look at what all other core projects are doing, we'll end up with an headache. To me, tenant_id/project_id we should look at keystone only, as all projects eventually will sync up with it.
21:38:02 <danwent> salv-orlando: that's fair
21:38:06 <PotHix> +1
21:38:10 <nati_ueno> +1
21:38:16 <markmcclain> +1
21:38:18 <gongys> ok, let's see what is in keystone.
21:38:20 <danwent> ultimately, the UUID is a keystone value, so the keystone name is somewhat "authoritative"
21:38:29 <danwent> gongys: that's the problem
21:38:42 <danwent> keystone will be tenant-id in Folsom, but is switching to project-id in Grizzly
21:38:49 <danwent> (with the v3 api)
21:39:27 <danwent> ok, so I think there's a agreement for aligning with keystone
21:39:34 <danwent> just not clear with which version of keystone
21:39:34 <gongys> My god. Bad enough. All the industry is talking about multi tenancy,
21:39:50 <gongys> I have no idea about multi project term.
21:40:04 <rkukura> i think long term, but if nova is already on project_id and that is where keystone is going, why not do it now?
21:40:05 <nati_ueno> It is simple to use same version
21:40:17 <nati_ueno> If Folsom keystone use tenant_id, let's keep tenant_id now
21:40:22 <danwent> gongys: perhaps talk to heckj about it.
21:40:47 <danwent> nati_ueno: but I don't want Quantum API to change uncessarily from v2 to v2+
21:41:09 <danwent> ok, well, let's take this to the ML as necessary
21:41:12 <danwent> time is running late.
21:41:20 <nati_ueno> or let's keystone team update project-id in Folsom
21:41:39 <danwent> ok, we had two other items brought up.  one by nati_ueno and one by gongys
21:41:44 <danwent> nati_ueno: go ahead
21:42:04 <shivh> Is there a real relation between tenant_id and project_id (1 tenant can have many projects) ?
21:42:16 <nati_ueno> OK I send mail for mailing list about qunatum-schduler. Is that make sense for you?
21:42:21 <danwent> shivh: the relationship is between users and project.
21:42:33 <shivh> ok
21:42:36 <danwent> shivh: you can check out the proposed keystone API specs
21:43:39 <danwent> nati_ueno: ok
21:43:51 <danwent> gongys:  you had wanted to bring something up in open discussion?
21:44:34 <danwent> p.s.: for those keeping score, the latest version of the keystone v3 spec still seems to mention tenants, but heckj sent me an email saying it was changing to projects, so now I'm very confused (https://docs.google.com/a/nicira.com/document/d/1_TkawQIa52eSBfS4pv_nx1SJeoBghIlGVZsRJJynKAM/edit)
21:44:36 <gongys> I want to refactor the ip/mac allocatoin into an independent one.
21:44:51 <gongys> So that we can replace it with a configuration item.
21:44:59 <danwent> gongys: that seems reasonable
21:45:17 <gongys> Ok, I will have a try.
21:45:28 <danwent> k
21:45:36 <danwent> ok, anything else for open discussion, or are we done?
21:46:05 <danwent> k, don't forget to sign up for review days http://wiki.openstack.org/Quantum/ReviewDays
21:46:09 <danwent> have a good week folks!
21:46:12 <danwent> #endmeeting