| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-27 | |||
| 09:00:08 | lyarwood | For the Yoga OpenStack release we could easily add an image property to control the timezone directly | |
| 09:02:27 | MrClayPole | That would defo be useful to us so we can revert the compute nodes back to UTC. | |
| 09:15:47 | stephenfin | bauzas: gate fix for novaclient here if you have 2 | |
| 09:15:48 | stephenfin | https://review.opendev.org/c/openstack/python-novaclient/+/802417 | |
| 09:16:02 | bauzas | stephenfin: we have a gate issue ? | |
| 09:16:12 | stephenfin | Yes, a very slight one due to cinderclient's removal of cinder API v2 | |
| 09:16:46 | bauzas | stephenfin: any bug y'know ? | |
| 09:16:46 | stephenfin | Spotted after reading through Takashi Kajinami's email to openstack-discuss ("[all] Broken gate caused by Block Storage API v2 removal") | |
| 09:16:54 | bauzas | ahah | |
| 09:17:23 | stephenfin | lots of related patches available also https://review.opendev.org/q/topic:%22volumev2-removal%22+(status:open%20OR%20status:merged) | |
| 09:18:09 | bauzas | I just read the email, I don't see failing jobs | |
| 09:18:49 | bauzas | hah | |
| 09:19:15 | lyarwood | stephenfin: ACK'd the novaclient change | |
| 09:19:24 | stephenfin | ty! | |
| 09:20:59 | bauzas | are we sure that the v3 client supports the same than for the v2 ? | |
| 09:21:09 | bauzas | lyarwood: ^ | |
| 09:21:20 | lyarwood | bauzas: yeah it does | |
| 09:22:03 | bauzas | ok, I was a bit afraid of just using the new version without making sure it wasn't creating problems for us | |
| 09:22:19 | bauzas | but if it doesn't change our client API, fair enough | |
| 09:22:26 | lyarwood | https://docs.openstack.org/api-ref/block-storage/api_microversion_history.html#maximum-in-mitaka | |
| 09:22:42 | lyarwood | The 3.0 Cinder API includes all v2 core APIs existing prior to the introduction of microversions. The /v3 URL is used to call 3.0 APIs. This is the initial version of the Cinder API which supports microversions. | |
| 09:26:41 | sean-k-mooney | it looks like in most cases the convertion to v3 is trivial as a result | |
| 09:26:57 | bauzas | lyarwood: thanks | |
| 09:29:04 | sean-k-mooney | MrClayPole: im not sure th at nova should really provide a facility to set a timezone | |
| 09:29:35 | sean-k-mooney | at least not at the host level provbly not ant the image or flaovr level. although im more open to the image idea | |
| 09:30:20 | sean-k-mooney | if we were to suprot settign a time zone i think i would want it to be per instance hosetly but really i think that woule be better handeles withine the workload | |
| 09:30:38 | sean-k-mooney | just always set your host to utc | |
| 09:31:09 | sean-k-mooney | and in windows set the timezone appropreiately if needed | |
| 09:32:06 | CeeMac | sean-k-mooney: thats exactly the issues we have at the moment though. The host is set to utc and windows seems locked to that, so during DST the guest still runs -1 hour instead of updating. | |
| 09:32:54 | CeeMac | i must confess I'm a little perplexed as I was expecting the os_type=windows to resolve the issue, but this doesn't appear to be the case | |
| 09:35:21 | sean-k-mooney | CeeMac: you should be able to set the time in windows the clock source will by utc | |
| 09:35:35 | sean-k-mooney | but in windows itself you can change the local | |
| 09:36:09 | CeeMac | sean-k-mooney: yes, "should" appears to be the main issues here as that was my expectation, but the results don't appear to support this :( | |
| 09:36:16 | sean-k-mooney | are you saying if you go into the region settign in windows it does not work? | |
| 09:36:43 | sean-k-mooney | CeeMac: that sound like a windows bug you should report to microsoft | |
| 09:36:54 | CeeMac | our guest VMs are all set to BST (UTC+1) and the system clock is reporting UTC+0 times, so they're all an hour in the past | |
| 09:37:07 | sean-k-mooney | in a cloud enviornemt you cannot know the timezone of the tenant | |
| 09:37:17 | sean-k-mooney | so you shoudl always be abel to set it indepenently of the host | |
| 09:37:52 | CeeMac | it appears to be a known issue around how windows handles time from the bios clock, which i believe is the entire premise on why the os_type=windows patch was ported from hyper-v hypervisor to kvm hypervisor in nova | |
| 09:37:59 | sean-k-mooney | CeeMac: for what its worth i hate daylight saving time so im glad ill by on utc permently next year | |
| 09:38:06 | CeeMac | sean-k-mooney: yeah, thats the dream! | |
| 09:38:28 | CeeMac | yeah, can't say I'm a big fan either. its those pesky customers who are complaining :) | |
| 09:38:35 | sean-k-mooney | well os_type=windows does other things too | |
| 09:38:40 | sean-k-mooney | but that patch yes | |
| 09:39:31 | sean-k-mooney | although when we use os_type=windows it shoudl enabel the hyperv clock | |
| 09:39:42 | CeeMac | from what I gather, there is a reg hack that resolves the problem, but microsoft wont support it and say it is "buggy", whatever that means | |
| 09:39:50 | sean-k-mooney | which clock is this changing | |
| 09:39:58 | sean-k-mooney | we have multipel clock source i think in the vm | |
| 09:40:28 | sean-k-mooney | CeeMac: why not set the windows vms to utc | |
| 09:40:43 | sean-k-mooney | you can disable DST in them | |
| 09:40:43 | CeeMac | get added to the clock offset stanza for instances with os_type=windows | |
| 09:40:43 | CeeMac | i've seen the <timer name='hypervclock' present='yes'/> | |
| 09:41:11 | sean-k-mooney | CeeMac: ill pretend your not altering the xml :) | |
| 09:41:27 | CeeMac | sean-k-mooney: its ok, i'm not, i'm just looking at it with dumpxml | |
| 09:41:31 | CeeMac | :) | |
| 09:42:07 | sean-k-mooney | so we have offset and timezone https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L703-L705 | |
| 09:42:35 | CeeMac | so, the issue we're looking at currently, is a hosted platform for a customer clocking / time management systems. Presumably they want/need the clock in / clock out times to register against the correct regional time for accurate reporting | |
| 09:44:28 | sean-k-mooney | and then we add the hyperv clock source https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5840-L5844 in addation to the pit, rtc and optionally the hpet | |
| 09:45:13 | sean-k-mooney | CeeMac: right but the normal way to do that is to use UTC and then do the conversion client side | |
| 09:45:40 | sean-k-mooney | you should never store data in local time | |
| 09:46:05 | CeeMac | tbh, until we came across this issues it was always my belief that the windows kernel ran in utc natively and just adusted 'user' time based on the regional settings | |
| 09:46:11 | sean-k-mooney | you enither use unix time or some other utc reference time like isotime format | |
| 09:46:23 | CeeMac | but windows | |
| 09:46:29 | CeeMac | appears to be the issues | |
| 09:46:30 | sean-k-mooney | CeeMac: i belive it does with a different epoc | |
| 09:46:46 | CeeMac | as its chose to use the 'localtime' standard, if you can call it a standard | |
| 09:46:50 | CeeMac | stupid windows | |
| 09:46:51 | sean-k-mooney | CeeMac: i think windows expect the hardware time to be in utc | |
| 09:47:22 | CeeMac | i think more stick poking is required | |
| 09:48:23 | CeeMac | thanks sean-k-mooney we'll have a ponder and see if we can see whats happening, or not happening as the case may be | |
| 09:49:38 | sean-k-mooney | https://libvirt.org/formatdomain.html#time-keeping | |
| 09:51:06 | CeeMac | thanks, thats an interesting read. | |
| 09:52:12 | sean-k-mooney | so reading that localtime should give you what you wanted i think | |
| 09:52:36 | CeeMac | yeah, that was our theory. Perhaps we're missing something in the os | |
| 09:52:52 | sean-k-mooney | we can use timezone since we can only update that on reboot so you woudl have to reboot your vms evey 6 months | |
| 09:53:11 | CeeMac | i presume there is no easy way to insert the additional track and catchup information? | |
| 09:53:15 | sean-k-mooney | we could maybe use variable | |
| 09:53:36 | sean-k-mooney | its not currently exposed in nova no | |
| 09:54:05 | sean-k-mooney | this is getting more speicic then im comfortable exposing in a cloud env by the way | |
| 09:54:10 | CeeMac | all the data suggests that it should work, as you say | |
| 09:54:15 | sean-k-mooney | we might expsoe it but im not sure we should in general | |
| 09:54:48 | CeeMac | no thats fine, i get that. It must be working for other people, otherwise I'm sure there would be more chat out there for it not working | |
| 09:54:58 | sean-k-mooney | <clock offset='varible' basis='localtime'> | |
| 09:55:04 | sean-k-mooney | we cold maybe try that | |
| 09:55:09 | sean-k-mooney | *could | |
| 09:57:12 | sean-k-mooney | CeeMac: if we were to expose the timer settign i think it woudl ahve to be at teh image level rghat then host by the way | |
| 09:57:42 | CeeMac | sean-k-mooney: yes, that would make sense | |
| 09:57:55 | sean-k-mooney | CeeMac: host level config that modify the xml are basicaly terribel form a live migration standpoint as we havne to schdule on it or pass the data or both | |
| 09:58:36 | sean-k-mooney | so this type of info really needt to live with the instnace for its lifetime hence flavor or image | |
| 09:59:08 | sean-k-mooney | with that said i woudl be tempeted to start using server metadata for this personally | |
| 09:59:29 | sean-k-mooney | since this is a very pet like tuning | |
| 09:59:40 | CeeMac | it makes sense that it should follow the instance | |
| 09:59:48 | CeeMac | windows is all about the pet sadly | |
| 10:01:26 | CeeMac | server metadata would be useful i think | |
| 10:02:55 | sean-k-mooney | we dont currently allow it to modify xml exctra but i have always wondered if we should allow it to set anything that is setabel via image metadata | |
| 10:03:46 | sean-k-mooney | that would require a spec and some semi invasive changes to parts of the libvirt driver | |
| 10:03:49 | CeeMac | in some scenarios it could be beneficial, especially if its discovered you need to retrofit a value that would normally only be doable through an image | |
| 10:03:54 | sean-k-mooney | so not sure its worth it | |
| 10:03:59 | CeeMac | its still a very pet mentality granted | |
| 10:04:20 | CeeMac | hmm, cost/benefit are skewed i guess | |