| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-17 | |||
| 15:38:12 | dansmith | sean-k-mooney: so does that mean every time we destroy an instance using one of these that we have to block destroy until we've written gigabytes to this device? | |
| 15:38:20 | sean-k-mooney | alex_xu: i assume we can delgate the erase to a cli too and just do it async or in parallel | |
| 15:38:33 | dansmith | whereas if we were giving them flash we could just run a single trim command and move on? | |
| 15:38:35 | alex_xu | we are using the daxio | |
| 15:38:49 | sean-k-mooney | dansmith: i mean technically yes | |
| 15:39:11 | sean-k-mooney | that would be similar to the lvm image backend erase | |
| 15:39:27 | dansmith | sean-k-mooney: right, which is ridiculous and based on 1980s notions of disk, so I give it a pass | |
| 15:39:58 | dansmith | and also not really enjoyed by operators everywhere :) | |
| 15:40:10 | sean-k-mooney | alex_xu: to dansmith's point if we are using daxio can we just tell the device to nuke everythin in the namespace | |
| 15:40:33 | alex_xu | no, I don't think we have that kind of TRIM | |
| 15:40:43 | efried | this seems like a separate issue though. Whatever "clear" we have to do, we have to do the same thing on destroy() | |
| 15:40:55 | sean-k-mooney | ya | |
| 15:40:59 | sean-k-mooney | that is fair | |
| 15:41:07 | dansmith | efried: sure, it's more just that if we're going to massively slow down destroy, it'd be good to know that | |
| 15:41:15 | dansmith | so we can mock this "feature" if nothing else | |
| 15:41:22 | sean-k-mooney | the question that raises is can we have the agent wait to start up or not | |
| 15:41:23 | efried | IIRC that was in the spec | |
| 15:41:23 | dansmith | jay would be rolling over in his grave | |
| 15:41:38 | sean-k-mooney | could we play with the reserved value in placment | |
| 15:41:40 | dansmith | sean-k-mooney: we can and should, like anything else we do on this | |
| 15:41:50 | dansmith | I'm less concerned about the delayed compute startup than I am with destroy | |
| 15:42:11 | sean-k-mooney | e.g. make the dirty namespces reserved until we clean it | |
| 15:42:26 | dansmith | if you're billing by the hour, and a bunch of people destroy instances all at once and they all have to wait in line to have zeroes written to this new whizbang memory thing... | |
| 15:42:53 | efried | sean-k-mooney: if we change inventory on destroy() we're going to run into cdent's generation conflict race all over the place. | |
| 15:42:54 | sean-k-mooney | for what its worth it can do that at several GB/S | |
| 15:42:54 | dansmith | sean-k-mooney: that's a lot more complex and more opportunity to be interrupted in the middle and needing to be properly resumed | |
| 15:43:23 | sean-k-mooney | ok then lets just keep it simple | |
| 15:43:43 | cdent | (my patch to not do that, controlled by config, got merged internally) | |
| 15:43:44 | sean-k-mooney | and block untill they are all cleaned if their was a faild migration as ye suggested | |
| 15:44:03 | dansmith | sean-k-mooney: ++ | |
| 15:45:05 | sean-k-mooney | apparently the frist gen stuff will hit 8.9 GB/s in sequtial writes | |
| 15:45:29 | sean-k-mooney | although the cleaning operation would likely impact the performce of other isntances if you tried to max it out | |
| 15:45:54 | dansmith | which is why it's stupid to have to do this | |
| 15:46:01 | dansmith | I mean honestly, wtf | |
| 15:46:15 | dansmith | cheap sata SSDs have not required writing zeros to erase for ten years | |
| 15:46:58 | sean-k-mooney | its because its been mapped as memory rather then via a filesystem | |
| 15:47:12 | dansmith | which is also stupid | |
| 15:47:14 | dansmith | however, | |
| 15:47:30 | sean-k-mooney | if you did use it via the filesystem interface which is ssupported it proably would handel this interally | |
| 15:47:31 | dansmith | you have a cli tool to manage it, so there should be some thing to do it.. doesn't have to be _actual_ ATA TRIM | |
| 15:48:05 | dansmith | ...but intel *has* to have this seem memory like for optics, so.. :/ | |
| 15:48:26 | sean-k-mooney | well it littaly replaces ram dims | |
| 15:48:39 | dansmith | so? | |
| 15:48:40 | sean-k-mooney | and is byte adressable | |
| 15:48:49 | sean-k-mooney | so its pretty ram like | |
| 15:48:54 | dansmith | it's a block device to the guest yeah? | |
| 15:48:58 | sean-k-mooney | no | |
| 15:49:05 | alex_xu | it is ram for the guest | |
| 15:49:08 | sean-k-mooney | its exposed as dims to the guest | |
| 15:49:26 | dansmith | but people are going to use it as semi-persistent storage right? | |
| 15:49:33 | sean-k-mooney | no | |
| 15:49:37 | sean-k-mooney | well indirectly | |
| 15:49:51 | sean-k-mooney | they will be mmaping it into there application adress space | |
| 15:49:56 | dansmith | right | |
| 15:50:16 | sean-k-mooney | and using it as an "in memeory" cache / scratch space for there workign set | |
| 15:50:19 | dansmith | which works fine for block-addressable storage, to look like byte-addressable memory, even for rotating rust :) | |
| 15:51:28 | dansmith | anyway, whatever, I know this ship has sailed | |
| 15:51:43 | sean-k-mooney | sure :) you know we live in a world of hardward defiend software right :P | |
| 15:51:51 | dansmith | all too well | |
| 15:55:34 | alex_xu | dansmith: efried sean-k-mooney anyway...thank you guys | |
| 15:55:47 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 15:56:18 | zzzeek | is mriedem on vacation | |
| 15:56:38 | dansmith | zzzeek: yes | |
| 15:56:47 | zzzeek | dansmith: hokay | |
| 16:01:50 | edleafe | b | |
| 16:02:05 | edleafe | *ETOOMANYTERMINALSOPEN | |
| 16:19:32 | efried | IMO it's pretty much ready to go - but I may be too close to it to see the gaps. | |
| 16:19:32 | efried | gibi: dansmith: cdent: I gotta roll, but would you please have a look at the providers.yaml spec soonish? https://review.opendev.org/#/c/612497/ | |
| 16:19:55 | cdent | aye aye, will poke at it tomorrow mornig | |
| 17:02:30 | stephenfin | sean-k-mooney: What do we do if none of 'vcpu_pin_set', '[compute] cpu_shared_set' or '[compute] cpu_dedicated_set' are configured? | |
| 17:03:10 | stephenfin | I'm thinking we need to return both VCPUs and PCPUs for all host cores, like we would do if 'vcpu_pin_set' is configured | |
| 17:03:35 | stephenfin | But if we do that, we'll introduce a possibly breaking change when we stop doing that in U | |
| 17:04:40 | sean-k-mooney | if none are set then ya | |
| 17:04:50 | sean-k-mooney | i would report all host cpus as both | |
| 17:05:46 | sean-k-mooney | ideally we would require that one of cpu_shared_set or cpu_dedicated_set are set going forward | |
| 17:05:59 | sean-k-mooney | and issue a warning if neither are set | |
| 17:07:21 | stephenfin | Cool. Going to push drafts of this in a few minutes. It will fail every gate test there is but it should be good enough to see where I'm going with it | |
| 17:07:34 | sean-k-mooney | e.g in train we report both and issue warning. in U if you dont set one of the cpu_shared_set or cpu_dedicated_set we raise an error and refuse to start | |
| 17:11:36 | openstackgerrit | Merged openstack/nova master: Restore RT.old_resources if ComputeNode.save() fails https://review.opendev.org/668263 | |
| 17:28:36 | openstackgerrit | sean mooney proposed openstack/nova master: Libvirt: add support for vPMU configuration. https://review.opendev.org/671338 | |
| 17:29:14 | sean-k-mooney | i think ^ is the full implemtation of the vPMU spec | |
| 17:29:38 | sean-k-mooney | its pretty short so should be a quick win if people want to review. | |
| 17:29:52 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 17:30:52 | sean-k-mooney | its 75% unit tests,docs and release notes and like 40 lines of code that does something userful | |
| 17:32:26 | sean-k-mooney | ... actully its proably goign to fail the notification api tests... | |
| 17:33:05 | sean-k-mooney | i was actully trying to have it ready to mrege in the first patch but oh well | |
| 19:07:03 | artom | dansmith, around? Let's say with save a Nova object in one nova component, for example calling in nova-compute instance.save() after setting instance.migration_context | |
| 19:07:26 | artom | And then later, a different instance object, without migration_context lazy-loaded, also gets save()'ed, in the conductor | |
| 19:07:35 | artom | Will the second save clobber the first's migration_context? | |
| 19:08:18 | dansmith | meaning will the not-context-having instance.save() cause the migration context to go away? | |
| 19:08:52 | artom | Yeah | |
| 19:09:17 | dansmith | it shouldn't.. that would be a bug.. this is why objects track dirty fields.. so we know what to update in the database and what to leave as-is | |
| 19:10:02 | artom | (I tried to understand save()'s code, it's not super scrutable) | |
| 19:10:15 | artom | dansmith, ack, much thanks | |
| 19:11:13 | dansmith | instance is complicated, thus is has a complicated save handler | |
| 19:11:37 | dansmith | the actual save is not innate behavior for objects, it has to be implemented each time, so always an opportunity for a bug | |
| 19:12:15 | artom | There's no default "save each field into its column" implementation? | |
| 19:12:36 | artom | "each field" being overly simplistic | |
| 19:12:37 | dansmith | no | |
| 19:13:07 | dansmith | the number of objects that are just a simple "this field goes unchanged in this column" was never 100%, and has shrunk ever since | |