| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-03 | |||
| 17:46:27 | dansmith | sean-k-mooney: given how hyperv moves things I expect it's tracked by the hypervisor and so it just works, but I could be wrong | |
| 17:46:54 | sean-k-mooney | https://github.com/openstack/compute-hyperv/commit/f37ce8b6bb0eb88a367239698ba7c3df3b64db38 | |
| 17:47:01 | dansmith | the question is more about how things like snapshot works | |
| 17:47:10 | sean-k-mooney | they have an os_vtpm image property | |
| 17:50:00 | sean-k-mooney | they must have patches against nova because the ImageMetaProps object does not accept os_vtpm or os_shielded_vm | |
| 17:53:13 | dansmith | looks like maybe they're doing some mangling of instance.hostname to reference specific keys or something? | |
| 17:53:24 | dansmith | and they're illegally stashing their own stuff in insance.metadata | |
| 17:53:35 | dansmith | so all manner of hacks in that implementation | |
| 17:53:43 | sean-k-mooney | yep | |
| 17:53:55 | sean-k-mooney | and none of this is supported in the in tree one | |
| 17:56:42 | sean-k-mooney | im looking at there snapshot function now https://github.com/openstack/compute-hyperv/blob/cb203978f262f31790592b2a0692fc2acaaef33d/compute_hyperv/nova/snapshotops.py#L66 but i think its just of the image so they dont snapshot the tpm? | |
| 17:57:32 | dansmith | I dunno, but since they've already broken many rules of user interaction, looking further into how they handle it doesn't seem like it would help guide us | |
| 17:57:58 | sean-k-mooney | it proably wont but it looks like they just ignored it | |
| 17:58:27 | sean-k-mooney | so i guess there stance was the tpm state would not be resoreted if you restored form a snapshot | |
| 17:58:39 | sean-k-mooney | the same way non root disks are not restored | |
| 17:59:40 | dansmith | or there is magic in the hostname mangling stuff so that if you recreate an instance with the right magic hostname, it will re-get the tpm stored in the hypervisor? | |
| 18:00:39 | dansmith | given that they basically implement features by bounty in that out of tree driver, I expect they implemented just the part of the solution that would suffice for the one customer asking for it | |
| 18:01:26 | sean-k-mooney | i dont think they are manageling the path in the metatada but yes i would guess the custoemr did not ask for snapshotiing so they did not add it | |
| 18:02:54 | efried | To me, the only severe issue is evacuate. The rest should be easy to understand with proper documentation. | |
| 18:02:59 | sean-k-mooney | i think they were using the vtpm soly for disk encryption | |
| 18:03:19 | efried | "vTPM is tied to your instance. Don't expect to be able to snapshot and clone it." | |
| 18:04:13 | efried | "You can back up and restore as long as you use 'backup'." | |
| 18:04:44 | sean-k-mooney | ? you use backup | |
| 18:05:26 | sean-k-mooney | you mean as long as you rebuild form a snapshot and dont launch an new instance right | |
| 18:05:46 | efried | No. I mean as long as you use rebuild from an image created via the createBackup server action | |
| 18:06:07 | sean-k-mooney | right but does that not just create a shapshot | |
| 18:06:11 | efried | 'snapshot' isn't a server action. There's createImage and createBackup. Both of them snapshot under the covers. | |
| 18:06:23 | sean-k-mooney | oh right | |
| 18:06:43 | sean-k-mooney | but createBackup uploads it as a snapshot to glance | |
| 18:07:06 | efried | point is, the image you get from createImage can be (non-awkwardly) used to clone your VM. Whereas createBackup is more tailored to rebuild. | |
| 18:07:07 | sean-k-mooney | does createimage upload as a snapshot i though it flattened the image | |
| 18:07:23 | sean-k-mooney | ok | |
| 18:07:56 | efried | rebuild is your same instance. Otherwise you're creating a new instance. If you're creating a new instance, it will get a new (or no) vTPM. | |
| 18:08:41 | efried | so the only quirk is that in order for rebuild to restore your vTPM, you have to use an image from createBackup. | |
| 18:08:43 | efried | which makes sense | |
| 18:08:59 | efried | if you use a random image from createImage, why would you expect your vTPM from your original instance to be restored? | |
| 18:09:23 | efried | conversely, if you're creating a brand new instance (from *any* image), why would you expect anything other than a fresh vTPM? | |
| 18:09:56 | sean-k-mooney | ya so i said previously that the vtpm should be tied to the lifetime of the instace so i think that makes sense | |
| 18:10:19 | efried | we've got an answer for all the move operations and shelve/unshelve. | |
| 18:10:35 | sean-k-mooney | we are explcitly saying the usecase of i create a vm snapshot and spawn 100 more is expresly out of scope (in that they wont all get the orginal vms vtpm) | |
| 18:11:08 | efried | I wouldn't phrase it as "out of scope". It's got clean, predictable behavior: you don't get the original VM's vTPM. | |
| 18:11:29 | sean-k-mooney | yes that is what i intened | |
| 18:11:37 | efried | which, for anyone using a vTPM, ought to make sense. "don't give my secure stuff to another instance" | |
| 18:11:48 | sean-k-mooney | copying the vtpm in that case is not supported intentionally | |
| 18:12:19 | efried | yeah, I'm just getting nitpicky about the language. "out of scope" and "not supported" imply "don't work". | |
| 18:12:28 | sean-k-mooney | so i would be ok with that set of constratits but im not really the person you have to convice | |
| 18:12:55 | eandersson | dansmith so we jumped from mitaka to rocky | |
| 18:13:09 | eandersson | So it's difficult to say exactly what part improved performance the most | |
| 18:13:17 | eandersson | but we believe placement played a big role here | |
| 18:13:35 | dansmith | eandersson: well, is it scheduling performance, instance listing performance, build time, etc? | |
| 18:13:40 | eandersson | scheduled is a lot better at least ~50% | |
| 18:13:49 | dansmith | sweet, so that's likely placement yeah | |
| 18:13:54 | eandersson | Also scaling computes | |
| 18:14:05 | dansmith | eandersson: what does "scaling computes" mean? | |
| 18:14:06 | eandersson | We initially limited ourself to 1000 computes per region | |
| 18:14:12 | eandersson | in Mitaka | |
| 18:14:23 | eandersson | but now believe we can reach a much higher number than that | |
| 18:14:55 | dansmith | eandersson: is that via cells or just in general? because I don't think we've done anything other than get *more* chatty to the db/mq since mitaka :) | |
| 18:14:57 | eandersson | And even if we do hit limitations we can now use cells | |
| 18:15:23 | eandersson | scheduler used to be really heavy on rmq | |
| 18:15:29 | eandersson | in mitaka | |
| 18:15:53 | sean-k-mooney | eandersson: do you run sepperate rmq instacne per openstack service | |
| 18:16:01 | eandersson | We do not | |
| 18:16:24 | eandersson | but even at 1k computes we are barely putting any stress on rmq at the moment | |
| 18:16:32 | eandersson | Of course we are not using ceilometer | |
| 18:16:34 | sean-k-mooney | im surpirsed you are getting to 1000 nodes on one cluster with neutron and nova sharing it | |
| 18:16:48 | dansmith | eandersson: so you're thinking that lowered load on rabbit from the scheduler lets you have more computes? | |
| 18:16:52 | sean-k-mooney | ya not using ceilometer helps | |
| 18:17:02 | eandersson | dansmith I think it helps | |
| 18:17:09 | dansmith | ack | |
| 18:18:12 | eandersson | We were getting a lot of slow api calls in mitaka and they are all very consistent now | |
| 18:19:06 | eandersson | The only problems we have with nova now is getting our super custom scheduling logic to scale | |
| 18:19:07 | dansmith | that's what I'm interested in specifically, | |
| 18:19:17 | dansmith | but without knowing which calls those were I can't really attribute them to anything | |
| 18:19:31 | dansmith | (that == slow api calls) | |
| 18:20:55 | eandersson | Yea - unfortunately a lot of the research and testing we did was back in ~2016 | |
| 18:21:48 | eandersson | We didn't do a great job tracking individual improvements when going from Mitaka to Rocky | |
| 18:21:53 | sean-k-mooney | eandersson: do you have a list of constraits you need to schduler on that are not supported cleanly upstream that could be shared perhaps we could accomadate some of your custom logic | |
| 18:22:44 | eandersson | We do flavor stacking and what... we internally call "perfect fit". | |
| 18:22:59 | sean-k-mooney | using the type affingity filter | |
| 18:23:07 | mriedem | you also have a variant of the old flavor affinity filter yeah? | |
| 18:23:08 | sean-k-mooney | so that each host only one flavor | |
| 18:23:30 | eandersson | So we actually want to stack flavors on a compute | |
| 18:23:34 | eandersson | because these are game servers | |
| 18:23:40 | eandersson | So each game server takes up one numa | |
| 18:24:07 | eandersson | but we still want to be able to schedule other micro services on top | |
| 18:24:50 | eandersson | Since we don't want to have to divide the fleet | |
| 18:24:55 | sean-k-mooney | so you want to pack the large flavor and then fit the micof servces wehre tehy can | |
| 18:24:59 | eandersson | Yep | |
| 18:25:17 | sean-k-mooney | that not really unresobaly to be fair | |
| 18:25:41 | sean-k-mooney | the main issue i guess you face right now is fragmenation | |
| 18:26:02 | eandersson | Yea - if we go with the out of the box implementation | |
| 18:26:04 | sean-k-mooney | e.g. a small instnace spawns preventing a large instnace | |
| 18:26:09 | eandersson | yep | |
| 18:26:13 | dansmith | but also...scheduler filters are the one place I think we *should* be pluggable, and so unless other people want *exactly* the same weird scheduling thing, it makes sense for them to do this on their own, IMHO | |
| 18:26:37 | eandersson | Yep - I hate that I have to patch nova for this | |
| 18:26:55 | eandersson | I mean we have a super custom way of deploying, plus probably 20 custom nova patches at least | |
| 18:27:02 | sean-k-mooney | this is not the first time i have heard this requrest however | |
| 18:27:17 | eandersson | So it's not a big deal, but would be a lot easier for us to manage it if it was pluggable | |
| 18:27:27 | dansmith | scheduler filters *are* pluggable | |