| *** xgerman has quit IRC | 00:06 | |
| *** vivek-ebay has quit IRC | 00:07 | |
| *** vivek-ebay has joined #openstack-lbaas | 00:07 | |
| *** vivek-ebay has quit IRC | 00:12 | |
| *** mlavalle has quit IRC | 00:43 | |
| *** crc32 has quit IRC | 01:01 | |
| *** fnaval has quit IRC | 01:04 | |
| *** crc32 has joined #openstack-lbaas | 01:06 | |
| *** blogan_ has joined #openstack-lbaas | 01:06 | |
| *** crc32 has quit IRC | 01:07 | |
| *** fnaval has joined #openstack-lbaas | 01:11 | |
| *** dlundquist has quit IRC | 01:21 | |
| *** sbfox has joined #openstack-lbaas | 01:30 | |
| *** TrevorV has quit IRC | 01:34 | |
| *** TrevorV has joined #openstack-lbaas | 01:35 | |
| *** woodster__ has quit IRC | 01:35 | |
| *** sbfox has quit IRC | 01:44 | |
| *** fnaval has quit IRC | 01:51 | |
| *** sbfox has joined #openstack-lbaas | 01:57 | |
| *** fnaval has joined #openstack-lbaas | 02:15 | |
| *** sbfox has quit IRC | 02:36 | |
| *** fnaval has quit IRC | 03:30 | |
| *** ptoohill_ has joined #openstack-lbaas | 04:07 | |
| *** ptoohill_ has quit IRC | 04:07 | |
| *** ptoohill_ has joined #openstack-lbaas | 04:08 | |
| *** HenryG is now known as HenryG_afk | 04:19 | |
| *** sbfox has joined #openstack-lbaas | 05:50 | |
| *** evgenyf has joined #openstack-lbaas | 06:45 | |
| *** sbfox has quit IRC | 08:01 | |
| *** ptoohil__ has joined #openstack-lbaas | 08:07 | |
| *** ptoohill_ has quit IRC | 08:07 | |
| *** ptoohil__ has quit IRC | 08:12 | |
| *** evgenyf has quit IRC | 08:27 | |
| *** evgenyf has joined #openstack-lbaas | 08:40 | |
| *** [1]evgenyf has joined #openstack-lbaas | 08:53 | |
| *** evgenyf has quit IRC | 08:55 | |
| *** [1]evgenyf is now known as evgenyf | 08:55 | |
| *** neeraj has joined #openstack-lbaas | 08:55 | |
| neeraj | hello all | 08:55 |
|---|---|---|
| neeraj | i am doing a project, in which i need to write load balancer code | 08:56 |
| neeraj | which file of openstack neutron i should look upon? | 08:56 |
| *** neeraj has quit IRC | 09:08 | |
| *** evgenyf has quit IRC | 09:27 | |
| *** evgenyf has joined #openstack-lbaas | 09:41 | |
| *** woodster__ has joined #openstack-lbaas | 12:58 | |
| *** fnaval has joined #openstack-lbaas | 13:11 | |
| *** HenryG_afk is now known as HenryG | 13:24 | |
| *** fnaval has quit IRC | 13:41 | |
| *** markmcclain has joined #openstack-lbaas | 13:56 | |
| *** rolledback has joined #openstack-lbaas | 13:58 | |
| *** fnaval has joined #openstack-lbaas | 14:17 | |
| *** ptoohill_ has joined #openstack-lbaas | 14:30 | |
| ptoohill | neeraj, there's quite a few files that makes up the load balancer code. Is there a particular fix thats needed? | 14:30 |
| *** rolledback has quit IRC | 14:56 | |
| *** rolledback has joined #openstack-lbaas | 15:00 | |
| *** blogan_ has quit IRC | 15:06 | |
| *** sballe has joined #openstack-lbaas | 15:08 | |
| *** mlavalle has joined #openstack-lbaas | 15:13 | |
| *** TrevorV_ has joined #openstack-lbaas | 15:15 | |
| *** sbfox has joined #openstack-lbaas | 15:23 | |
| *** sbfox has quit IRC | 15:26 | |
| sballe | Morning | 15:28 |
| *** blogan_ has joined #openstack-lbaas | 15:30 | |
| *** blogan_ has quit IRC | 15:32 | |
| sballe | dougwig, blogan: Is it worth doing a retrospective on what we learned so far about the openstack process? I am especially interested in this BP deadline. What can we do better for the K release. | 15:33 |
| sballe | Should we add that to the agenda for tomororw's meeting or is it better to discuss this at the summit on we have the whole picture of what we learned from Juno | 15:34 |
| dougwig | a talk about the frustration of attempting to join a group with 300 unwritten rules, all of which are too tiny for anyone to remember to write down after they've learned them, you mean? oh, and the rules change daily. :) | 16:21 |
| *** rolledback has quit IRC | 16:23 | |
| *** sbalukoff has quit IRC | 16:26 | |
| blogan | dougwig you sound a bit....frustrated | 16:27 |
| dougwig | nah, it's just a larger hurdle than most anyone wants to admit. | 16:28 |
| *** xgerman has joined #openstack-lbaas | 16:29 | |
| dougwig | blogan: is the top-level review stable yet? it's been changing daily; i want to start pushing to get these in, but not until it stabilizes. | 16:31 |
| blogan | you mean the extension? | 16:33 |
| blogan | or the first 3? | 16:33 |
| dougwig | the extension | 16:33 |
| blogan | well | 16:34 |
| blogan | i think its stable but i'm sure someone will come in with somethign to fix | 16:34 |
| *** sbfox has joined #openstack-lbaas | 16:35 | |
| *** sbfox has quit IRC | 16:35 | |
| *** sbfox has joined #openstack-lbaas | 16:39 | |
| *** jorgem has joined #openstack-lbaas | 16:42 | |
| dougwig | blogan: might want to double-check your reviews; it just got another ripple up rebase. | 16:50 |
| *** rolledback has joined #openstack-lbaas | 16:56 | |
| *** evgenyf has quit IRC | 17:00 | |
| *** sbfox1 has joined #openstack-lbaas | 17:33 | |
| *** sbalukoff has joined #openstack-lbaas | 17:34 | |
| *** sbfox has quit IRC | 17:35 | |
| *** sbfox has joined #openstack-lbaas | 17:43 | |
| *** sbfox1 has quit IRC | 17:46 | |
| *** sbfox has quit IRC | 17:49 | |
| *** sbfox has joined #openstack-lbaas | 17:49 | |
| *** sballe has quit IRC | 17:50 | |
| *** vivek-ebay has joined #openstack-lbaas | 17:50 | |
| *** fnaval has quit IRC | 17:53 | |
| blogan | dougwig: i think evgenyf did the same thing you did yesterday | 18:04 |
| blogan | or the day before | 18:04 |
| *** rohara has quit IRC | 18:10 | |
| *** sbfox has quit IRC | 18:13 | |
| *** sbfox has joined #openstack-lbaas | 18:18 | |
| *** sbfox has quit IRC | 18:23 | |
| dougwig | yep, that's why i warned you. | 18:27 |
| blogan | oh ha i didnt see your message | 18:34 |
| blogan | i wonder how that happens | 18:35 |
| dougwig | i did a git rebase on my dependent review branch, then merged it into my topic branch, then git review, and "magic" happened. now i re-clone, git review -d, cherry-pick into topic, git review. | 18:44 |
| *** crc32 has joined #openstack-lbaas | 19:02 | |
| *** crc32 has quit IRC | 19:03 | |
| *** crc32 has joined #openstack-lbaas | 19:04 | |
| *** sbfox has joined #openstack-lbaas | 19:10 | |
| *** sbfox has quit IRC | 19:10 | |
| *** sbfox has joined #openstack-lbaas | 19:11 | |
| *** vivek-ebay has quit IRC | 19:20 | |
| *** vivek-ebay has joined #openstack-lbaas | 19:24 | |
| dougwig | anything for today's hangout, or cancel? | 19:30 |
| blogan | i think we decided to cancel until v2 is done | 19:32 |
| blogan | or in a relatively good review state | 19:32 |
| *** fnaval has joined #openstack-lbaas | 19:33 | |
| *** mestery has quit IRC | 19:34 | |
| *** mestery has joined #openstack-lbaas | 19:34 | |
| *** vivek-ebay has quit IRC | 19:43 | |
| dougwig | ok | 19:45 |
| *** rohara has joined #openstack-lbaas | 20:09 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:18 | |
| *** TrevorV_ has quit IRC | 20:27 | |
| *** sbfox has quit IRC | 20:31 | |
| *** vivek-ebay has quit IRC | 20:39 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:41 | |
| *** vivek-ebay has quit IRC | 20:42 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:43 | |
| *** sbfox has joined #openstack-lbaas | 20:50 | |
| *** rolledback has quit IRC | 20:54 | |
| *** Youcef has quit IRC | 21:01 | |
| *** markmcclain1 has joined #openstack-lbaas | 21:27 | |
| rm_work | Hey guys, who is around that could discuss the Barbican/TLS interaction for a few minutes? sbalukoff crc32 xgerman dougwig blogan enikanorov | 21:27 |
| rm_work | vivek-ebay | 21:27 |
| dougwig | i'm here | 21:28 |
| xgerman | sure | 21:28 |
| *** markmcclain has quit IRC | 21:28 | |
| crc32 | Here | 21:28 |
| rm_work | So, I've got all this stuff now around Consumer Registration in Barbican, but… I am not 100% confident that it is actually necessary | 21:28 |
| rm_work | Talking to woodster__ the other day got me thinking | 21:29 |
| rm_work | The real problem we were trying to solve was that a user's Cert/Key needed to be stored in a way we could access and we didn't want to lose track of it | 21:29 |
| rm_work | but… every backend that exists right now will store the cert/key in their own way once we pass it to them, right? | 21:29 |
| rm_work | and once Octavia gets going, it will be storing the certs/keys in Barbican but under its own user account | 21:30 |
| rm_work | is there a reason the API will even need to store what Barbican container the cert/key came from? | 21:30 |
| dougwig | the primary use case that i was thinking of was horizon (or its equivalents) providing an easy way in the cert store interface to put front-and-center all the places that are using said cert, to help the user not screw themselves over. | 21:30 |
| rm_work | well | 21:30 |
| rm_work | would the user be ABLE to screw themselves over? | 21:31 |
| *** sballe has joined #openstack-lbaas | 21:31 | |
| xgerman | dougwig +1 | 21:31 |
| rm_work | even if they deleted the cert from barbican, would neutron-lbaas *ever* need to access the cert again after the initial read? | 21:31 |
| xgerman | well, as a suer it is confusing if you delete something from bbq and it lives on as a zombie | 21:31 |
| rm_work | all of the backends (including Octavia) would store the cert/key on their own terms | 21:31 |
| crc32 | rm_work: The initial requirement is we needed a secure repository to store the keys in. Which every one agreed barbican was. :| | 21:31 |
| rm_work | right | 21:31 |
| rm_work | for *Octavia* | 21:32 |
| dougwig | maybe it's just me, but i'd envision a future where you could store just a barb id, and not copy the cert/key. and to get to that point, i'd want to know who was using things. all the duplication is a maintenance and security headache. | 21:32 |
| xgerman | it was debated that the lb should check during failover if the cert is still there | 21:32 |
| xgerman | dougwig +1 | 21:32 |
| dougwig | as in, octavia on process start would go fetch its key, and not store it anywhere. | 21:32 |
| xgerman | well, there was the sue case we need to fail ove rand the cert is gone | 21:33 |
| xgerman | that was the only case we said we might want to store the cert somewhere else | 21:33 |
| xgerman | (+ carlos had some for caching/spped) | 21:33 |
| dougwig | xgerman: right, but if you warn the user where it's used, and it's deleted anyway, the window for accidental failure versus purposeful is sufficiently tiny that i think you can not worry about it. | 21:33 |
| xgerman | yep, i completely agree. I like a single source of truth more then thousand copies we need to kjeep in sync | 21:34 |
| rm_work | right, but none of the backends at this point use Barbican | 21:35 |
| rm_work | as far as I'm aware | 21:35 |
| rm_work | they all have their own storage mechanisms | 21:35 |
| rm_work | and Octavia will use Barbican, but for this purpose it could be considered a black box | 21:35 |
| rm_work | the actual neutron-lbaas API receives a request to enable TLS with a barbican containerID for cert/key | 21:36 |
| rm_work | but once we read the cert/key and pass it to the driver, the driver stores and utilizes that info | 21:36 |
| rm_work | and the neutron-lbaas API itself won't ever be queried again for that info | 21:36 |
| dougwig | chicken/egg. you'll never get to a single source of truth if you don't include the primitives for people to start using it as such. you can't wait for the backends to evolve there on their own. | 21:36 |
| rm_work | or at least that is my current understanding | 21:36 |
| crc32 | if we don't store the TLS container ids then when ever a cert is being added to an LB we have to reparse the other X509s associated with that loadbalancer for SNI hostname mangling. etc etc. Plus its awkward for a customer to not have a way to retrieve the certificate associated with their loadbalancer. | 21:36 |
| xgerman | yep, but me the user goes in sees all those certificates and wonders where they are used | 21:37 |
| rm_work | AH, so for updates, we need to pass down every cert/key again? | 21:37 |
| rm_work | or at least, we have to assume that it's necessary to do so? | 21:37 |
| rm_work | whether or not every backend requires that or not | 21:37 |
| crc32 | rm_work: yes we need to send a new cert at the minimum the key may be the same though. | 21:38 |
| *** markmcclain1 has quit IRC | 21:38 | |
| dougwig | as a driver author, i'd like to get both the barb id and the cert/key, and i'll pick which i use. the re-parsing issue i'm not worried about, because provisioning changes are still relatively rare events in comparison to actual load balancing. | 21:38 |
| crc32 | xgerman: by not maintaining an association your making this hard to trouble shoot when a user does come back with a matching x509 issue. | 21:39 |
| xgerman | yep | 21:39 |
| rm_work | ok, so the consensus is we *do* still want to track the cert/key in the neutron-lbaas API? | 21:40 |
| xgerman | yes. I think that would be best | 21:40 |
| dougwig | rm_work: does octavia, or any vendor, need the registration in the short-term? no, we're all going to copy. to me, it's purely a long-term thing, with the hope that we stop copying over time. | 21:40 |
| rm_work | I just needed confirmation before I kept rolling ahead with this, as I was starting to be convinced it wasn't strictly necessary | 21:40 |
| crc32 | I'm a fan of Single source of truth but I still have to balance it against trouble shooting and RestApi to RestApi performance lag. | 21:41 |
| rm_work | dougwig: i mean, do you forsee a time when A10's appliance actually uses barbican to pull cert/key instead of storing it on its own? :P | 21:41 |
| xgerman | no worries. The main goal is to get to our pie in the sky that BBQ automatically renews the cert, notifies us, we reload it autmagically or ask the nuser to press oem button | 21:41 |
| crc32 | rm_work: Not strictly needed unless you need to start trouble shooting what cert and key actually made it to the backend. | 21:41 |
| dougwig | if it's more secure, or provides a better user experience, or if some big customer just wants it centralized, absolutely. | 21:42 |
| rm_work | hmm | 21:42 |
| vivek-ebay | just came back | 21:43 |
| vivek-ebay | catching up | 21:43 |
| dougwig | let me flip that around; it's easy to see why a big iron appliance with 500k LB's on it would store its own certs. but if you have a huge pile of soft appliances running those LBs instead... | 21:43 |
| dougwig | the management/maintenance implies treating the soft appliances like cattle, which means the more you push out of them, the better. | 21:44 |
| xgerman | agreed. Octavia has no need to store the cert locally | 21:45 |
| xgerman | and use the annotated one | 21:45 |
| rm_work | so we'd actually pass through the original Barbican ID to Octavia? | 21:46 |
| rm_work | and Octavia wouldn't store its own copy? | 21:46 |
| xgerman | that would be a possibility | 21:46 |
| dougwig | the less state that octavia stores, the easier it will be to shuttle LB's around the nova infrastructure. | 21:46 |
| xgerman | yep | 21:46 |
| xgerman | and it hasn't been decided how failover will work -- which is the only use case of storing a copy | 21:47 |
| dougwig | not to mention, it's one less security headache; no sense doing PKI in multiple places if you can just let barbican handle it. | 21:47 |
| rm_work | my understanding was that: A) The driver interface would only send the raw cert/key, after having decoupled them from Barbican; B) There was not a way for the backends to query upwards to the API layer at a later time to retrieve information | 21:47 |
| rm_work | Thinking about it, possibly B is very misinformed | 21:47 |
| dougwig | the backends are getting the sqlalchemy objects. we can absolutely go uphill. :) | 21:48 |
| rm_work | actually, was B the thing we were specifically trying to enforce so that the backends don't all store their own truths | 21:48 |
| rm_work | ? | 21:48 |
| rm_work | IE, we WANT the backends to query uphill to the API as much as possible for info instead of storing it? | 21:48 |
| blogan | yes and that is what the driver does should it need to get an updated entity | 21:49 |
| blogan | well what the drivers should do | 21:49 |
| dougwig | i'm going to flip that around again, and say that i want to avoid cache coherency and security problems unless i can't avoid dealing with them. | 21:49 |
| rm_work | ok so, different question now -- if we are not going to store a copy of the cert/key on our own in Octavia, would the lack of "hard-delete-prevention" be an issue? | 21:49 |
| dougwig | which implies, it'd be awesome if barbican was the source of truth (if it's fast enough for operational concerns.) | 21:49 |
| rm_work | since we agreed on the ML in the past that storing our own copy of the key in Barbican would be the accepted solution to the problem of the user possibly deleting keys | 21:50 |
| dougwig | if the UI warns the user, which it can do so with registration (a soft lock, as it were), then you've stopped the stupid user case. the api is power users, so they get what they ask for. so no, i think it's avoided in the ui. | 21:50 |
| rm_work | alright | 21:50 |
| xgerman | dougwig +1 | 21:50 |
| rm_work | so we don't want a hard insurance policy | 21:50 |
| dougwig | i want it, i just didn't get it. and i can live with a ui-only version of same. | 21:51 |
| xgerman | yep, and the really case where it was trouble was failover which might be solved differently (e.g. having two lbs configured and running) | 21:51 |
| rm_work | hmm | 21:52 |
| crc32 | no the user could delete their original copy of the TLS container thus breaking future lb fail over type breaks. | 21:52 |
| dougwig | right ,but if they do that, even seeing their cert is in use, it's their problem. we can't protect everyone from everything. | 21:53 |
| crc32 | dougwig: I don't want to relie on UI usage. Straight API users can still hurt them selves. | 21:54 |
| dougwig | IMO - API users are power users; they get what they ask for. | 21:55 |
| rm_work | is "sorry, you did this to yourself" a good thing to be saying on the phone to a customer who just had their site unavailable for some duration because we had a failover event in our datacenter? | 21:55 |
| rm_work | even if it's a power user? :/ | 21:55 |
| rm_work | that's not "Fanatical" :P | 21:55 |
| xgerman | well, as I said we can debate that when we do failover | 21:56 |
| xgerman | failove rmight not involve getting the cert from BBQ | 21:56 |
| *** fnaval has quit IRC | 21:56 | |
| xgerman | because we have 10 LBs running ready to go | 21:56 |
| dougwig | like i said, i'd prefer a force flag. you could always put a layer in front that turned the registrations into an api warning. | 21:58 |
| dougwig | but without it, there is a path forward without copying, i think | 21:58 |
| dougwig | how many phone calls do you get from people that misuse the API and are surprised when it breaks something? :) | 21:59 |
| dougwig | (law of averages means probably many.) | 21:59 |
| crc32 | I don't like the possability of configuring fail over on a loadbalancer. Then delete some randon TLS id from barbican then poof lb failover is broken. That just sucks. | 21:59 |
| rm_work | well, I guess this discussion can be tabled and handled during Octavia design/dev | 22:00 |
| xgerman | yeah, but that is a different discussion than this one | 22:00 |
| rm_work | the original question I had is already answered -- yes, we want to keep the customer's barbican container ID, and yes, we want to register for them | 22:00 |
| rm_work | so thanks for the arguments :P | 22:00 |
| rm_work | I'm re-convinced it's necessary | 22:01 |
| crc32 | xgerman: If we make a decision now then the debate won't even be available when we actually talk about failover. This kinda needs to be finialized early. | 22:01 |
| rm_work | was starting to feel like I wasted the last month | 22:01 |
| xgerman | crc32 I don't think having registration precludes us from decising later that we need to store a copy somewhere | 22:03 |
| xgerman | for all we know we might offer lbs which don't fail over | 22:03 |
| *** fnaval has joined #openstack-lbaas | 22:03 | |
| dougwig | rm_work: i think what you're doing is quite important for more than lbaas, in the long-term. that's just my opinion. without it, we couldn't even have the follow-on conversation. | 22:03 |
| xgerman | yep | 22:04 |
| dougwig | (IMO, of course.) | 22:04 |
| rm_work | kk | 22:05 |
| rm_work | one more opinion question -- Consumer Registration right now takes a "Service Name" and a "Reference URL" | 22:05 |
| rm_work | which for example would be "LBaaS" and "http://api.mycloud.net/v2/lbaas/listeners/<uuid>" | 22:05 |
| xgerman | lgtm | 22:07 |
| rm_work | ok but the question is (sorry, got distracted IRL) | 22:07 |
| rm_work | How many characters do we allow for each | 22:07 |
| rm_work | I have the "Name" at varchar(36) right now | 22:08 |
| rm_work | and "URL" at varchar(120) | 22:08 |
| rm_work | I had them much larger | 22:08 |
| rm_work | but | 22:08 |
| rm_work | I am running into MySQL Constraint constrains (lol) | 22:08 |
| rm_work | *Constraint constaints | 22:08 |
| rm_work | damnit i can't type | 22:08 |
| rm_work | *Constraint constraints | 22:08 |
| rm_work | so my concern with the URL being *only* 120 characters is | 22:09 |
| xgerman | well, if it can't be done | 22:10 |
| xgerman | though I like longer urls and info like which lb it is | 22:10 |
| rm_work | https:// (8) + hostname.com (x) + /v2.0/lbaas/listeners/C57BD591-25CB-44A6-8E2A-1E2FE99C225D (58) | 22:10 |
| rm_work | leaves x = 54 | 22:11 |
| rm_work | also, the 58 characters is just for LBaaS | 22:11 |
| rm_work | other people's URLs could be longer, like if they use multiple uuids | 22:11 |
| *** ptoohill_ has quit IRC | 22:13 | |
| *** sballe has quit IRC | 22:14 | |
| xgerman | yeah, wonder why we can't have 255 or more... | 22:16 |
| dougwig | DNS max hostname len is 1024, so 120 is already flirting with death | 22:16 |
| dougwig | i would think 256/1500 would be enough, if you can get away with it. | 22:17 |
| rm_work | yeaaaah so | 22:22 |
| rm_work | MySQL Constrains have a limit of 790 or so BYTES | 22:23 |
| rm_work | which equates to slightly less than 200 characters | 22:23 |
| xgerman | unicode? | 22:23 |
| rm_work | yes | 22:23 |
| rm_work | >_> | 22:23 |
| rm_work | since max bytesize per char is 4 | 22:23 |
| rm_work | varchar(198) is the max for a constraint | 22:23 |
| rm_work | funnily enough, this is not a problem in sqlite >_> | 22:24 |
| rm_work | http://dba.stackexchange.com/questions/27190/mysql-unique-constraint-on-large-column | 22:24 |
| *** sballe has joined #openstack-lbaas | 22:24 | |
| rm_work | so one solution is to add another column which is a hash of Name+URL | 22:25 |
| rm_work | and just put the constraint on that <_< | 22:25 |
| xgerman | can't you just use a tinyblob or so? | 22:25 |
| rm_work | I guess maybe that's the way to go? | 22:25 |
| xgerman | do we really need to index that field? | 22:26 |
| rm_work | it's a unique constraint | 22:26 |
| xgerman | oh, ok | 22:26 |
| xgerman | it's per listener so that's ok | 22:26 |
| rm_work | Yeah I think I'll probably ask the Barbican folks first but seems like the hash is maybe the best bet | 22:27 |
| dougwig | it's a low volume API, so you could also just do a get/set instead of a constraint. | 22:41 |
| dougwig | (in a transaction) | 22:41 |
| *** mlavalle has quit IRC | 22:58 | |
| *** sballe has quit IRC | 23:04 | |
| *** fnaval has quit IRC | 23:32 | |
| rm_work | dougwig: right, atomicity was my concern with that | 23:34 |
| rm_work | though I think that's pretty ugly anyway | 23:34 |
| rm_work | (I did consider it) | 23:34 |
| dougwig | wrap the get/write in a transaction and it's still atomic, without the constraint. i don't know if our libraries make that easy or not. | 23:35 |
| dougwig | uglier than tiny fields? :) | 23:35 |
| rm_work | well | 23:35 |
| rm_work | i'm going with hashing | 23:35 |
| rm_work | ContainerID+ServiceName+URL -> Hash -> Store in hash_field, put constraint on hash_field | 23:35 |
| rm_work | dougwig: chance of collision should be low… :/ | 23:36 |
| rm_work | like, "i might be more likely to be hit by a comet. while playing volleyball. on a thursday." low | 23:36 |
| dougwig | probably more likely than that, given api retries/multiple api servers. | 23:37 |
| dougwig | :) | 23:37 |
| *** sbfox has quit IRC | 23:42 | |
| rm_work | heh | 23:43 |
| sbalukoff | Hi guys. Just got caught up on the conversation. I agree that hash seems to make sense to handle the unique constraint. | 23:46 |
| *** ptoohill_ has joined #openstack-lbaas | 23:46 | |
| *** ptoohill_ has quit IRC | 23:46 | |
| sbalukoff | Also regarding Octavia and storge of TLS certificates: | 23:46 |
| sbalukoff | I'm not a fan of anything which will create a ticking timebomb later. | 23:46 |
| *** ptoohill_ has joined #openstack-lbaas | 23:46 | |
| sbalukoff | Those always end up being the most annoying support cases to solve, so let's not do that. | 23:46 |
| sbalukoff | If Octavia doesn't have its own store to ensure that failovers (and scaling, when we get there) don't break when a user (stupidly) deletes a key that's in use, then we should force all services using the TLS container to break at the time when the user does a force delete. | 23:48 |
| sbalukoff | I don't see barbican wanting to support those kinds of call-outs on delete... | 23:48 |
| dougwig | sbalukoff: on the spectrum of, 1) users are guaranteed to shoot themselves, and A) users can never shoot themselves, the registration+UI gets you 99% of the way to A), which is why, to me, it starts to become an acceptable tradeoff to not over-complicate for that last 1% (numbers made up out of thin air.) | 23:48 |
| sbalukoff | So, for now I'm in favor of Octavia using its own (redundant) store for these secrets (which will be barbican, but on an 'octavia system user' account instead of the user's account)... | 23:50 |
| sbalukoff | dougwig: I'm thinking of the difficulty troubleshooting for the operator when the user shoots himself in the foot (which he absolutely will, even with a warning) | 23:50 |
| sbalukoff | I agree that registration is a huge step in the right direction. | 23:51 |
| dougwig | it's not a complete solution, agreed. i question how much effort to put in, given that barbican is adding an event stream, probably in the same timeframe that octavia will land. | 23:52 |
| sbalukoff | If we get the event stream, then that will solve the ticking timebomb problem. | 23:52 |
| sbalukoff | And, really, we can cross this bridge when we're actually implementing Octavia. | 23:53 |
| dougwig | yep, hook delete, that's the "right" fix. | 23:53 |
| sbalukoff | Yep! | 23:53 |
| sbalukoff | It might be worthwhile to have the code in there for Octavia to have its own secret store: I can see some operators still wanting to have it even with a delete hook. | 23:54 |
| sbalukoff | (Mostly, large private organizations who occasionally employ stupid application developers. ;) ) | 23:54 |
| dougwig | https://www.irccloud.com/pastebin/KHWe5QHD | 23:55 |
| dougwig | hence, IMO, no. :) | 23:55 |
| dougwig | (says the guy with his own secret store.) | 23:55 |
| sbalukoff | He forgot to mention off-by-one errors. | 23:55 |
| sbalukoff | HAHA | 23:55 |
| sbalukoff | I think it should be a config option to enable/disable a separate secret store for Octavia. | 23:56 |
| *** sbfox has joined #openstack-lbaas | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!