| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-27 | |||
| 00:09:22 | penick | I have a talk on it, one sec.. | |
| 00:09:31 | rm_work | i was hoping to just glance at the repo | |
| 00:09:58 | rm_work | https://github.com/yahoo/athenz ? | |
| 00:10:05 | penick | https://www.openstack.org/videos/vancouver-2018/attestable-service-identity-with-copper-argos | |
| 00:10:13 | penick | yup | |
| 00:10:16 | rm_work | https://github.com/yahoo/athenz/blob/master/docs/copper_argos_dev.md | |
| 00:10:37 | penick | Ayup, that's it | |
| 00:11:10 | rm_work | so basically, we're screwed once Stein hits, and we have to get something like this working before then? :P | |
| 00:11:27 | rm_work | sounds like another day at the office, lol | |
| 00:11:29 | penick | I feel like it benefits me to say Yes :) | |
| 00:11:40 | rm_work | we'll investigate | |
| 00:11:50 | dansmith | rm_work: you should really read the spec you're freaking out about | |
| 00:11:54 | rm_work | I did | |
| 00:11:55 | dansmith | "Since personality file injection will still be supported with older microversions, there will be nothing removed from the backend compute code related to file injection" | |
| 00:12:08 | penick | We're eager to have other people use this, so lmk if y'all (who..are..you?) are interested in using Athenz. It'd be good to get other organizations using/contributing to Athenz | |
| 00:12:14 | rm_work | yeah, but in Octavia we don't necessarily control the nova deployments | |
| 00:12:21 | rm_work | so we can't guarantee they have the thing enabled | |
| 00:12:25 | rm_work | but we still need our stuff to work | |
| 00:12:38 | dansmith | rm_work: oooh, I have good news for you | |
| 00:12:42 | rm_work | penick: we'd be writing something like that into Octavia | |
| 00:12:59 | dansmith | rm_work: user_data will always work? see how nice it is to have features that don't come and go with the deployment choices? :) | |
| 00:13:03 | rm_work | lol | |
| 00:13:15 | rm_work | except user-data already doesn't work :P | |
| 00:13:26 | johnsom | Well, nova is a stable api, so it shouldn't be going away any time soon or they are dropping their stable assertion.... | |
| 00:13:28 | penick | We'll be using octavia with this in the near future. It's one of the things we have to suss out this qtr | |
| 00:13:34 | dansmith | you mean jamming a bus into your wallet won't work | |
| 00:13:35 | penick | But, we already have Athenz in place | |
| 00:13:51 | penick | dansmith: Well not with that attitude | |
| 00:13:57 | dansmith | johnsom: that's what I'm trying to point out | |
| 00:14:08 | rm_work | but you're saying it's already disabled in most nova deploys? | |
| 00:14:25 | dansmith | johnsom: which is what you get if you read a paragraph down below "and now lose your mind" | |
| 00:14:42 | dansmith | rm_work: no, we're saying that file injection is disabled, but as you pointed out we're putting those personality files into the config drive the first time we make it | |
| 00:15:13 | rm_work | [16:38:53] <dansmith>so this has been disabled by default for libvirt for a long time, | |
| 00:15:16 | rm_work | ^^ so what did that mean? | |
| 00:15:24 | dansmith | rm_work: file. injection. | |
| 00:15:41 | rm_work | yes, which has always worked via personality files? | |
| 00:15:48 | dansmith | rm_work: you saw the part where I said "I'm not sure how this is going into config drive" and then ... found and quoted the code right? | |
| 00:15:54 | rm_work | maybe? | |
| 00:16:00 | johnsom | dansmith I was shocked because we hadn't heard of this and it was the *way* to do this securely and reliably and user-data was .... less than ideal | |
| 00:16:35 | rm_work | https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L191-L194 this link? | |
| 00:16:43 | rm_work | I thought that was via libvirt using the thing you said was disabled | |
| 00:16:48 | dansmith | johnsom: you know that config drive is disable-able and depending on it is also not reliable yeah? | |
| 00:16:58 | dansmith | rm_work: no | |
| 00:17:08 | dansmith | rm_work: I get that it says libvirt there, but... | |
| 00:17:35 | johnsom | dansmith We force require it as the metadata service was swiss cheese and blew up if you booted more than a few instances at a time | |
| 00:17:35 | rm_work | if that's not "file injection" then I don't know | |
| 00:17:39 | dansmith | rm_work: the rest of the spec is talking about file injection specifically, which has nothing to do with config drive and is all about violating the very sanctity of the image by forcing large things into small holes | |
| 00:18:10 | rm_work | err | |
| 00:18:16 | penick | rm_work what's generating the secrets that you're putting into the instance? (amphora vms?) | |
| 00:18:16 | rm_work | so *are we using file injection or not*? | |
| 00:18:22 | dansmith | I'm serious, you should totes read the spec :) | |
| 00:18:27 | rm_work | I read the spec | |
| 00:18:41 | rm_work | several sections more than once | |
| 00:18:52 | rm_work | so obviously whatever you're hinting at, i'm not going to get | |
| 00:18:57 | johnsom | Yeah, the terminology in that spec is super confusing compared to the nova API and client API | |
| 00:19:14 | dansmith | that's the point of the first #1 bullet | |
| 00:19:14 | rm_work | this whole conversation started because I asked "is what we are doing the deprecated file injection" and multiple people said "yes" | |
| 00:19:40 | dansmith | users can't know whether they will get the files they send, because either the deployment may have actual injection disabled (the default), | |
| 00:19:40 | rm_work | which #1 bullet, there are several | |
| 00:19:53 | dansmith | or they may have disabled config drive (the other way to get these files) | |
| 00:19:59 | dansmith | rm_work: I said the first :) | |
| 00:20:05 | rm_work | (in fact, I DID notice something new by re-reading -- that SECTION has two, rofl) | |
| 00:20:36 | openstackgerrit | Merged openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440 | |
| 00:20:43 | dansmith | let me try to restate this whole thing | |
| 00:21:03 | dansmith | and if that doesn't help, then I'll leave and you can keep your torches and pitchforks for whatever you want | |
| 00:21:25 | dansmith | in the olden times, | |
| 00:21:32 | dansmith | there was a feature called "file injection" | |
| 00:21:38 | dansmith | there are two halves of said feature: | |
| 00:21:59 | dansmith | 1. The API (personality files) by which people provide this data which may get ignored if config is unfriendly | |
| 00:22:29 | johnsom | Anyhow, any change we can bump that max size of user-data up to a floppy size? Is it just the API limitation and a DB column alter, or is cloud-init going to need to spin too? | |
| 00:22:35 | dansmith | 2. The actual injection part, where the virt driver (some not all) could inject files into images forcibly, literally by taking a hard-coded partition number, and writing over it with your data | |
| 00:22:37 | dansmith | are you with me? | |
| 00:22:45 | dansmith | config drive didn't exist at this point | |
| 00:24:03 | dansmith | aight, I guess nobody wants to hear my story | |
| 00:24:13 | rm_work | i'm trying to parse it | |
| 00:24:27 | dansmith | which part? | |
| 00:24:42 | rm_work | so, file-injection IS what we're using, correct? so right now, we are using both halves of this? | |
| 00:24:47 | dansmith | no, | |
| 00:24:51 | dansmith | you're using the first part, | |
| 00:24:52 | rm_work | or this was just the past, and it's changed now, and you're getting to that | |
| 00:24:56 | dansmith | and another part I haven't gotten to yet | |
| 00:25:00 | rm_work | k | |
| 00:25:23 | dansmith | the #2 part is the really nasty bit, which has been disabled by default, and which we _actually_ want to be rid of | |
| 00:25:44 | dansmith | however, the first part is problematic because we don't store it and it breaks several of our other features (agree to disagree on this) | |
| 00:25:54 | dansmith | so, in the middle ages, long before you showed up, | |
| 00:25:59 | dansmith | this config_drive thing was created | |
| 00:26:14 | dansmith | which was a way to avoid the metadata server's restrictions, complication, whatever | |
| 00:26:47 | dansmith | apparently when we create that the first time, we also put those files in there (TIL) | |
| 00:27:08 | dansmith | but we can't re-create it later, which is the #2 part of the spec problem section | |
| 00:27:10 | dansmith | so, | |
| 00:27:33 | dansmith | you're using the API part, and the config drive part, but not the actual injection thing which is the most smelly bit | |
| 00:27:35 | rm_work | ha, right, which is funny because the #2 "problem" is actually WHY we chose this method | |
| 00:27:45 | dansmith | fine, but whatever | |
| 00:27:55 | rm_work | ok so if #2 was the bad part, and that's just not done anymore... why is the first part being removed? | |
| 00:28:17 | dansmith | #2 is related to the API not the really bad part | |
| 00:28:41 | rm_work | err | |
| 00:28:46 | rm_work | sorry, PART 1 and 2 | |
| 00:29:21 | dansmith | the API part is bad because it takes arbitrary files and then kind keeps track of them, until a rebuild or something and then we lose them | |
| 00:29:25 | rm_work | per "1. The API (personality files) by which people provide this data" and "the #2 part is the really nasty bit, which has been disabled by default, and which we _actually_ want to be rid of" | |
| 00:29:36 | rm_work | hmmm | |