14:00:39 <enikanorov> #startmeeting neutron lbaas
14:00:40 <openstack> Meeting started Thu Jun 19 14:00:39 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:43 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:46 <dougwig> o/
14:01:05 <[1]evgenyf> hi
14:01:21 <sbalukoff> Do we have an actual agenda for this meeting?
14:01:25 <mestery> Yes
14:01:27 <enikanorov> so i would to spend time on two items today: team update from the code sprint and flavor framework discussion
14:01:29 <sbalukoff> Or are we going straight into flavor framework?
14:01:35 <mestery> blogan is going to cover what happened locally for remote people
14:01:39 <mestery> And then we'll cover flavors
14:01:45 <enikanorov> lets start with the team update which i expect to be somewhat short
14:01:46 <mestery> enikanorov: +100 :)
14:01:46 <sballe> perfect
14:01:53 * mestery gets out of the way
14:01:59 <sbalukoff> Yay!
14:02:36 <blogan> alright so we got the api and object model blueprint approved, though there is still some discussion on whether the subnet_id on the pool should remain optional or not, vijay and I will continue on coding that part
14:03:33 <dougwig> i've been working on the changes to the driver interface, for bologna's object model changes.  code review out on that now, i'd appreciate feedback:  https://review.openstack.org/#/c/101084
14:03:36 <sbalukoff> We're going to do a bit of a round-robin where the various subgroups say what they've been working on.
14:03:41 <rm_work> o/
14:03:50 <s3wong> OK
14:03:51 <enikanorov> blogan: what major code parts are we expecting as a result of the sprint?
14:04:22 <TrevorV> o/
14:04:44 <sbalukoff> It's probably useful to mention this, too:
14:04:46 <sbalukoff> #link https://etherpad.openstack.org/p/juno_lbaas_mid_cycle_meetup_reviews
14:04:48 <sballe> I create the https://bugs.launchpad.net/neutron/+bug/1331836 which Kyle and I spent most of yesterday looking at fixing. It will allow the dva services to have a semi-admin status that will allow them to list network, and create/update/delete port on other tenants networks.
14:04:49 <uvirtbot> Launchpad bug 1331836 in neutron "Advanced Services need to be able to list all networks and create/update/delete ports on other tenants's networks." [Medium,In progress]
14:04:56 <dougwig> enikanorov: api and new object model, driver changes and starting the shim for older drivers, part of updating the haproxy ref driver, and part of adding ssl to ref driver.
14:05:33 <dlundquist> Phillip and I been working on updating the HAProxy reference driver for the new object model.
14:05:34 <sballe> s/dva/adv
14:05:40 <dougwig> and the etherpad that sbalukoff linked is what is actively in review, mostly as a result of the meetup.
14:05:41 <enikanorov> dougwig: that's quite a lot!
14:06:25 <sbalukoff> We've established some process around the Octavia reference driver and have started the process for getting it on stackforge, launchpad, etc. Note that this doesn't presently affect neutron-lbaas in any way (and in the long run is just going to be another driver / provider)
14:06:35 <mestery> sbalukoff: Yay!
14:07:51 <enikanorov> ok, anything else on updates?
14:08:00 <blogan> sorry i got disconnected
14:08:13 <blogan> enikanorov: well there will be a new extension, plugin, an db module so that the apis can live side by side at first
14:08:16 <dlundquist> We have daily recaps here: https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon
14:08:34 <blogan> the extension is relatively complete, the plugin and db probably won't get done today but vijay and I can work on that after until it is complete
14:08:36 <enikanorov> cool
14:08:44 <enikanorov> blogan: anything on review yet?
14:09:08 <blogan> enikanorov: i think we'll be able to put something up in gerrit as a WIP some time today
14:09:15 <enikanorov> cool!
14:09:16 <dougwig> enikanorov: not yet; all outstanding reviews for the meetup are on the etherpad.
14:09:25 <enikanorov> ok
14:10:36 <enikanorov> if that's all with updates, lets move to flavors
14:10:40 <german__> and we reached out to ceilometer to get the mtrics
14:10:41 <s3wong> Are we going to talk about flavor?
14:10:45 <enikanorov> s3wong: yes
14:10:46 <mestery> enikanorov: +1
14:10:50 <german__> flavor-time
14:10:53 <dougwig> enikanorov: +1
14:10:54 <mestery> flavor flav
14:10:59 <sbalukoff> Heh!
14:11:02 <min> I was working on the api documentation part, specifically Neutron LBaaS API v2.0
14:11:08 <enikanorov> ok, so let me briefly introduce the topic
14:11:15 * markmcclain wonders why mestery isn't wearing a clock
14:11:34 <enikanorov> initially we've introduced multivendor support for lbaas
14:11:37 * annegent_ perks up
14:11:37 <mestery> #link http://en.wikipedia.org/wiki/Flavor_Flav
14:11:51 <enikanorov> which is the ionly service able to handle several drivers simultaneuosly right now
14:11:54 <enikanorov> (in neutron)
14:12:23 <enikanorov> from API perspective that means that user is exposed to available implementations (providers or drivers) and can choose between them
14:12:31 <enikanorov> associating service (loadbalancer) with the provider
14:12:50 <enikanorov> that approach has various drawbacks which we want to address with Flavor Framework
14:13:01 <enikanorov> first of all, the term Flavor is taken from Nova flavors
14:13:20 <enikanorov> where it defines few basic capabilities that VM has: memory, cpus, disk size
14:13:39 <enikanorov> it also has additional 'extra specs' which are actually scheduler hints
14:13:48 <sbalukoff> Ok, so we have been doing a lot of hand-waving around providing for vendor-specific features in the past, implying that this would happen through the 'flavors' interface as well as the things you've mentioned.
14:13:50 <enikanorov> e.g. parameters, that help get proper compute host for the VM
14:13:58 <sbalukoff> And yes, 'extra specs' could cover this.
14:14:32 <enikanorov> sbalukoff: probably on vendor-specific features it would help if you could give an example
14:14:39 <enikanorov> so we're sure we're discussing the same thing
14:14:43 <german__> is our situtaion really like nova... we have many more things then memory, etc.
14:15:01 <enikanorov> because vendor-specific feautres are supported per the proposal, so i'm not 100% sure what we were arguing about
14:15:13 <enikanorov> german__: correct
14:15:16 <sbalukoff> So, let's assume some vendor has a specific load balancing appliance topology they've got patented (ie. only they can offer)
14:15:31 <enikanorov> german__: that's why we have configurable 'columns' in our flavor unlike fixed in nova
14:15:32 <sbalukoff> Some users want to use this, and the vendor wants this feature to be exposed to OpenStack users somehow.
14:15:45 <sbalukoff> The operator must decide whether to offer it.
14:15:58 <sbalukoff> But if he/she does, then we need to have a way for the operator to expose this vendor feature to the users.
14:16:03 <sbalukoff> Flavors seems like the way to do this.
14:16:06 <enikanorov> sbalukoff: yep, operator can expose this capability via flavor
14:16:13 <sbalukoff> Great!
14:16:16 <german__> enikanorov what I am saying is that we might have to many features making it unwieldy for a nova style flavor
14:16:33 <sbalukoff> So, the other disagreements I've had with you on this start to get into the weeds a bit on details.
14:16:42 <sbalukoff> This is all in the spec review...
14:16:49 <enikanorov> german__: conceptually they are the same, neutron flavor has configurable options ('tags' per current proposal)
14:16:51 <markmcclain> agreed the capability matrix will exponentially grow
14:17:02 <sbalukoff> For what it's worth, I like the (stub of an) idea that Mark McClain shaired last night to resolve this.
14:17:11 <german__> +1
14:17:15 <dougwig> +1
14:17:21 <sballe> +1
14:17:22 <mestery> +1
14:17:24 <enikanorov> actually there's only 1 thing in Mark's proposal that i dont agree with
14:17:29 <enikanorov> (or just don't understand)
14:17:30 <blogan> +1
14:17:42 <min> +1
14:17:44 <enikanorov> it is  the notion of driver profile
14:17:53 <enikanorov> from the first glance it seems to be a DB entity
14:18:05 <enikanorov> markmcclain: can you explain?
14:18:07 * markmcclain hand waved on profiles
14:18:24 <enikanorov> we always tried to avoid getting any parts of configuration into the DB
14:18:32 <sbalukoff> So....
14:18:35 <markmcclain> so it could be an entity or something in a config file
14:18:38 <sbalukoff> I don't really agree with that.
14:18:52 <sbalukoff> I don't like the idea of having to restart neutron (disruptive maintenance) to add a new tag.
14:18:58 <enikanorov> markmcclain: yes, it can, and ... why not just leave it for the driver?
14:19:00 <s3wong> enikanorov: so all these time, we have been talking about capabilities exposed via a config file, right?
14:19:05 <sballe> sbalukoff, +1
14:19:10 <markmcclain> I side stepped the exact location because I did not want the idea to get bogged down in the religious war of configs living the db
14:19:22 <enikanorov> hehe
14:19:29 <dougwig> markmcclain: +1
14:19:38 <enikanorov> when core is sidestepping, we will not get +A
14:19:39 <enikanorov> :)
14:19:44 <enikanorov> trust my experience :)
14:19:50 <markmcclain> hehe
14:19:57 <mestery> enikanorov: heh :)
14:20:26 <enikanorov> i can give reasons why it's not good to push conf into the DB, but i'd like to take it as fact
14:20:28 <german__> configuration-as-a-service?
14:20:42 <sbalukoff> Oh, I'm not going to let you get away with that. ;)
14:20:44 <sbalukoff> But!
14:20:49 <markmcclain> so let's continue to side step the location :)
14:20:53 <sbalukoff> It sounds like people don't want to debate that now anyway.
14:20:54 <enikanorov> sbalukoff: adding the tag is a process of configuration, and neutron doesn't support updating conf on the fly
14:21:00 <enikanorov> so it's fundamental
14:21:04 <markmcclain> and talk concepts here because location is an implementation argument
14:21:06 <blogan> +1 to not discussing that part right now
14:21:17 <german__> +1
14:21:20 <TrevorV> +1
14:21:29 <vjay2> +1
14:21:33 <enikanorov> so my proposal is to let drivers handle their profiles in the way the want
14:21:54 <enikanorov> and not link profile into the flavor
14:22:06 <markmcclain> except that as an operator I want choice
14:22:12 <enikanorov> because that's a kind of association we wanted to get rid of, when introducing flavors
14:22:26 <markmcclain> so returning to the original question
14:22:31 <markmcclain> driver profiles
14:22:45 <enikanorov> markmcclain: let's discuss it on some example
14:23:01 <enikanorov> let's say we have lbaas driver  with HA and non-HA profile
14:23:11 <markmcclain> are really the items that describe which driver to use and the initialization params necessary to implement the flavor
14:23:26 <markmcclain> enikanorov: that's where profiles matter
14:23:34 <enikanorov> markmcclain: right
14:23:34 <markmcclain> conceptually the same driver
14:23:51 <markmcclain> but my crap flavor may not enable HA initialization in the metadata
14:24:05 <enikanorov> markmcclain: by saying 'leave it ro driver' i mean the next thing:
14:24:45 <enikanorov> when driver receives create_lbaas(flavor_id), if analyzes the flavor and sees the tag: ("HA", True)
14:24:53 <dougwig> i think what's being debated here is whether the drivers *must* be flavor aware, or whether the flavor metadata contains enough information to utilize the same driver in different modes.
14:24:55 <enikanorov> and then it uses HA profile
14:25:11 <enikanorov> markmcclain: do you think it makes sense?
14:25:33 <enikanorov> dougwig: not really. drivers must be tags-aware (or capabilities-aware)
14:25:43 <sbalukoff> Right...
14:25:50 <dougwig> enikanorov: no, they actually don't, if the profile contains the config information to enable the tags.
14:25:59 <markmcclain> as an operator I don't want my drivers flavor aware
14:26:08 <s3wong> dougwig: I don't think driver is flavor aware. Driver exposed a set of tags and flavor framework picks provider based on the tags associated with a flavor
14:26:09 <sbalukoff> and if tags / capabilities are a sub-entity of flavors, shouldn't instances be associated with flavors?
14:26:15 <markmcclain> hence profiles it allows me to deploy to meet my needs
14:26:20 <enikanorov> sure, drivers cant rely on dynamically configured entities
14:26:33 <markmcclain> hence driver profiles
14:26:48 <enikanorov> markmcclain: i'm not against profiles itself, i just don't see a need for them to be in the flavor
14:27:06 <enikanorov> decoupling flavor from driver is what whole framework is for
14:27:30 <markmcclain> enikanorov: how else do would I as an operator express that this flavor A and B can use the same driver, but different initialization params
14:28:12 <dougwig> i think you're arguing to put the definition of tags into the vendor/driver's hands, and we're all wanting to put the definition of tags into the operators hands.
14:28:15 <markmcclain> +1
14:28:16 <sballe> +1
14:28:18 <german__> +1
14:28:19 <enikanorov> it is driver who choses profiles, so actually profile is associated with tags, not with flavor
14:28:32 <enikanorov> dougwig: it's both!
14:28:36 <enikanorov> it's in both hands!
14:28:50 <markmcclain> enikanorov: no profiles are an operator item
14:29:08 <enikanorov> markmcclain: you as an operator configure drivers anyway
14:29:21 <markmcclain> enikanorov: ?
14:29:22 <enikanorov> so, for the example i made above
14:29:50 <markmcclain> enikanorov: as an operator I select the solutions in the my deployment
14:29:52 <enikanorov> markmcclain: you provide a profile for HA model of the driver and driver knows when to use HA (when HA: True tag is encountered)
14:29:56 <markmcclain> those solutions have a set of drivers
14:30:16 <sbalukoff> I'm also interested in the problem as viewed from the user's perspective:  If I as a user deploy loadbalancer A with a specific flavor being offered by the operator, how can I be sure it was actually deployed that way, and will remain that flavor for the lifetime of the loadbalancer?
14:30:30 <enikanorov> markmcclain: yes, i'm talking about the same, it's just the mechanism is different
14:30:47 <markmcclain> enikanorov: I disagree
14:30:47 <dlundquist> sbalukoff: but an operator may choose to discontinue a flavor...
14:31:03 <markmcclain> sbalukoff: so that was part of the reason of associating the entry point and metadata
14:31:08 <sbalukoff> dlundquist: In which case the operator better also know which users are using that flavor.
14:31:23 <sbalukoff> markvan: Aah, ok.
14:31:28 <sbalukoff> So that needs to be visible to the user.
14:31:34 <sbalukoff> D'oh!
14:31:40 <sbalukoff> markmcclain
14:31:58 <enikanorov> basically, if we associate entry point and metadata it's equal to store conf in DB
14:32:08 <german__> yeah, and flavors need to go to ceilometer/billing
14:32:11 <enikanorov> it's kind of architectural argument, not implementation one
14:32:15 <markmcclain> enikanorov: remember we're side stepping that for now :)
14:32:28 <enikanorov> that just susks me in
14:32:46 <markmcclain> haha…so the crux of my proposal is to drop tags/caps and let the operator determine the mapping
14:33:09 <enikanorov> markmcclain: if no tags, that what map to what?
14:33:28 <enikanorov> wouldnt then Flavor be just another name for existing 'provider'?
14:33:28 <markmcclain> flavors contain a set of driver profiles which the op curates
14:33:44 <markmcclain> nope… list of profiles
14:34:01 <markmcclain> the scheduler then selects from the list accord to the algorithm
14:34:03 <enikanorov> yes, instead of one there will be a list
14:34:10 <enikanorov> but then how to choose the profile?
14:34:23 <enikanorov> there's not so much hints in such flavor
14:34:27 <enikanorov> (actually - no hints)
14:34:40 <enikanorov> and also - absolutely no hints for backends
14:34:53 <markmcclain> why do we need hints?
14:34:55 <enikanorov> i mean, for scheduling to a backend
14:35:22 <markmcclain> as an operator… I've said these drivers (when invoked a certain way) satisfy this flavor
14:35:43 <sbalukoff> markmcclain: Are you saying the hints enikanorov is talking about are essentially embedded in the various profiles in the list of profiles?
14:35:51 <enikanorov> markmcclain: yes, and besides that you want particular backend operated by the driver to implement the service
14:36:50 <markmcclain> yeah so scheduler can ask the drivers about capacity and then select
14:37:03 <markmcclain> remember we start simple and make the scheduling more complex
14:37:12 <enikanorov> scheduling should base on some data
14:37:18 <enikanorov> not clear what data is it
14:37:23 <enikanorov> (if no tags)
14:37:35 <enikanorov> also, what kind of information the flavor represents to a user?
14:37:39 <markmcclain> can ask the driver about capacity
14:37:48 <enikanorov> sure
14:37:52 <markmcclain> I think that we can make the flavor a name/description
14:37:56 <german__> or if scheduling with one driver fails tries a different one
14:37:57 <sbalukoff> I think I might need to see your idea fleshed out a bit more in a spec to really understand the implications, markmcclain.
14:38:14 * markmcclain recognizes some will want machine consumable info (ie tags)
14:38:25 <enikanorov> markmcclain: tags were the description... and scheduling hints at the same time
14:38:35 <markmcclain> sbalukoff: happy to write one up
14:38:42 <sbalukoff> Yay! Thanks1
14:39:09 <markmcclain> enikanorov: well scheduling is difficult because some solutions will present as a massive LB and others will be a collection of backends
14:39:32 <markmcclain> so upon reflection I couldn't really see how tags make this easier for us
14:39:37 <enikanorov> markmcclain: hmm, isnt' that up to scheduling algorithm?
14:39:45 <enikanorov> it's not 'easier'
14:39:52 <enikanorov> it's for user to show what he gets
14:39:56 <markmcclain> us -> operators, users
14:40:00 <german__> flavor tells scheculer about suitable drivers
14:40:20 <markmcclain> with tags as an operator I don't have the ability to steer certain flavors to specific implementations
14:40:34 <enikanorov> yes have!
14:40:38 <enikanorov> *you
14:40:48 <enikanorov> and i've described in the spec on how that can be done
14:40:59 <markmcclain> didn't seem that way
14:41:00 <enikanorov> tags are very flexible for such tasks
14:41:14 <markmcclain> because of the layers of complexity
14:41:21 <german__> +1
14:41:33 <enikanorov> ok, the complexity argument
14:42:07 <enikanorov> on slightly different matter, if we associate flavor and driver profile directly, what will happen with the flavor if we remove driver?
14:42:18 <enikanorov> the driver which profile was in the flavor
14:42:47 <markmcclain> so as an operator.. I'd be foolish to remove a driver without rescheduling the instance
14:42:55 <sbalukoff> +1
14:42:58 <markmcclain> hence the enable/disabled flag
14:43:18 <markmcclain> allows for data to exist while I'm decommissioning system(s)
14:44:36 <dougwig> markmcclain +1
14:45:03 <enikanorov> still not clear how is it better than providers. provider is the profile (it's just one single profile instead of several ones)
14:45:22 <markmcclain> so provide is attached to single vendor
14:45:26 <enikanorov> and there was proposals on how to add configuration to the provider entity
14:45:31 <markmcclain> as an op I want multiple vendors
14:45:39 <markmcclain> I think we're spinning our wheels a bit
14:45:44 <markmcclain> so let me write some stuff up
14:45:53 <enikanorov> i mean the driver profile is single vendor, right?
14:46:02 <enikanorov> (it has entry point)
14:46:05 <markmcclain> but the profile is not exposed to user
14:46:27 <enikanorov> yep, it's hidden behind flavor name
14:46:40 <markmcclain> enikanorov: exactly which is what I want as an op
14:46:40 <enikanorov> just as it could be hidden behind provider name
14:46:58 <markmcclain> provider name == vendor
14:47:07 <enikanorov> not necessarily
14:47:12 <enikanorov> it's up to operator
14:47:22 <enikanorov> i'm just trying to get the advantage
14:47:34 <enikanorov> beyong the scheduling between several driver profiles
14:47:47 <enikanorov> which is good, but i'm not sure it was the goal
14:48:13 <markmcclain> yeah so the other benefit as an operator with flavors is that the user expresses their intent
14:48:22 <markmcclain> but as an op I have to ability to manage my deployment
14:48:30 <sbalukoff> Yep.
14:49:11 <enikanorov> ok, prbably a spec will clerify things
14:49:15 <enikanorov> *clarify
14:49:16 <markmcclain> ++
14:49:22 <sbalukoff> +1
14:49:23 <dougwig> +1
14:49:26 * mestery notes 10 minutes left and dougwig wanted to discuss the noop driver ...
14:49:27 <german__> +1
14:49:32 <VijayB> +1
14:49:42 <dougwig> i got some feedback on the noon driver that it shouldn't be exposed in neutron.conf
14:49:45 <enikanorov> ok, lets move to the noop driver
14:49:56 <mestery> dougwig: noon? Is that like bologna? /cc blogan
14:50:02 <dougwig> as a server admin, i kind of like tools that help me debug smaller pieces of bigger puzzles, so that decision seemed odd to me.
14:50:03 <sbalukoff> Haha
14:50:06 <dougwig> noop, not none.
14:50:08 <dougwig> autocorrect fail.
14:50:08 <mestery> I jest :)
14:50:17 <dougwig> so i wanted to get peoples thoughts on that.
14:50:30 <sbalukoff> And in this case, a noop driver is useful for doing things like debugging UI.
14:50:33 <enikanorov> markmcclain: i remember we discussed noop in HK !
14:50:56 * markmcclain hates noop drivers
14:51:00 <enikanorov> sbalukoff: it is, but the question is whether to expose it in the default config
14:51:12 * dougwig hearts noop drivers.
14:51:21 * mestery grabs some popcorn
14:51:23 * rm_work pineapples noop drivers
14:51:26 <markmcclain> dougwig: define....
14:51:31 * blogan grabs some bacon
14:51:39 <dlundquist1> The noop driver may be useful for testing the flavor framework.
14:51:46 * mestery thinks we've all been in this room too long together
14:51:53 * TrevorV (ノ ゜Д゜)ノ ︵ ┻━┻
14:51:53 <markmcclain> noops that log can be ok
14:52:05 * sbalukoff doesn't usually speak in the third person but will in this case.
14:52:20 <dlundquist1> markmcclain: That sounds more useful than the black hole noop driver
14:52:25 <mestery> dlundquist1: +1
14:52:30 <sbalukoff> Yep!
14:52:34 <sballe> dlundquist1, +1
14:52:34 <enikanorov> then name it LoggingLbaasDriver!
14:52:55 <enikanorov> (andwe'll be done with nups)
14:53:07 <vivek-ebay> +1 for no-op driver
14:54:02 <markmcclain> so as long as it doesn't blackhole we're good
14:54:07 <dougwig> LoggingNoop driver?
14:54:09 <markmcclain> logging driver is fine with me
14:54:12 <dougwig> it does log, so it's not a pure noop
14:54:12 <mestery> dougwig: +1
14:54:19 <sbalukoff> +1
14:54:20 <dlundquist1> dougwig: +x
14:54:22 <german__> +1
14:54:27 <german__> rename and we are good
14:54:28 <dlundquist1> where x = 1
14:54:32 <blogan> i prefer LoggingLoadBalancerDriver
14:54:50 <rm_work> x++
14:54:58 <sbalukoff> dlundquist1: Don't you use your fancy mathematics to try to confuse me!
14:55:25 <dougwig> ok, not enabled by default, and must log and not just pass, and we're ok.
14:55:32 <dougwig> ?
14:55:35 <vivek-ebay> who will maintain no-op driver ?
14:55:43 <mestery> vivek-ebay: are you volunteering?
14:55:45 <vivek-ebay> will it be maintained as a vendor ?
14:55:45 <enikanorov> no-op driver maintenance team?
14:55:49 <enikanorov> ;)
14:55:49 <dougwig> the community, but i won't let it fester.
14:56:08 * markmcclain wants 3rd party ci for it
14:56:20 <enikanorov> :D
14:56:32 <enikanorov> btw, yes, that's a requirement!
14:56:32 <markmcclain> open discussion?
14:56:40 <dougwig> lol
14:56:42 <enikanorov> dougwig: think twice before adding it! :)
14:56:42 <markmcclain> enikanorov: haha
14:57:13 <enikanorov> ok, anything else for the meeting?
14:57:30 <vjay2> if we are done with driver, i have a trivial question regarding the flavour framework
14:57:38 <sbalukoff> Uh oh
14:57:40 <sbalukoff> :)
14:57:41 <enikanorov> vjay2: sire
14:57:42 <mestery> #sadpanda
14:57:43 <markmcclain> vjay2: what's your ?
14:57:43 <enikanorov> *sure
14:57:46 <vjay2> apologies for interrupting. examples please,  what does the profiles contain? tags (like HA, dedicated/shared allocation policy etc)?
14:58:01 <sbalukoff> markmcclain is going to write a spec to show this, i think.
14:58:11 <markmcclain> sbalukoff: +1
14:58:16 <german__> 1
14:58:16 <vivek-ebay> vijay2: https://review.openstack.org/#/c/90070/
14:58:24 <vjay2> ok
14:58:33 <markmcclain> vivek-ebay: that's the old one
14:58:44 <vjay2> will one driver expose many profiles?
14:58:46 <markmcclain> with only the stub.. I'll more meat to it
14:58:50 <markmcclain> *add
14:59:54 <dougwig> vjay2: yes
15:00:15 <vjay2> dougwig: thanks!
15:00:26 <mestery> Thanks everyone, looks like we're at time.
15:00:33 <sbalukoff> Thanks!
15:00:34 <dougwig> thanks
15:00:39 <blogan> bye everyone, thanks!
15:00:39 <enikanorov> thanks
15:00:40 <vivek-ebay> thanks.
15:00:40 <rm_work> \o
15:00:44 <german__> tahnks
15:00:46 <enikanorov> #endmeeting