20:01:15 <xgerman_> #startmeeting Octavia
20:01:16 <openstack> Meeting started Wed Nov 22 20:01:15 2017 UTC and is due to finish in 60 minutes.  The chair is xgerman_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:19 <openstack> The meeting name has been set to 'octavia'
20:01:29 <xgerman_> #topic Announcements
20:01:47 <xgerman_> so johnsom won’t attend today so it’s all me ;-)
20:02:18 <nmagnezi> and me :D
20:02:37 <longstaff> hi
20:02:39 <xgerman_> :-)
20:02:50 <jniesz> hi
20:03:05 <xgerman_> #chair nmagnezi
20:03:06 <openstack> Current chairs: nmagnezi xgerman_
20:03:36 <nmagnezi> xgerman_, ^^ i hope that chair is not Ikea made
20:03:41 <nmagnezi> :)
20:03:46 <xgerman_> ok, I don’t really have any announcements other that most of us will be out until Monday
20:04:18 <xgerman_> #topic Brief progress reports / bugs needing review
20:05:27 <xgerman_> johnsom made some good progress on #link https://review.openstack.org/#/c/519509/ - please review
20:06:03 <xgerman_> we also need reviews for #link https://review.openstack.org/#/c/509957/
20:06:10 <nmagnezi> #link https://review.openstack.org/#/c/519509/
20:06:37 <xgerman_> #link https://review.openstack.org/#/c/458308/
20:06:56 <jniesz> for the provider spec, auth token approach sounded ok to me
20:07:03 <xgerman_> QoS is pretty close but I also discovered that we don’t enable the qos extension in our devstack
20:07:26 <longstaff> ok thanks jniesz
20:07:31 <bar_> I've created a story about QoS progress: https://storyboard.openstack.org/#!/story/2001310
20:07:44 <nmagnezi> xgerman_, yeah, I also saw such comment from bar_ . any reason not to include that addition in the same patch?
20:07:50 <bar_> I made devstack deployment work earlier today
20:08:21 <xgerman_> we can add to that patch or make that patch dependant on the devstack update
20:09:24 <nmagnezi> ack
20:09:34 <xgerman_> then we probably also need to tempest test…
20:09:45 <xgerman_> any updates on our test efforts?
20:10:04 <nmagnezi> Alex_Staf, ^ ?
20:10:37 <nmagnezi> we have a scenarios gate for the tempest plugin repo now, don't we?
20:11:08 <xgerman_> yeah, I think so, too ;-)
20:11:38 <xgerman_> #topic Provider driver spec
20:12:02 <Alex_Staf> hi guys
20:12:07 <xgerman_> hi
20:12:20 <xgerman_> I will make another topic for you after that ;-)
20:12:32 <Alex_Staf> no news from my side . I bugged u enough on the plugin
20:12:41 <xgerman_> ok
20:12:44 <Alex_Staf> I do  have some request though I submitted
20:12:52 <Alex_Staf> regarding HA documentation etc
20:13:14 <xgerman_> ok, it’s definitely on our radar
20:13:21 <Alex_Staf> cool
20:13:24 <Alex_Staf> another thing
20:14:06 <Alex_Staf> I think we need some api call tool that request for the octavia processes status  - like neutron agent-list but for octavia
20:15:06 <xgerman_> yes, we talked about that in Denver at the PTG
20:15:08 <jniesz> yea, where the driver would be required to give the status
20:15:10 <Alex_Staf> I think it will help in the automated tests as well - to getr status after failover , for example
20:15:15 <jniesz> and maybe an error field to list an error
20:15:24 <Alex_Staf> xgerman_, really? I missed that I guess =\
20:15:43 <xgerman_> it was on one of the provider driver days
20:15:57 <xgerman_> we should make sure the spec includes that call
20:16:37 <jniesz> that is something we should require drivers to implement
20:16:40 <nmagnezi> xgerman_, not sure, but do o-hm and o-hk even use RPC? is not, I wonder how can we achieve an "agent-list" for octavia services
20:17:15 <nmagnezi> btw I think we should be discussing the provider spec at the moment.. :P
20:17:38 <xgerman_> we are doing it - agent list is something all providers need
20:17:56 <xgerman_> but we call it more “component” list
20:18:11 <nmagnezi> ack
20:18:24 <xgerman_> nmagnezi we can start having the octavia components sending heartbeats
20:18:59 <nmagnezi> xgerman_, yup.
20:19:02 <xgerman_> or use one of the new etcd integrations…
20:19:28 <Alex_Staf> xgerman_, another question . I discussed with nir the octavia operation and we know that api sends the request to the workers ( ha setup 3 controllers- 3 api,worker,HM,houseKeeper) , and it send the task to the messaging que and one of the workers pick it up and execute right ?
20:19:31 <nmagnezi> do we have a story for that?
20:19:37 <nmagnezi> if not, maybe Alex_Staf can submit one
20:20:06 <xgerman_> yes
20:20:09 <Alex_Staf> nmagnezi, octavia components sending heartbeats ?
20:20:29 <jniesz> etcd seems to make sense for status / health
20:20:29 <nmagnezi> Alex_Staf, about the octavia components list
20:20:38 <Alex_Staf> xgerman_, how do the other 2 workers are not executing the request again ?
20:20:39 <xgerman_> jniesz +1
20:20:53 <xgerman_> we pop the request from the queue
20:21:06 <xgerman_> and if the worker with the request dies you are SoL
20:21:10 <Alex_Staf> when it was received it removed fro mthe que ?
20:21:16 <xgerman_> yes
20:21:19 <Alex_Staf> cool
20:21:22 <Alex_Staf> what is SoL ?
20:21:42 <Alex_Staf> nmagnezi, lets discuss that tomorrow - the story
20:21:42 <xgerman_> the idea is that one day we use task board and taskflow will manage persisting tasks
20:21:58 <xgerman_> out of luck
20:22:20 <nmagnezi> O_o
20:23:01 <xgerman_> ok, after we went on a tangent is there anything longstaf_  needs to move ahead with the spec
20:23:06 <xgerman_> ?
20:23:16 <jniesz> to limit provider drivers from only updating the status of their objects (amphora, loadbalancer, listener...) with auth token
20:23:25 <jniesz> from provider, do we need to add something like "owner" field to the tables
20:23:42 <xgerman_> we have a provider field on LB
20:23:57 <xgerman_> that’s what i thought we would be using
20:24:56 <jniesz> ok, I don't remember seeing that field added in the spec
20:24:57 <jniesz> for lb
20:25:13 <jniesz> i guess it is implied through flavor
20:25:13 <xgerman_> it has been there forever
20:25:29 <kong> hi, guys, does that make sense to support http communication between worker and amphora?
20:25:36 <jniesz> yes, nm
20:25:44 <longstaf_> for auth token: Octavia would generate a token and pass to provider driver when loading driver, and drivers include token on calls to update Octavia
20:26:09 <longstaf_> does this make sense?
20:26:30 <nmagnezi> kong, kindly wait for the open part :)
20:26:58 <kong> ooh, sorry, i didn't know i am in a 'meeting room'...
20:27:04 <xgerman_> longstaf_ I see two authentications
20:27:16 <xgerman_> 1) Is the token to update status/stats
20:27:29 <xgerman_> 2) is user/pwd to read from Octavia API if needed
20:28:04 <xgerman_> (1) since we are using a library we can leave that for implementation details
20:28:22 <xgerman_> there might be multiple “drivers” with different auth methods
20:29:27 <xgerman_> I am not sure what volume those updates are and if we get a ton every second we likely need to do soemthing different then when they are more sporadic
20:29:47 <jniesz> I think the use-case is  for the driver to update status/stats of only objects that it owns
20:30:08 <jniesz> and the library having protection, so one driver doesn't update status of objects from another
20:30:15 <xgerman_> indeed
20:30:57 <jniesz> shouldn't that be a single auth method, since it would be part of the library
20:31:37 <xgerman_> I like the library to only do the updates… for anyhting else a driver should use the Octavia API
20:31:45 <jniesz> yea, agreed
20:31:56 <jniesz> strictly for status / stats update
20:32:04 <jniesz> anything else should leverage existing apiv
20:32:09 <xgerman_> +1
20:32:27 <longstaf_> agreed
20:33:23 <xgerman_> anyhow I like to keep auth/transport driver specific so we can swap that out if we can’t handle the volume
20:33:38 <xgerman_> or somebody has a weird network topology
20:35:46 <xgerman_> ok, moving on
20:35:52 <xgerman_> #topic Open Discussion
20:37:03 <nmagnezi> kong, ^
20:37:14 <kong> hi
20:37:20 <kong> just wanna ask does that make sense to support http communication between worker and amphora? we don't want to use https in our ci environment, it will increase our complexity
20:37:54 <nmagnezi> to the best of my knowledge it is will not work out of the box
20:38:00 <kong> yeah
20:38:02 <nmagnezi> i looked at it once
20:38:10 <xgerman_> ok, so we generate the certs ourselves and out the amphora-id in them
20:38:33 <xgerman_> then we check if the amphora-id in the server cert matches the one we are supposed to talk to
20:38:52 <nmagnezi> kong, can't you have the same workflow we have in devstack?
20:38:56 <xgerman_> which means if we go to http that would all need to be refactored
20:39:05 <nmagnezi> It's CI... it might fit.
20:39:18 <xgerman_> +1
20:39:20 <nmagnezi> xgerman_, +1
20:39:43 <nmagnezi> xgerman_, that's exactly what I saw when I looked at it in the context of tripleO support
20:40:16 <kong> i want to know if adding an option makes sense
20:40:18 <kong> to the upstream
20:40:38 <kong> we don't want to maintain private code :-)
20:40:39 <nmagnezi> can you describe the usecase?
20:40:58 <xgerman_> yeah, I can’t see anyone wanting less security ;-)
20:41:01 <nmagnezi> what would anyone who use Octavia in production would prefer http over https?
20:41:12 <nmagnezi> what/ why
20:41:20 <jniesz> shouldn't CI match what you would run in prod?
20:41:27 <xgerman_> +1
20:41:50 <nmagnezi> +1
20:41:55 <kong> ok, i know. doesn't make sense to add this kind of thing just for ci
20:42:07 <kong> yeah, in our prod, we use https
20:42:23 <nmagnezi> sorry for that guys but I need to drop
20:42:24 <xgerman_> yeah, since the SSL stuff has a lot of custom things you likely need to test that
20:42:24 <nmagnezi> o/
20:42:26 <kong> just because the specialty of our ci
20:43:09 <kong> i mean, special case
20:43:32 <xgerman_> well, I think we don’t see a need for upstream at the moment but we won’t stop you
20:43:43 <kong> we will try to figure out another way for that, thanks
20:43:51 <xgerman_> ok
20:44:21 <xgerman_> anything else to discuss?
20:45:04 <xgerman_> #endmeeting