| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-26 | |||
| 19:27:00 | opendevreview | melanie witt proposed openstack/nova stable/ussuri: Reject open redirection in the console proxy https://review.opendev.org/c/openstack/nova/+/791806 | |
| 19:45:19 | opendevreview | Merged openstack/nova master: libvirt: Always delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/797428 | |
| #openstack-nova - 2021-07-27 | |||
| 02:00:27 | opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: Use Block Storage API v3 instead of API v2 https://review.opendev.org/c/openstack/python-novaclient/+/802417 | |
| 08:40:23 | MrClayPole | Time appropriate greetings, we have a company policy for all network and compute devices have their timezone set to UTC time. The issue we have is that during the summer in the UK we have our clocks set to UTC+1. Our Windows servers are currently booting with clock 1 hour in the past. Is there a way for libvirt/nova to track our timezone while keeping Ubuntu 18.04 set to UTC time? | |
| 08:43:25 | lyarwood | MrClayPole: are you using os_type=windows for the images? | |
| 08:43:39 | lyarwood | https://bugs.launchpad.net/nova/+bug/1231254 a slightly old bug but I wonder if it still applies | |
| 08:45:02 | lyarwood | https://libvirt.org/formatdomain.html#time-keeping would be how libvirt controls this FWIW | |
| 08:46:00 | lyarwood | https://github.com/openstack/nova/blob/1c490ecd7be5722c6cfdaddfacc8d7a5539dd035/nova/virt/libvirt/driver.py#L5792-L5806 is where we switch to localtime when os_type=windows | |
| 08:46:05 | lyarwood | instead of utc | |
| 08:47:59 | lyarwood | ah right but your hosts remain on UTC so that isn't useful | |
| 08:56:05 | MrClayPole | lyarwood: We are running OpenStack rocky, as you said the os_type didn't help but it's interesting that libvirt xml supports a timezone. Can this be set from Nova? | |
| 08:57:56 | lyarwood | MrClayPole: not at the moment AFAICT, we have all of the config code just no way for a user to request it | |
| 08:59:05 | MrClayPole | I wondering if the best way forward might just be to have an exception for our compute nodes so they can bet set to "Europe/London" rather than UTC | |
| 08:59:37 | lyarwood | Yeah for your env on Rocky that would be for the best | |
| 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 | |