17:00:45 <ildikov> #startmeeting VLAN-aware VMs BP discussion
17:00:46 <openstack> Meeting started Tue Jun 16 17:00:45 2015 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:47 <ChrisPriceAB> Hi guys
17:00:50 <openstack> The meeting name has been set to 'vlan_aware_vms_bp_discussion'
17:00:58 <ildikov> Hi.
17:01:03 <ijw> ildikov: I have a phone meeting at the same time, so I'll be distracted, but I'm here
17:01:19 <ildikov> Who's around for the VLAN-aware VMs discussion?
17:01:41 <ildikov> ijw: a-ha, ok, thanks :)
17:02:14 <pcarver> ildikov: I'm here to listen (or read)
17:02:15 <ijw> I'm just here to wind ChrisPriceAB up
17:02:18 <svinota> ildikov, let's wait several minutes, it takes a time usually for people to join
17:02:26 * ChrisPriceAB is feeling wound...
17:02:38 <ijw> My work here is done.
17:02:52 <ildikov> armax: mestery: ping
17:02:56 <ChrisPriceAB> lel
17:03:02 <ildikov> ijw: ChrisPriceAB: :)
17:03:08 <mestery> ildikov: hi there!
17:03:20 <mestery> ijw: you wind everyone up
17:03:35 <ijw> It's a talent
17:03:50 <mestery> you could call it that ;)
17:03:56 <ChrisPriceAB> It's an English thing...
17:04:09 <mestery> ijw is english? I thought it was all an act!
17:04:33 * ChrisPriceAB think's he might be a returned convict...
17:05:00 * pc_m lurking
17:05:14 <ijw> ChrisPriceAB: coming from a close relation to a wombat that's horribly racist
17:05:27 * ildikov wonders how many readers are needed for starting a meeting :)
17:05:45 <ChrisPriceAB> better start before things turn ugly...
17:05:50 <mestery> ildikov: We're likely good, I suggest you run it (you can make me and ijw co-chair if you want assistance)
17:06:00 <mestery> ChrisPriceAB: Wait, ijw is already here?
17:06:02 <mestery> Last joke I promise :)
17:06:09 <ChrisPriceAB> heh
17:06:12 <ildikov> LOL :)
17:06:13 <mestery> And I likely owe ijw a few more beers at this point too
17:06:17 <ildikov> let's start then
17:06:29 <ijw> mestery: naturally
17:06:44 <ildikov> #chair mestery
17:06:44 <openstack> Current chairs: ildikov mestery
17:06:54 <ildikov> #chair ijw
17:06:55 <mestery> #chair ijw
17:06:55 <openstack> Current chairs: ijw ildikov mestery
17:06:56 <openstack> Current chairs: ijw ildikov mestery
17:06:57 <mestery> lol
17:07:10 <ildikov> ok, now we can start :)
17:07:12 * ijw feels flushed with power
17:07:22 <ildikov> #topic (again) Why VLAN transparency does not fit our needs?
17:07:34 * ChrisPriceAB facepalms...
17:07:45 <ijw> Now, this one needs to go into the BP, but we're all basically agreed
17:08:01 <ijw> VLAN transparency covers VMs that know they're talking on VLANs to each other
17:08:05 <svinota> looks like not all of us, so I would like to be double sure
17:08:16 <ijw> This covers VMs where one end isn't talking VLANs and the other one is.
17:08:30 <svinota> is Armando here, does anyone know?
17:08:40 <ijw> svinota: If they're going to be 10 minutes late we have to make do without
17:08:54 <mestery> svinota: armax is lurking I think
17:09:02 <armax> I am here
17:09:13 <ijw> mestery: I thought that violated his parole?
17:09:21 <mestery> lol
17:09:43 <mestery> ijw: Remind me what we're arguing about here with regards to use cases?
17:09:53 <mestery> I need the tl;dr version, and be gentle
17:10:02 <svinota> armax, great — pls leave comments also, if you have some, I need to be sure that I didn't miss anything
17:10:17 <ijw> mestery: this is where you want to connect a VM to more networks than it has interfaces by combining the networks on a VLAN trunk before it comes into the VM
17:10:50 <armax> svinota: sure
17:10:54 <ijw> The VLAN trunk - as this BP is designed - doesn't exist on a network, just within the port, because that gives you better control over the settings for the VLAN subports. but that's a design choice.
17:11:39 <mestery> ijw: ack
17:12:21 <ijw> OK - I'll take it from the silence that we've covered those two topics, so we should probably talk about the crux of the matter
17:12:32 <svinota> yep
17:12:39 <ijw> #topic API
17:13:19 <ijw> If we accept based on above that this is wanted and nothing else does it (which is is) then the problem we have is that the port that attaches to the VM is not quite like a normal port
17:13:50 <svinota> if I do understand correctly, there are different opinions, should it be a new port class, or can we use original Neutron port class
17:13:56 <ijw> The subports connect to a network and 'bind' to the port.  The port connecting to the VM doesn't really need to bind to a network.
17:14:15 <armax> I personally don’t see this done any other way than a new port class
17:14:34 <ijw> I think given the parallels the subport just needs a parent port reference in an extension, and is otherwise fairly normal other than the fact that it's not a VM it's bound to (which, while it's unusual, is not out of the scope of what ports do)
17:14:39 <pcarver> In Cisco-speak this is basically the difference between "switchport mode access" and "switchport mode trunk", correct?
17:15:04 <pcarver> Currently all Neutron ports are "access" ports
17:15:08 <ijw> pcarver: yup - and in Linux speak the difference between ifconfig eth0 and ifconfig eth0.0 using the port info
17:15:30 * mestery waits for someone to explain this in docker speak
17:15:33 <ijw> Well, I'd call them trunk ports, but call them either
17:15:43 <ijw> In docker speak, networks are scary so go away
17:15:46 <mestery> +1 to armax
17:16:01 <svinota> armax, new port class for the trunk port or for all of them? Why can not we use the original class, but make it hierarchical?
17:16:29 <ijw> So if we were to create a new port class it inherits behaviour from an ur-port, if you will
17:16:43 <pcarver> armax: I agree, but in terms of terminology it's unfortunate that the word "port" ends up being a subnet of what it means on "real" switches
17:16:44 <armax> svinota: I thought I had made this point on the spec proposal
17:17:05 <ijw> If I define ur-port is something that can be attached to a VM, it does that bit, and a port does to.  What it can't do is attach to a network.  What it additionally does is have subports
17:17:19 <ijw> pcarver: Freudian
17:17:40 <pcarver> right, subset not subnet
17:17:56 <armax> but the crux of the matter is that adapting the existing model is incredibily problematic
17:18:04 <armax> for a number of standpoints
17:18:08 <ijw> So, if we were to create a trunkport (which is probably only the first in that category of ports we might want) then (a) what do we call it and (b) how do we implement it in the least scary way?
17:18:33 * ijw hands the mic and the warm git repo to armax
17:18:58 <ijw> (I've been sitting on it, which is why it's warm, sorry)
17:19:06 <armax> the most prominent would be that the changes required are pretty invasive and might entirely break the mdoel for all the plugins outta there
17:19:39 <armax> let alone the fact that we have so many efforts in-flight that I am not sure how a coordination with them is feasible in such a small amount of time left for Liberty
17:20:07 <ijw> armax: given the time in the cycle the 'small amount of time' is all we will ever get to do this sort of thing
17:20:27 <ijw> armax: I think if we use binding to attach to a subport then at least the code can live outside of the plugin
17:20:41 <armax> you mean port-binding?
17:20:45 <ijw> Yup
17:20:48 <ijw> It would be no different on that side to a router
17:21:27 <ijw> (Router binding is also a bit broken in that it's limited but still, the model exists)
17:21:44 <armax> mine is suggestion
17:22:08 <armax> based on my experience on how to work on the codebase on a daily basis, that’s how I would go on about
17:22:14 <armax> implementing this
17:22:29 <armax> binding is a hack
17:22:45 <armax> hijacking the existing port model is a hack
17:22:52 <armax> sure, they can be used to make this work
17:22:59 <armax> but that doesn’t make them less of a hack
17:23:00 <ijw> I tend to disagree on that.
17:23:03 <armax> they are still a hack
17:23:29 <armax> surely the hack is one way that could be pursued
17:23:41 <armax> but that guarantees you 0% chances of success of this effort
17:23:47 <armax> or very slim anyway
17:23:51 <ijw> I would agree with a trunk port would be a hack because the thing on longer behaves like a port at all.  I think a subport is a normal port - a tap on a network with addresses
17:24:07 <armax> now I am not saying that going with first class citizen is going to be a bed or roses
17:24:26 <ijw> But I'm only working with what we have.  If you have something you consider to be a cleaner approach that would be great
17:24:46 <armax> but at least chances are going to be higher and we’d be miniziming the side effects of breaking plugins and causing all sorts of regressions
17:25:02 <ijw> armax: what would you consider to be a first class citizen?
17:25:05 <armax> ijw: we don’t have to work with what we have
17:25:12 <armax> we can build what we need from scratch
17:25:19 <armax> to enable, effectively what is a new use case
17:25:22 <ijw> What would you build?
17:25:28 <svinota> armax, that will mean Nova change as well, won't that?
17:25:38 <armax> ripping the code apart to make it do what it was not supposed to do isn’t something I would be comfortable to bless
17:25:54 <armax> svinota: nova changes will be required more or less nonetheless
17:26:13 <ijw> armax: I agree with that but you haven't really expressed what the specific problem is or what your alternative suggestion is, can you go further?
17:27:22 <armax> not sure how further I need to delve into
17:27:38 <armax> my suggestion is that trunk ports should be first class elements of the API
17:28:00 <armax> that will bring the minimal amount of disruption to the existing model and changes to the codebase
17:28:09 <ijw> armax: I think we pretty much agree on that point
17:28:20 <armax> what else do you need? that I do the coding for you? :)
17:28:36 <ijw> And I wasn't arguing that point at all
17:28:55 <svinota> ijw, armax : I will do coding, I just need you opinion to choose the direction :)
17:29:07 <ijw> But that wasn't what I was saying, I was talking about subports and I wanted to be clear what you thought there
17:29:18 <armax> svinota: sure, I expressed my opionion here and on the spec
17:29:29 <armax> svinota: nothing else will make change my mind or recommednation
17:29:39 <armax> svinota: is there anything else that you would need from me?
17:29:47 <ijw> armax: subports
17:29:55 <svinota> armax, subports
17:29:56 <armax> ijw: go on?
17:30:06 <ijw> There are two objects here, trunk and subports
17:30:17 <ijw> subports behave a lot more like traditional ports than trunk ports do
17:30:19 <svinota> can we use original Neutron ports as subports?
17:30:23 <ijw> Do you feel that they need to be something different?
17:30:50 <armax> ok
17:30:59 <armax> that depends
17:31:04 <mestery> ijw: you want to make trunks a new object in the API but have subports melded into the existing ports?
17:31:38 <armax> could a subport be modeled  as 1-1 to relationship with a port
17:31:38 <armax> ?
17:31:47 <ijw> armax: yes
17:31:59 <ijw> mestery: Given that subports behave like existing ports in almost every respect apart from needing a couple of extra bits of information I'm wondering if there's any need to have another object there
17:32:02 <svinota> (I would say so: can we extend existing port model to be used as subports as well w/o disrupting all the model)
17:32:05 <armax> is tehre any relationship attribute that needs to be captured?
17:32:23 <ijw> parent and encap relationships would be needed (and could be extension attrs)
17:32:34 <armax> well there is no need to capture it in the port model itself then
17:32:38 <ijw> 'parent' might not be the right word given trunk ports aren't really ports
17:32:50 <armax> if a subport is a port + some stuff
17:32:51 <amotoki> it depends on how we model subports. if we introduce a new object "trunk port", we can use a neutron port as subport. "trunk port" ojbect can terminate a normal neutron port and encap it into VLAN.
17:32:56 <ijw> armax: true enough but it has to go somewhere
17:33:00 <armax> it can be modeled as its own entity too
17:33:11 <ijw> armax: it can.  The question is the value
17:33:18 <armax> that can have a 1-1 mapping with port
17:33:42 <armax> what value? If I need to translate an OO conceptual model into a logical schema
17:33:47 <armax> that’s the only sensible way forward
17:33:56 <ijw> OK, so you're suggesting trunk attachment points (let's not call them ports) and encap descriptors that we pair up with a port.
17:34:09 <armax> strictly speaking you don’t generate a denormalized schema
17:34:18 <armax> just because it ‘saves' you a table
17:34:21 <ijw> When they're paired up with a port, the port is bound and can't be used any other way
17:34:41 <armax> ijw or is there any other value you’re talking about?
17:35:36 <ijw> Well, my point is that ports are made to take extension attrs, so I'm asking the question whether having a separate 1:1 object that holds data is the choice to use here
17:36:10 <ijw> It sounds like a nicer arrangement, but I want to hear your opinion
17:36:14 <armax> ijw: well as a matter of fact extension attrs are implemented as separate tables
17:37:21 <armax> and that is also partially done to ensure that the model addition does not interfere with the rest of the code taht doesn’t understand the extension
17:37:26 <ijw> Yup
17:37:39 <ijw> armax: so internally the coding effort is similar.
17:37:47 <armax> ijw: I guess so, yea
17:38:00 <ijw> armax, people who want to use this: any particular arguments for or against?
17:38:14 <ijw> ildikov, ChrisPriceAB, pcarver: speak
17:38:40 <armax> ijw: all I am debating about is oblivious to the User
17:38:44 <ChrisPriceAB> I don't think it makes a huge difference.  We need to get it in in a way that doesn't cause issues moving forward.
17:38:57 <armax> the user nneds not to care about how we implement this
17:39:11 <ChrisPriceAB> And at the end fo the day this is where we would follow guidance from the cores.
17:39:13 <armax> so long as they have their use case addressed
17:39:38 <garci_> Seeing it from the point of view of a user, indeed, I don't care how its done as long as I can attach my vms with a vlan tag.
17:39:41 <armax> sure the suggestions made here have implications to the API/CLI
17:39:43 <ildikov> This is my opinion too, we would like to fit this into the Neutron architecture
17:40:07 <ChrisPriceAB> So, if I get it all right: we intend to make a new first class "trunk port" object and extend the regular port attributes with relation/encap for association?
17:40:08 <ildikov> As far as the feature we implement fulfills the use cases we identified, we're good IMHO
17:40:14 <armax> but they do not lead to any deficiencies of the use case AFAIK
17:40:30 <HenryG> As 50% of API/DB lieutenant for Neutron, I recommend new "trunk-interface" and "attachment-point" resources. amotoki is the other 50%. (And armax is the third 50% for this discussion :)
17:40:48 <armax> wow we are at 150% agreement?
17:40:52 <ChrisPriceAB> :D
17:41:00 <armax> that’s impressive
17:41:15 * ildikov feels issues with the power here :)
17:41:25 <armax> HenryG: btw I still need to stand up and drink my gallon of coffee, can you believe that?
17:41:31 <ChrisPriceAB> let's not get Ian started again...
17:41:54 <ijw> OK, well one set of you said 'extention attr' and HenryG said 'attachment point', so which have we agreed upon?
17:42:26 <armax> attachement point is an extension attr is it not?
17:42:46 <ijw> armax: I could tell you what else it could be but I'm not going to start you off again
17:42:50 <ijw> So, agreed:
17:43:12 <ijw> - we create a trunk port (don't call it 'port' or 'interface' please, but something like that)
17:43:44 <armax> ijw: not sure what the potential source of discord might be, but once we start seeing some coding then I am sure it’ll be immediately clear what is what
17:43:46 <ijw> - we add extension attributes to a normal port to indicate it's attached to a trunk port
17:44:04 <ijw> - ports with these attrs are created bound and can't be used by a VM
17:44:36 <ijw> And not stated but I think assumed, this would for preference *not* like in the OVS L2 agent or driver, if we can manage it
17:44:44 <ijw> DOes that summarise accurately?
17:45:04 <amotoki> i have another view. we create attachment-point on "trunk port" to add some port to "trunk port".
17:45:06 * ChrisPriceAB nods
17:45:39 <ijw> amotoki: yup, that comes down to the 'separate attachment port object' approach because it's 0+ element list
17:46:13 <ijw> amotoki, armax: I can see that either will do the job; I just want to pick the best one
17:46:30 <ijw> (ideally without writing the code for one and changing our mind to the other when it's finished)
17:46:44 <ildikov> ijw: +1
17:47:09 <pcarver> ijw: +1
17:47:20 <ijw> amotoki, armax: you're in the ring.  No biting, gouging or punching below the belt
17:47:35 <ijw> And the ref is open to bribery
17:47:45 <HenryG> amotoki: how would you "attach" multiple ports to a trunk object?
17:47:53 <amotoki> from API perspective, If we go a way of 'separeate attachmetn point", one thing considered is how we represent a "port" connected to VM side.
17:47:54 <pcarver> I don't think it matters too much what it's called, but armax makes sense.
17:48:08 <ijw> amotoki: I'd just bind it
17:48:12 <amotoki> HenryG: what in my mind is similar to L2 gateway modeling.
17:48:19 <ijw> But it would be hard to spot what it was actually attached to
17:48:47 <ijw> The attachment point then behaves like a VIF in many ways
17:49:15 <amotoki> we can create connections on L2GW. Similarly we can create attachment point on "trunk port".
17:49:25 <amotoki> perhaps i am in the same page as ijw.
17:50:34 <ijw> amotoki: I think we're talking about the same thing.  Again, I'm not expressing a preference here, I can see both solutions and I would personally take either
17:50:34 <amotoki> it is all API perspective. I am not sure we address armax's concern on implementatoin complexity.
17:50:49 <armax> I personally exausted my ability to visualize mentally what we’re saying…too many level of indirections
17:51:04 <armax> I’d like to see some code if at all possible
17:51:11 <ijw> armax: wuss
17:51:17 <armax> ijw: I am
17:51:18 <armax> bite me
17:51:21 <armax> :)
17:51:30 <ijw> armax: just trying to make sure we don't pack someone off who will definitely be writing something you -2
17:51:32 <HenryG> armax needs more coffee
17:51:39 <ijw> I mean, if you capriciously -2 it that's fine
17:51:43 <armax> ijw: when did that happen?
17:52:08 <svinota> armax, I need the BP anyway before I can deliver any code — otherwise we will not be in the timeframe
17:52:09 <ijw> armax: not saying it did, but if we don't understand your concerns then it will happen here
17:52:21 <ildikov> I would like to get the blueprint into an acceptable shape first
17:53:00 <garci_> +1
17:53:07 <ijw> So then, it seems like it's on the spec writers to update the spec at this point.  armax can check he likes that
17:53:09 * ChrisPriceAB feels we have enough to be concise on the BP now.
17:53:11 <armax> ijw: I am sure I agree, we shouldn’t be afraid of taking the wrong turn…it takes much longer to talk than whip up some code and discuss what’s going on
17:53:15 <ijw> (which it sounds like he will)
17:53:25 <amotoki> as far as I looked the spec, even though we go either way of API modeling the implementation will be similar.
17:53:28 <ijw> armax: talk faster
17:53:44 <svinota> ijw, I will update, but I need you guys to have some common vision :)
17:53:45 <armax> all I care is that we minimize the dependencies on the existing model
17:54:07 <ijw> So we need a trunk port primary object thing that Nova can bind that isn't a conventional port
17:54:09 <armax> and that we don’t rip it out as a result of this effrt
17:54:12 <ijw> (which implies a new table)
17:54:18 <armax> ijw: it sounds to me that I have set my bar pretty low
17:54:25 <ijw> And we need either port attributes in an extension or a separate endpoint object
17:54:37 <ijw> If we have something along those lines I think it will get a good reception.
17:55:05 <ijw> Would anyone disagree?
17:55:11 <ijw> Except armax, he doesn't count
17:55:13 <svinota> ijw, I will update the BP tomorrow morning
17:55:24 <armax> ijw: now you’re talking sense
17:55:31 * armax doesn’t exist
17:55:35 <ijw> armax: I talk so much it has to happen occasionally
17:55:50 <ijw> OK, so we now have 5 minutes to insult ChrisPriceAB in the meeting record
17:56:01 <ijw> #topic Insults
17:56:03 <svinota> finally :) yeah
17:56:04 <ChrisPriceAB> hehe, give it your best shot
17:56:35 * ChrisPriceAB is not competent enough to understand a good insult...
17:56:46 * armax is okay being insulted
17:56:50 <ijw> I worry about insulting people who have evolved to be poisonous
17:57:06 * armax is like a kitty
17:57:12 <ildikov> it's too late for me to insult anyone
17:57:21 <ijw> ildikov: I'm disappointed
17:57:22 <ildikov> armax: you mean Hello Kitty? :)
17:57:32 <ijw> ildikov: Oh no, that counts
17:57:36 <armax> sure why not
17:57:38 <ChrisPriceAB> Damn, next time give us some warning ijw.  This didn't turn out very well...
17:58:23 <ijw> See, we're even driving people away now
17:58:25 <HenryG> ijw managed to waste an hour of everyone's time
17:58:34 <HenryG> (is that an insult?)
17:58:35 <ijw> HenryG: I'm sorry
17:58:43 <ijw> I can usually manage longer than an hour
17:58:45 <ildikov> armax: sorry :)
17:58:50 <ChrisPriceAB> hehe, hey Ian can you link the picyure of the unicorn Ildikov drew?
17:59:08 <ildikov> ok, thanks everyone, I think we managed to choose a direction, which is good
17:59:21 <armax> all right guys, feel free to poke me anything
17:59:25 <armax> anytime
17:59:28 <ijw> https://twitter.com/lan_wan_ian/status/601073060783923201
17:59:28 <ChrisPriceAB> ack, thanks all
17:59:32 <svinota> great. Anyways, armax , ijw , mestery , HenryG , amotoki , ChrisPriceAB , ildikov  — thanks all.
17:59:34 * armax corrects himself
17:59:44 <ChrisPriceAB> wrong ijw!!!!
17:59:50 <ijw> Oh, not wrong
17:59:51 <ildikov> svinota will update the blueprint asap, let's get it approved in time and also let's start on do some coding to make armax happy too :)
18:00:07 <armax> ildikov: I am hardly pleased, but thanks for trying ;)
18:00:08 <amotoki> thanks, ijw and all.
18:00:16 <ijw> #endmeeting