Monday, 2015-10-19

« Sunday, 2015-10-18 Index Tuesday, 2015-10-20 »
johnsomFYI, the regression in coverage has been released in version 4.0.1 on pypi.  Our Sonar job is back in business00:00
*** vivek-ebay has joined #openstack-lbaas00:18
*** clev is now known as clev-away00:41
*** chlong has joined #openstack-lbaas01:01
*** chlong has quit IRC01:03
*** chlong has joined #openstack-lbaas01:05
*** chlong has quit IRC01:05
*** chlong_ has joined #openstack-lbaas01:05
*** chlong_ has quit IRC01:05
*** chlong has joined #openstack-lbaas01:06
*** ducttape_ has joined #openstack-lbaas01:32
*** Brian_shang has joined #openstack-lbaas01:37
xgermanyeah!!01:39
*** sbalukoff has joined #openstack-lbaas01:59
*** doug-fish has joined #openstack-lbaas02:04
*** ducttape_ has quit IRC02:05
*** doug-fi__ has joined #openstack-lbaas02:06
*** doug-fis_ has quit IRC02:06
*** yfujioka has joined #openstack-lbaas02:08
*** doug-fish has quit IRC02:09
*** amotoki has joined #openstack-lbaas02:40
*** amotoki has quit IRC02:41
*** amotoki has joined #openstack-lbaas02:42
rm_you|wtfnoice02:56
*** rm_you|wtf is now known as rm_you02:56
*** vivek-ebay has quit IRC03:03
*** clev-away is now known as clev03:41
*** vivek-ebay has joined #openstack-lbaas03:47
*** clev is now known as clev-away03:57
*** Brian_shang has quit IRC04:11
*** Brian_shang has joined #openstack-lbaas04:11
*** amotoki has quit IRC04:17
*** amotoki has joined #openstack-lbaas04:17
*** yfujioka_ has joined #openstack-lbaas04:41
*** yfujioka has quit IRC04:44
*** yfujioka_ has quit IRC04:44
*** yfujioka has joined #openstack-lbaas04:44
*** amotoki has quit IRC05:22
*** amotoki has joined #openstack-lbaas05:29
*** numans has joined #openstack-lbaas05:43
*** ljianbj has joined #openstack-lbaas05:45
*** amotoki has quit IRC05:54
*** amotoki has joined #openstack-lbaas05:57
*** amotoki has quit IRC05:59
*** sbalukoff1 has quit IRC06:01
*** sbalukoff1 has joined #openstack-lbaas06:13
*** amotoki has joined #openstack-lbaas06:34
*** nmagnezi has joined #openstack-lbaas06:38
*** amotoki has quit IRC06:39
*** amotoki has joined #openstack-lbaas06:39
*** evgenyf has joined #openstack-lbaas06:40
*** yamamoto has joined #openstack-lbaas06:55
*** amotoki has quit IRC07:01
*** amotoki has joined #openstack-lbaas07:19
*** chlong has quit IRC07:23
*** kobis has joined #openstack-lbaas07:31
*** bana_k has quit IRC07:42
*** vivek-ebay has quit IRC07:58
openstackgerritBertrand Lallau proposed openstack/neutron-lbaas: Use AssertIsNone  https://review.openstack.org/23684308:37
openstackgerritBertrand Lallau proposed openstack/neutron-lbaas: Use assertIn and assertNotIn  https://review.openstack.org/23684608:52
*** vivek-ebay has joined #openstack-lbaas08:58
*** vivek-ebay has quit IRC09:03
*** evgenyf has quit IRC09:05
*** evgenyf has joined #openstack-lbaas09:06
*** openstack has joined #openstack-lbaas09:18
openstackgerritBertrand Lallau proposed openstack/octavia: use assertTrue instead of assertEqual(True, ***)  https://review.openstack.org/23686309:27
openstackgerritBertrand Lallau proposed openstack/octavia: Use assertIn and assertNotIn  https://review.openstack.org/23686409:30
openstackgerritKobi Samoray proposed openstack/neutron-lbaas: Add TLS support to VMWare Edge LBaaSv2 driver  https://review.openstack.org/23686609:32
*** evgenyf has quit IRC09:35
*** nmagnezi has quit IRC10:36
*** Brian_shang has quit IRC10:40
*** Brian_shang has joined #openstack-lbaas10:40
*** nmagnezi has joined #openstack-lbaas10:51
openstackgerritBertrand Lallau proposed openstack/octavia: Use assertTrue instead of assertEqual(True, ***)  https://review.openstack.org/23686311:07
*** evgenyf has joined #openstack-lbaas11:22
*** doug-fish has quit IRC11:22
*** doug-fish has joined #openstack-lbaas11:25
*** rtheis has joined #openstack-lbaas11:27
openstackgerritBertrand Lallau proposed openstack/octavia: Fix argument order for assertEqual  https://review.openstack.org/23691711:36
openstackgerritKobi Samoray proposed openstack/neutron-lbaas: VMWare NSXv LBaaSv2 driver  https://review.openstack.org/22726611:51
openstackgerritKobi Samoray proposed openstack/neutron-lbaas: Add TLS support to VMWare Edge LBaaSv2 driver  https://review.openstack.org/23686611:51
openstackgerritBertrand Lallau proposed openstack/octavia: Fix argument order for assertEqual  https://review.openstack.org/23691711:53
*** amotoki has quit IRC12:00
*** ducttape_ has joined #openstack-lbaas12:11
*** diogogmt has quit IRC12:19
*** ducttape_ has quit IRC12:36
*** amotoki has joined #openstack-lbaas12:38
*** Kiall has quit IRC12:42
*** Kiall has joined #openstack-lbaas12:44
*** diogogmt has joined #openstack-lbaas12:45
*** amotoki has quit IRC12:47
*** amotoki has joined #openstack-lbaas13:08
*** yamamoto has quit IRC13:11
*** diogogmt has quit IRC13:19
*** mestery has joined #openstack-lbaas13:24
*** vivek-ebay has joined #openstack-lbaas13:34
*** vivek-ebay has quit IRC13:39
*** evgenyf has quit IRC13:51
*** yamamoto has joined #openstack-lbaas13:52
*** ducttape_ has joined #openstack-lbaas14:02
*** ajmiller has joined #openstack-lbaas14:21
*** diogogmt has joined #openstack-lbaas14:32
*** chlong has joined #openstack-lbaas14:40
*** TrevorV|Home has joined #openstack-lbaas14:52
*** diogogmt has quit IRC15:10
*** diogogmt has joined #openstack-lbaas15:11
*** ajmiller has quit IRC15:14
*** sbalukoff has quit IRC15:21
*** nmagnezi has quit IRC15:22
rtheisWith LBaaS v1 deprecated in Liberty, how does this impact bug fixes for v1 in Kilo, Liberty and Mitaka?  That is, will v1 fixes be accepted for all of these releases based on the stable branch policy?15:28
xgermanI think we will accept bug fixes but their won’t be any active work15:29
rtheisthanks15:29
*** vivek-ebay has joined #openstack-lbaas15:40
*** Alex_Stef has joined #openstack-lbaas15:43
*** armax has joined #openstack-lbaas15:52
*** kobis has quit IRC15:55
dougwigmorning.16:02
johnsomMorning dougwig16:02
johnsomSee you could totally make the oslo meeting....16:03
johnsomgrin16:03
*** vivek-ebay has quit IRC16:12
*** Aish has joined #openstack-lbaas16:22
*** armax_ has joined #openstack-lbaas16:27
*** Aegil_ has quit IRC16:29
*** telmich has quit IRC16:29
*** armax has quit IRC16:29
*** chlong has quit IRC16:29
*** mestery has quit IRC16:29
*** armax_ is now known as armax16:29
*** telmich has joined #openstack-lbaas16:30
*** telmich has joined #openstack-lbaas16:30
*** Aegil has joined #openstack-lbaas16:30
*** davidlenwell_ is now known as davidlenwell16:36
*** Alex_Stef has quit IRC16:40
*** chlong has joined #openstack-lbaas16:42
*** kiran-r has joined #openstack-lbaas16:56
*** vivek-ebay has joined #openstack-lbaas16:57
*** vivek-ebay has quit IRC16:57
*** vivek-ebay has joined #openstack-lbaas16:57
*** kiranr has joined #openstack-lbaas17:00
*** openstackgerrit has quit IRC17:01
*** openstackgerrit has joined #openstack-lbaas17:02
*** kiran-r has quit IRC17:02
xgermanrm_work barbican question17:03
xgermando I still need to clone stuff to get it into devstack17:04
rm_workno17:05
rm_workjust enable_plugin17:05
xgermanoh, ok17:05
xgermanfigured17:05
rm_worksee my script here: https://gist.github.com/rm-you/f7585ca4932b3ee1eed917:05
xgermanstill need to clone — or just add to the list of enabled plugins17:06
xgerman?17:06
xgermangotvha17:06
*** numans has quit IRC17:13
*** klindgren__ is now known as klindgren17:17
*** ajmiller has joined #openstack-lbaas17:28
*** orion__ has joined #openstack-lbaas17:28
dougwigneutron cross project (including adv.services), add your input to the bottom: https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration17:31
*** numans has joined #openstack-lbaas17:36
johnsomdougwig I'm a git lost on context.  Is this where we discuss requests of other teams?17:39
*** kiranr has quit IRC17:40
johnsomi.e. nested virtualization enabled in the gate hosts?17:40
dougwiganything outside neutron, or mix and match neutron teams, that needs face time or coordination.17:41
dougwigthat's a possible topic, yes.17:41
johnsomI don't have high hopes, but I can throw it in the ring17:43
*** bana_k has joined #openstack-lbaas17:50
*** yamamoto has quit IRC18:00
*** sbalukoff has joined #openstack-lbaas18:09
*** yamamoto has joined #openstack-lbaas18:09
*** armax has quit IRC18:10
*** yamamoto has quit IRC18:21
*** devlaps has joined #openstack-lbaas18:22
openstackgerritGerman Eichberger proposed openstack/neutron-lbaas: Adds a Barbican option to local.conf  https://review.openstack.org/23712518:25
rm_workah cool18:27
xgermanrm_work, not cool https://bugs.launchpad.net/neutron/+bug/150772318:31
openstackLaunchpad bug 1507723 in neutron "Octavia Barbican cert manager broken" [Critical,Confirmed]18:31
rm_workhmm18:31
rm_workabout to head to a doctor appointment18:31
rm_workwill look when i get back18:31
xgermanthanks18:31
rm_workit just uses python-barbicanclient18:32
rm_workso maybe something changed?18:32
xgermanyep18:32
rm_workhmm18:32
rm_work{"URL": null, "name": "Octavia"}18:32
rm_workthat doesn't look right18:32
rm_workit isn't passing the right LB URL18:32
rm_workthat is the rpoblem18:32
rm_workRESP BODY: {"code": 400, "description": "Provided object does not match schema '18:32
rm_workConsumer': None is not of type 'string'. Invalid property: 'URL'", "title": "Bad18:32
rm_work Request"}18:32
xgermanmmh18:33
xgermanfix it :-)18:33
rm_worklol18:33
rm_workk i'll look when i get back18:33
xgermanthanks18:33
rm_workunless pc-pothole sees it first :P18:33
pc-potholemaybe its missing certain config values or something. Though i havnt messed with it in a while and nothing has changed. I love when thing just magically start breaking18:40
*** armax has joined #openstack-lbaas18:41
*** amotoki has quit IRC18:55
pc-potholeI see the issue. This was all tested and verified with the ssh driver. I had made changes to tls processing in a common place and notified so the other drivers could be updated also. That unfortunately didnt happen. Since registration happens in the frontend/n-lbaas the backend/octavia doesnt need to reg. Ideally, the rest driver needs updated to use the cert_parser utils.18:58
pc-potholeor, just add check-only=True as an arg18:59
*** ducttape_ has quit IRC19:22
*** ducttape_ has joined #openstack-lbaas19:22
*** crc32 has joined #openstack-lbaas19:23
bana_kblogan: I followed your suggestion and got multiple commits. https://review.openstack.org/#/c/236048/. and How do I select a particular commit from that group of commits to amend them. git checkout commitid?19:26
markvanFYI, I put up two patches related to LBAAS V2 in the gates: https://review.openstack.org/#/c/237124/ and https://review.openstack.org/#/c/237156/19:28
*** woodster_ has joined #openstack-lbaas19:37
xgermanpc-poythole sorry19:39
xgermanprobably need to get that all fixed19:40
pc-potholeI was working on it19:42
xgermanso should I fix or you?19:48
pc-potholeI just need to debug this test19:49
pc-potholewhich isnt playing nice :/19:49
xgermanok19:49
xgermanI know I copied & pasted everything originally from the ssh driver...19:49
pc-potholeYea, then you had asked to have it put in common place, so i did that19:50
pc-potholei think i messaged you directly that it was ready. But its not a biggie19:50
pc-potholewell19:51
pc-potholeits too late for any fixes for L right?19:51
xgermanwe can always back port ;-)19:52
pc-pothole:)19:52
xgermanand sorry I dropped the ball on that one19:52
*** amotoki has joined #openstack-lbaas19:56
pc-potholeoh, no worries, lots going on and i never tested tls with rest but attempting to put it in the lab. so im glad it was brought up sooner rather than later. but ya know19:57
*** amotoki has quit IRC20:00
openstackgerritGerman Eichberger proposed openstack/octavia: Adds cert_mamanger option to octavia.conf  https://review.openstack.org/23718320:03
*** minwang2 has joined #openstack-lbaas20:04
openstackgerritMichael Johnson proposed openstack/octavia: Amphora Flows and Drivers for Active Standby  https://review.openstack.org/20625220:06
*** diogogmt has quit IRC20:16
*** yamamoto has joined #openstack-lbaas20:30
*** yamamoto has quit IRC20:34
*** fnaval has joined #openstack-lbaas20:41
*** amotoki has joined #openstack-lbaas20:57
fnavaljohnsom: hi, i'm here21:01
*** amotoki has quit IRC21:02
johnsomSent you some pms21:03
fnavalkk thanks21:03
rm_workxgerman: such cert_mamanger21:19
xgermanyep, typo21:19
xgermanmight need to respin21:19
rm_workyeah21:20
rm_workalso per my comment21:20
rm_workneed to respin anyway21:20
xgermanok, will do21:21
openstackgerritGerman Eichberger proposed openstack/octavia: Adds cert_manager option to octavia.conf  https://review.openstack.org/23718321:24
xgermanok, got those small changes respun21:24
openstackgerritPhillip Toohill proposed openstack/octavia: Fixes TLS processing in the rest driver  https://review.openstack.org/23720721:32
pc-potholexgerman: Take a look at that when you can, please21:32
*** rtheis has quit IRC21:32
xgermanchecking...21:41
rm_workxgerman: should you have a thing like you did on the second below21:42
xgermanwill resin my devstack and test21:42
rm_workwhere it says the options?21:42
rm_work# Certificate Manager options are local_cert_manager21:42
rm_work^^21:42
rm_worki guess ... there is only one option21:42
rm_worklol21:42
rm_workso nevermind21:42
xgermanyep, only one which wortks21:42
rm_workuntil we get anchor up and running21:43
xgerman+121:43
rm_workah also i am writing a BP currently21:43
rm_workjust a heads up21:43
xgermanfor what?21:43
rm_workwe will need to change our API/storage a little bit to actually accept a Private Key Passphrase21:43
rm_workdirectly21:43
rm_workand store it21:43
rm_workit solves the cross-tenant vuln21:43
xgermanah, yeah somebody mentioned that21:43
rm_workyou on board with that?21:43
rm_workneed more context?21:43
rm_workI will have a BP which hopefully will be useful21:44
xgermanmmh, not sure why we can’t keep Barbican save21:44
rm_workbut the short story is21:44
rm_workit provides a sort of two-factor21:44
rm_workso here's the scenario that breaks ACLs:21:44
rm_workUser A sets up their PK in barbican21:44
rm_workand sets ACLs for LBaaS Service Account21:44
rm_workand creates a LB21:44
rm_worksorry, Alice does this21:44
xgermanok, Alice :-)21:45
rm_workEve gets the uuid of the secret, but can't retrieve it ... BUT Eve can create a LB using it, which happily retrieves Bob's secret because the lbaas service account21:45
rm_workhas the correct ACLs21:45
rm_workbecause it needed to access Bob's secret for Bob's LB21:45
rm_workerr21:46
rm_workdamnit I switched from Alice to Bob21:46
rm_workwhatever21:46
rm_workAlice and Bob are the same account <_<21:46
xgermanwell, I get the idea21:46
rm_worklol21:46
rm_workyeah21:46
xgermanmmh, but we know the tenant-id of the user creating LB + tenant-id of the cert?21:46
rm_workso if AliceBob's PK is passphrase protected, we can store the passphrase separately in LBaaS21:46
rm_workwhich is useless by itself, but also makes the PK useless unless Eve also knows the passphrase21:47
rm_workand it is not retrievable via API21:47
rm_workxgerman: to get the tenant-id of the cert, we have to actually try to retrieve it21:47
rm_workbut yes, we could kick it back at that point if tenant-ids don't match21:47
xgermanthat just makes it so that Alice can create certs for Bob to use in his load balancers if they share the private key21:47
rm_workBUT21:47
rm_workthat disables another usecase21:47
rm_workwhich is that someone actually is using two different accounts on purpose21:47
xgermanyep21:47
rm_workyeah21:47
rm_workexactly21:48
rm_workso, storing passphrase directly in LBaaS / VPN / FWaaS would solve that21:48
rm_workmake sense?21:48
xgermanwell, I think more that the unlocking should be per account21:48
rm_workstepping back, does it seem reasonable to do this?21:48
xgermanisn’t that what ACL’s are for?21:48
rm_workxgerman: the problem is that the ACLs allow our whole account to use the resource21:48
rm_workwhich, unless we have a service-account per tenant21:49
rm_workis not feasible21:49
rm_workerr, is not possible to then restrict in any useful way21:49
xgermanyep, but Barbican should help us by allowing it to scope to a specific tenant, e.g. we are doing that on behalf of user X21:49
rm_workother than blocking any non-matching tenant, which we just talked about and agreed disables a valid use-case21:49
rm_workxgerman: that's getting a little nuts21:49
rm_workand how is that enforced at all21:49
rm_workwe are a service account21:50
rm_workhow do we prove to barbican which user-id we're doing something on behalf of?21:50
rm_workinternally we actually do have a mechanism for doing that (which we'll be using on top of the passphrase thing, because it has its own issues in this workflow)21:51
xgermanI am pretty sure other services (VPNaS ahem) would ahem the same problem so it should be solved in Barbican21:51
rm_workbut in upstream keystone, i don't know a way to do it21:51
rm_workxgerman: yeah i am saying we'd have to do this same thing in every service essentially21:51
rm_workbut I think of it kinda like two-factor21:51
xgermanwell, it’s not like our DB is really “protected” so Alice can easily hack it21:52
rm_workwell21:52
rm_worki mean i wouldn't say easily21:52
rm_workbut if she can hack our whole DB i think we have bigger trouble21:52
rm_workbut she still wouldn't have the actual PK21:53
rm_workunless she went in and got it from Barbican21:53
rm_workand if she was able to hack our DB, was she able to grab our keystone credentials too? at which point she can get anything of the user's that is in Barbican too <_<21:53
rm_workat some point everything goes off the rails21:53
rm_workI can write up the BP I'm suggesting, and we can discuss it at the summit?21:54
rm_workseems like a great time :P21:54
xgermanyeah, sounds good21:54
rm_workI will get the BP up before the summit21:54
xgermanI just think Barbican should have a solution for that problem21:54
rm_workthe problem is actually that it'd then all be within one system21:54
rm_workwhich is the vulnerability in the first place21:54
xgermanwhich is backed by crypto hardware21:55
rm_workbut which acts exactly like our system, in that the crypto passphrases are in config files :P21:55
rm_workbecause their API needs to be able to pull stuff out21:55
rm_worklol21:55
rm_workthe hardware crypto is really just preventing against an offline attack21:55
rm_worknot an online one21:55
rm_workif you get access to barbican's HSM creds, it's toast anyway21:56
xgermanyeah, we need to talk that through with security people21:56
rm_workthe best we can do for security is split up the access so half is in one system and half is in another21:56
rm_workwill you have people at the summit?21:56
rm_workthe Barbican team is on board with this plan as of currently21:57
xgermanyeah, they usually go21:57
rm_workjust got out of meetings with them21:57
xgermanwell, they are on board with any plan which means work for us21:57
rm_workheh21:57
rm_workand i am acutely aware that it is work for us :(21:57
rm_workbut21:57
rm_workI think it's the right move, because as of yet I haven't heard any better ideas21:57
rm_workbut I am all ears :P21:57
rm_workanything that solves for all of the use-cases and vulnerabilities that come along with them21:57
*** yamamoto has joined #openstack-lbaas21:58
xgermanwell, if they say manage an ACL of tenant ids per secret + allow us to ship the tenant we are doing it on behalf of that does the same thing21:58
rm_workthat'd be a keystone feature21:58
rm_workthat doesn't exist upstream21:58
rm_workwe have no way to prove we're doing something "on behalf of" a specific user21:58
xgermanwell, wouldn’t that be BBQ because we authenticate with our Octavia tenant and then we tell them we want to retrieve cert 1 for tenant Alice21:59
rm_workright21:59
rm_workbut21:59
rm_workthat's just us telling them that21:59
rm_workdoesn't really secure it21:59
rm_worki mean it's kinda better22:00
rm_workbut not *really* hardened22:00
xgermanwell, the Barbican API is secured with a short lived (Abchor based) SSL certs22:00
xgerman+ you have apices rules22:00
xgermanipsec22:00
rm_workyeah22:01
xgermanso you still need to own our box to do soemthing22:01
xgermanwhich we said earlier is the same attack vector we can’t guard against22:01
rm_workyeah, though this also helps protect against other threats22:02
xgermannow users are “used” to enter the certificate passphrase so their is some UX precedence22:02
rm_worklike if a single system is compromised (ie, barbican)22:02
xgermanbut I can also set that to nothing22:02
rm_worktheir PK would still be safe22:02
rm_workyeah, it'd be optional22:03
rm_workbut recommended22:03
xgermanand then we would need to store it so we can do failures, etc.22:03
xgermanfail-overs22:03
rm_workyes we need to store it22:03
rm_workas i was saying, it'd be a DB change as well22:04
xgermanor we store it in barbican ;-)22:04
rm_workergh22:04
rm_workbut then it's in the same single system22:04
rm_workand vulnerable to single-system-compromise22:04
rm_workif we store it locally we have the best of both worlds22:05
rm_workrequires both systems to be compromised22:05
xgermannot really - we will have a copy of the cert on the amphora as well22:05
xgermanguess lot’s of discussion ahead22:05
rm_workyeah, true there it will be unencrypted22:05
rm_workbut we can't pull it off22:05
rm_workand our images will not have SSH enabled, I believe22:05
xgermanyep22:06
rm_workso unless they compromise the container host22:06
rm_work<_<22:06
rm_workwhich is all kinds of bad too22:06
rm_workhard to protect against that22:06
xgermanyep22:06
xgermanalso if we have the passphrase what is barbican actually buying us when storing the cert?22:07
xgermancan’t we just put that in swift now?22:07
*** TrevorV|Home has quit IRC22:07
rm_workxgerman: kinda? :?22:09
rm_work:/22:09
rm_workit honestly doesn't buy us a WHOLE lot <_<22:09
xgermanyeah, but those barbican people have a knack for coming up with resons/features making them obsolete22:11
*** ajmiller has quit IRC22:11
rm_workheh22:11
rm_workxgerman: we'll discuss at the summit22:11
xgermanyep22:11
rm_workwe can pull some of the barbican folks into a room, and some of the RAX security guys and HP security guys22:12
rm_workand we'll have the rest of the lbaas people too22:12
xgermanexactly22:12
rm_workxgerman: full disclosure, doing it this way also helps us a lot internally, but i still think it is the right move to make upstream as well, regardless of what we are doing at RAX22:12
*** ajmiller has joined #openstack-lbaas22:12
xgermanwell, our Barbican is hooked up to a crypto drive so there must be a better solution than use that as an expensive replacement for swift22:13
xgermanI put my and my families passports in a  bank deposit box — so by your logic being afraid of the bank being robbed I keep hal the passports at home?22:15
xgermanor rip out some pages?22:15
rm_worknot a horrible analogy -- but now imagine it is 1000 times more likely that banks get robbed, and if they have your passport they own everything about you22:17
xgermanwell, if we put keys into our DB, it needs to be backed ups securely, logs, etc.22:19
xgermanwhereas if they do everything behind the scenes that feels more clean22:19
xgermanand my bank sort of makes me enter a pin and bring a key before I get into the vault22:20
rm_workwell right22:20
rm_workso in this case think of it like22:20
*** orion__ has quit IRC22:20
rm_workyour bank requires a key and a signature to get your passport22:21
xgermanno, a pin22:21
rm_workok, sure, key and pin22:21
xgermanmy banking pin22:21
rm_workso the key is your API key for barbican22:21
rm_workand the PIN is your passphrase stored in LBaaS22:21
xgermanwell, that would be me the user22:21
rm_workyeah, so it's kinda like you gave your friend Chuck a copy of your key, and told him your pin22:22
rm_workand if Chuck loses the key22:22
rm_workor you lose your original22:22
rm_workthey still need Chuck to type the PIN22:22
xgermanwell, they also know me and would get suspicious if Chuck shows up22:23
rm_workno, since you've added Chuck to the bank's register for your account (ACLs)22:23
rm_workthis analogy is lulz22:23
xgermanok, so Chuck comes put in his pin brings my key22:23
xgermanand gets the stuff22:24
rm_workif someone mugs Chuck at that point, sure, you're out of luck22:25
rm_workbut Chuck has a bodyguard22:25
rm_work(no SSH access to VMs)22:25
rm_workif someone takes out the bodyguard (gets root access to the hypervisor), then sure22:25
xgermanbut we are sort of part of the bank...22:25
rm_work<_<22:26
*** amotoki has joined #openstack-lbaas22:28
*** amotoki has quit IRC22:32
rm_workjohnsom: you there?22:33
rm_workjohnsom: fnaval is saying you found a way to turn on nested virt flags in RAX cloud? is that true?22:34
rm_workjohnsom: AFAIK it is disabled at the hypervisor layer22:34
johnsomHi22:34
johnsomI have no idea if you can turn it on in the RAX cloud.  I think xgerman said there are certain hosts available.22:35
rm_workpc-pothole: oh cool, so you got that handled, awesome22:35
johnsomI was just trying to explain why his tests were taking so long22:36
rm_workjohnsom: ah, so is there a way to enable it or no?22:36
rm_workI was guessing no22:36
johnsomI run on vmware so it's check box.  There are instructions here for KVM: http://docs.openstack.org/developer/devstack/guides/devstack-with-nested-kvm.html22:37
johnsomNot sure if any of those apply22:37
johnsomMaybe xgerman knows more about the hosts that have this enabled at RAX22:37
rm_workrax cloud is Xen AFAIK22:38
xgermanthere was some e-mail earlier from Adrian Otto saying there is a special magnum pool — dougwig forwarded that22:38
xgermanit’s oil openstyack-infra22:38
rm_workhmm k22:39
rm_workinteresting22:39
*** ducttape_ has quit IRC22:39
xgermanrm_work: http://comments.gmane.org/gmane.comp.cloud.openstack.infrastructure/312722:42
rm_workwtf22:43
rm_workwhy couldn't we get them to do this for us22:43
rm_worki guess maybe we didn't talk to the right people :P22:43
rm_workxgerman: looks like that thread just kinda died22:49
rm_workand the conclusion was "maybe, but ... we're dubious"22:49
xgermanyeah, but it shows you have that kind of hardware ;-)22:49
*** fnaval has quit IRC22:55
rm_workxgerman: hmm, yeah i knew we did, but... getting it available to infra is an interesting step22:55
rm_workxgerman: i would like to reply to that email but I am not even subscribed to openstack-infra22:55
rm_workand not sure how i'd effectively reply to it since i don't have a copy22:55
rm_worki guess just set the subject properly and copy/paste in the body from that page you linked? lol22:56
xgermanyep, also there is only one devlist?22:56
xgermannope, it’s in fra22:56
xgermanyeah, if you repply they will bounce you until you subscribe IHMO22:56
*** divya has quit IRC22:57
*** TrevorV has joined #openstack-lbaas23:00
rm_workyeah23:03
rm_worki think that's right T_T23:03
rm_workI am just going to poke infra people in their IRC channel and then see about meeting up at the summit23:03
rm_workneed to start making a list of "things I need to schedule meetings for at the summit, whether in a meeting room or at a bar after"23:03
*** crc32 has quit IRC23:23
openstackgerritGerman Eichberger proposed openstack/octavia: Stop checking if listener exists when uploading cert  https://review.openstack.org/23728223:25
rm_youxgerman: interesting23:29
rm_youyeah ironically i still haven't gotten a chance to see this stuff actually work front to back23:30
xgermanwell, I am playing with it in devstack23:30
rm_youi wrote a bunch of barbican code in a void months ago and then got dragged onto other stuff internally T_T23:30
rm_youso i am not sure what happened with the workflows23:30
xgermanyeah, I think we switched to REST but never made sure TLS actually works23:31
xgermannow hopefully I can just do some trick to get a new amp image23:32
*** TrevorV has quit IRC23:40
*** ajmiller has quit IRC23:52
openstackgerritGerman Eichberger proposed openstack/octavia: Stop checking if listener exists when uploading cert  https://review.openstack.org/23728223:57
« Sunday, 2015-10-18 Index Tuesday, 2015-10-20 »

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!