14:00:26 <enikanorov_> #startmeeting neutron lbaas subteam meeting
14:00:27 <openstack> Meeting started Thu Dec  5 14:00:26 2013 UTC and is due to finish in 60 minutes.  The chair is enikanorov_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:31 <openstack> The meeting name has been set to 'neutron_lbaas_subteam_meeting'
14:01:08 <enikanorov_> lbaas folks around?
14:01:29 <Vijay_> Hi Eugene
14:01:55 <enikanorov_> hi Vijay_
14:02:40 <obondarev> Hi
14:02:42 <enikanorov_> as long as we only have you at the meeting we could discuss ssl if you like
14:03:19 <Vijay_> sure! we could wait probably a minute more?
14:04:06 <enikanorov_> yeah
14:04:09 <enikanorov_> here we go
14:04:13 <enikanorov_> hi folks
14:09:39 <obondarev> maybe move to the first topic?
14:10:04 <enikanorov_> #topic announcements
14:11:58 <obondarev> not so many announcements this week I guess)
14:12:05 <enikanorov_> so we're past I-1, and have 4 more weeks of I-2
14:12:05 <enikanorov_> main goal for I-2 would be for vendors to setup their third-party testing environments
14:12:06 <enikanorov_> and for us to provide some scenario tests
14:12:06 <Vijay_> should it necessarily run the tempest tests?
14:12:06 <enikanorov_> we have already published one basic scenario on review and recently I sent an email to openstack-dev asking about vip wiring
14:12:06 <enikanorov_> which goes dont to the automating creation of ull loadbalancer configuration
14:12:07 <enikanorov_> Vijay_: tempest smoke tests
14:12:07 <enikanorov_> ull=all
14:12:07 <Vijay_> I done see any lbass tests in https://github.com/openstack/tempest
14:12:07 <enikanorov_> so far it appears that all solutions posted on review or implemented, support haproxy-like workflow
14:12:07 <enikanorov_> Vijay_: there are some API tests
14:12:07 <enikanorov_> Vijay_: but we're working on scenario tests
14:12:07 <enikanorov_> they're not yet committed, but are on review
14:12:07 <Vijay_> ok got it , thanks
14:12:08 <enikanorov_> so the basic scenario test will execute the workflow where vip is created on the same subnet as pool's
14:12:08 <enikanorov_> and then floating ip will be associated
14:12:08 <enikanorov_> I expect this scenario is supported by all vendor solutions
14:12:08 <enikanorov_> any questions/suggestions on the testing?
14:12:23 <enikanorov_> ok
14:12:50 <avishayb> hi (sorry I am late)
14:13:00 <sgran> hi, sorry I'm so late
14:13:02 <enikanorov_> #topic progress with features
14:13:05 <enikanorov_> hi folks
14:13:42 <enikanorov_> so, in I-2 neutron team will continue to focus on stability and bug fixing
14:13:59 <enikanorov_> meanwhile we could develop our features and review them among ourselves
14:14:29 <enikanorov_> so i'll start with myself
14:15:04 <enikanorov_> i've published the very raw version of 'loadbalancer instance' on review
14:15:17 <enikanorov_> there are several importeam items yet to be done about that patch
14:15:21 <enikanorov_> plus CLI and horizon
14:15:59 <Vijay_> Can you give the link/review number?
14:16:04 <enikanorov_> feel free to comment but not that I'll appreciate design-level comments at the moment since the code is obviously not polished yet :)
14:16:22 <enikanorov_> !link https://review.openstack.org/#/c/60207/
14:16:22 <openstack> enikanorov_: Error: "link" is not a valid command.
14:16:44 <enikanorov_> #link https://review.openstack.org/#/c/60207/
14:17:59 <enikanorov_> I'd like to see major features to have their initial implementations published during I-2
14:18:21 <enikanorov_> just to familiarize some of core reviewers with the code
14:18:40 <Vijay_> Can we switch to SSL
14:18:43 <sgran> just looking over the review now
14:18:55 <sgran> sorry, one moment before we do
14:19:23 <sgran> I just want to clarify: loadbalancer instance means, running an openstack instance that provides a loadbalancer backend?
14:20:12 <sgran> or just creating the object, api and persistence models to encapsulate the idea of a loadbalancer
14:20:15 <sgran> ?
14:20:17 <sgran> It looks like the latter
14:20:19 <Vijay_> loadbalancer instance is a new entity/resource which is a wrapper around vip & pool
14:20:19 <enikanorov_> the second one
14:20:24 <enikanorov_> correct
14:20:26 <sgran> yes, ok, good
14:20:31 <sgran> just so I understand :)
14:20:40 <sgran> carry on - SSL when you're ready :)
14:20:54 <enikanorov_> ok, lets move to SSL feature
14:21:19 <iwamoto> "instance" is a openstack term for a VM. so it might be confusing
14:21:37 <Vijay_> SSL, looks to have achieved some consensus to introduce certificate as a separte instance
14:21:47 <sgran> yes, that was my confusion.  I'm also running loadbalancers inside openstack instances, so it's doubly confusing :)
14:21:48 <Vijay_> *instance == resource
14:22:01 <enikanorov_> iwamoto: it is general-purpose word, not patented for 'VM', so it's ok, anyway the entity itself called 'loadbalancer'
14:22:21 <sgran> Vijay_: nod, it seems that making it a top level resource is probably a good idea
14:23:00 <enikanorov_> iwamoto: so 'instance' actually appears in commit message and comments only.
14:23:04 <sgran> my only question at this point would be if we want to start off with a provider attribute that can either be something like 'local' for certs just stored in the DB or 'barbican' or 'active directory' or whatever ?
14:23:12 <sgran> I don't know how forward thinking to be on that one
14:23:36 <Vijay_> Yes that can be introduced.
14:23:39 <iwamoto> I felt, in openstack context, "instance" generally refers to a vm
14:23:42 <sgran> sort of how the loadbalancer provider is modeled
14:23:44 <yamahata_> is "container" instead of instance used at the summit?
14:23:50 <enikanorov_> supporting 'providers' might be too complex for the first step to take
14:23:52 <Vijay_> having that as a default value is fine
14:24:26 <enikanorov_> yamahata_: it doesn't matter, the resource is named 'loadbalancer'
14:24:50 <Vijay_> Provider is more involved work
14:25:10 <sgran> Vijay_: yeah, I don't think we want to do the work for a provider now
14:25:14 <samuelbercovici> I think that after having the "loadbalancer" as an entitry we can look on how to move charachteristics such as provider, networkis, insertion model to it
14:25:15 <enikanorov_> so I suggest the basic db-persistence will be implemented first
14:25:22 <sgran> I was just wondering if we wanted to leave space in the API for it
14:25:40 * sgran nods enikanorov_
14:26:26 <Vijay_> for now then as everyone agrees, we will have certificate as a separate resource with certificate parameters stored in db
14:26:29 <samuelbercovici> I am also gathering feedback from custumers on this.
14:26:35 <iwamoto> Loadbalancer resource would need some more attributes. for example an ID to distinguish vendor specific LB resource
14:27:02 <samuelbercovici> I mean on persisting SSL in DB
14:27:11 <enikanorov_> iwamoto: lets discuss it at the end of the meeting. also feel free to add this as a comment on the review
14:27:12 <Vijay_> that will help Sam
14:27:30 <iwamoto> enikanorov_: i see
14:27:32 <samuelbercovici> overall, I think that eugene, proposal to have the certificate API as an extension/mixin
14:27:48 <samuelbercovici> might assist in introducing the basic capability with DB persiatnce
14:28:07 <samuelbercovici> and then if another "trust" sture exists, allow other backend implementation
14:28:13 <enikanorov_> exactly
14:28:27 <Vijay_> agreed!
14:29:10 <samuelbercovici> my only concern is still that with the corrent implementation in the DB, the solution will not be acceptable
14:29:22 <samuelbercovici> and will not be adopted
14:29:36 <enikanorov_> what do you mean?
14:29:44 <samuelbercovici> I am waiting for two custumers to come back to me on this so I can form an oppinion
14:30:20 <samuelbercovici> enikanorov_: I mean that a "real" custumer will not be willing to use this if the certificates are stoerd in the DB
14:30:30 <enikanorov_> i see
14:30:49 <sgran> the aws api is rather basic for certs
14:31:03 <samuelbercovici> up until now, we only got response on ML from the gurdian. I hoped that we will get more "custumer" feedback.
14:31:06 <sgran> http://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadServerCertificate.html
14:31:15 <sgran> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/API_SetLoadBalancerListenerSSLCertificate.html
14:31:30 <samuelbercovici> as I said, I am also checking with out custumers to see if this is ok.
14:31:34 <iwamoto> could API be designed to allow both? to store certs in DB or to request user to re-supply certs when LBs fail
14:31:58 <enikanorov_> iwamoto: it may make sense to allow this
14:32:04 <enikanorov_> may be have some flag or something
14:32:16 <samuelbercovici> sgran: I am aware on this. as far as I remember AWS stored this inofrmation in some "secure" store
14:32:26 <sgran> sure
14:32:35 <sgran> I'm only talking about the API now
14:32:42 <sgran> the backend is an implementation detail
14:32:50 <sgran> (maybe an important one, of course)
14:32:52 <Vijay_> From top of my mind: It is not possible to allow both
14:33:01 <enikanorov_> Vijay_: could you explain?
14:33:15 <enikanorov_> if you have something like 'persistent' flag in your resource
14:33:22 <enikanorov_> that it is used ad you have proposed
14:33:25 <Vijay_> when certificate is created as a separate resource and sending confidential parameters
14:33:30 <Vijay_> which device will it be sent to?
14:33:36 <enikanorov_> otherwise it needs to be resupplied each time
14:33:37 <sgran> so I can see that UploadServerCertificate must store the certificate
14:33:57 <sgran> but SetLoadBalancerListenerSSLCertificate could take either a resource reference or data, right?
14:34:03 <enikanorov_> Vijay_: i see
14:34:14 <enikanorov_> seems you're right, obviousle
14:34:40 <sgran> samuelbercovici: I am the guy from the Guardian :)
14:35:04 <Vijay_> sgran: I think definitely the IAM service is storing the service separately outside of loadbalancer
14:35:19 <Vijay_> because certificates can be reused
14:35:20 <samuelbercovici> sgran: :-)
14:35:34 <sgran> Vijay_: yes, I think so as well
14:36:09 <sgran> I don't know that we need to follow the same model to start with
14:36:23 <sgran> it might be that later this gets changed to default to downloading from Barbican or something
14:37:34 <Vijay_> Sam, what kind of security is applied in the device to protect certificates.
14:38:07 <samuelbercovici> Vijay_: not sure I understadn ur q
14:38:50 <Vijay_> for ex. Netscaler accepts certificates through API call or through file transfers
14:39:11 <samuelbercovici> Vijay_: yes we also do
14:39:19 <sgran> So does riverbed, yeah
14:39:22 <Vijay_> if it is through APIs no loggin is done
14:39:37 <Vijay_> on the confidential params
14:39:42 <samuelbercovici> Vijay_: do u mean log files or log into the device?
14:39:50 <Vijay_> logs in the device
14:40:04 <Vijay_> also when support bundle is downloaded, the keys are not packaged
14:40:08 <Vijay_> for debugging purpose
14:40:53 <samuelbercovici> Vijay_: the keys are transfered via secure channle or upload from sftp to the device
14:41:10 <Vijay_> correct!
14:41:18 <samuelbercovici> they are not logged anywhwre
14:42:01 <Vijay_> do we have support bundle concept in openstack?
14:42:30 <Vijay_> where all logs and db configurations are packaged?
14:42:57 <enikanorov_> not aware of this
14:43:26 <Vijay_> ok, if there is one, we should make sure that certificate params stored in db is not packaged.
14:44:17 <Vijay_> so i was wondering if we can make a list of things that devices do to protect certificates, we can "try" to make sure similar mechanisms are employed
14:44:54 <sgran> symmetric encryption is probably the simplest
14:45:32 <enikanorov_> ok, I'd like to cover other topics as well
14:45:39 <enikanorov_> any update on L7 rules?
14:45:41 <samuelbercovici> Vijay_: this is excatly what I was trying to avoid. dfining a secure store for this feature might get a pushback as the need for "secure" store is not just here
14:45:46 <avishayb> yep
14:46:06 <avishayb> Open question: can the l7rule be reused in different l7policy or it can only be connected to 1 policy
14:47:16 <samuelbercovici> avishayb: L7 Policies are resued. I think that the rule is not reused
14:47:47 <samuelbercovici> on many occasions it is too granular
14:47:52 <enikanorov_> samuelbercovici: agree
14:48:43 <Vijay_> #agreed
14:48:56 <avishayb> ok - I will update the wiki page. and the policy - vip relations are 1:many
14:49:00 <avishayb> right?
14:49:26 <samuelbercovici> its actualy n:m
14:49:37 <samuelbercovici> VIP can have a few policies
14:49:45 <samuelbercovici> a policy can be used by multiple vips
14:50:04 <enikanorov_> right
14:50:22 <evgeny_fedoruk_> Regarding other topics, I have a change for a review
14:50:30 <enikanorov_> so i'd suggest it's done with VipPoolAssociation
14:50:38 <Vijay_> Avishay, as far as i can see, rule are already created for a policy.
14:50:39 <Vijay_> neutron lb-create-l7rule rule2 --attribute-type path --attribute-value "/shopping/.*" --action SELECT-POOL --policy p1
14:50:45 <enikanorov_> VipPoolAssociation(vip_id, pool_id, policy_id)
14:51:01 <enikanorov_> samuelbercovici: avishayb: does it make sense to you?
14:51:16 <avishayb> yes
14:52:00 <enikanorov_> (in case policy_id refers to the policy that has 'pool select' action)
14:53:14 <samuelbercovici> enikanorov_: we also would like to define arule with a "reject" action. in this case there is no pool_id
14:53:29 <Vijay_> is there a case for default pool?
14:53:38 <enikanorov_> samuelbercovici: i see
14:53:55 <Vijay_> *OR* always true rule + policy
14:54:34 <enikanorov_> Vijay_: default pool must be there
14:54:52 <enikanorov_> it will be association without policy_id
14:55:13 <samuelbercovici> Vijay_: "default" pool acn either be adressed here. Or can be addressed as a unique different memeber (as is implemented today).
14:56:03 <Vijay_> Hmm, Sam, then it will mix with default loadbalancer instance
14:56:51 <enikanorov_> Vijay_: how it is mixing with default instance?
14:57:19 <enikanorov_> you create a vip specifying pool_id, it becomes default pool for the vip
14:57:30 <Vijay_> Sam: can you explain " Or can be addressed as a unique different memeber (as is implemented today)."?
14:57:38 <enikanorov_> if you want to attach another pool to the same vip - you need to do it via l7 rule
14:58:14 <enikanorov_> i think Sam meant that vip will have pool_id attribute pointing to the default pool
14:58:23 <samuelbercovici> as we have 3 more minutes, we can take it offline to ML and the WIKIs
14:58:26 <enikanorov_> but I'd argue that it's better to avoid that
14:58:36 <samuelbercovici> is there anything else for the genda?
14:59:13 <enikanorov_> not much, lets discuss everything else offline or on #openstack-neutron
14:59:18 <enikanorov_> #endmeeting