Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-23
15:18:56 lyarwood kashyap: ^ that was my point sorry
15:19:25 lyarwood and the workaround appears to be to pin to the oldest version
15:19:33 kashyap Yep
15:19:40 lyarwood but I just don't get how this works downstream across multple releases
15:19:49 lyarwood we'd basically need to pin to the first version used in the env
15:20:55 openstackgerrit Takashi Natsume proposed openstack/nova master: Fix list rendering in the accelerator support doc https://review.opendev.org/721846
15:21:58 lyarwood surely we should work out and persist the versioned machine type during a migration?
15:22:24 lyarwood so if the source is 8.1 and using the q35 alias ensure it uses that on the dest
15:22:36 lyarwood but all new instances use the 8.2 q35 type?
15:22:56 kashyap lyarwood: For downstream, yes: you need to pick a versioned machine type and set it across the nodes before deplyoying.
15:22:59 aarents lyarwood: kashyap we hit this kind of issues.. but Im not the guy who work on it I will check how we dealt with that..
15:23:01 lyarwood kashyap: sorry I'm talking out loud here, could you add the LM section back into the spec and I'll add words there.
15:23:26 kashyap lyarwood: Sure, let me add that bit in the spec in a separate section; it's important
15:23:30 lyarwood kashyap: yeah the issue with that is you can never move from it
15:24:16 kashyap lyarwood: Hang on - you _can_ move; it's a step-by-step process:
15:25:35 kashyap lyarwood: Err, my "Here's the problem" has a bug!
15:25:41 kashyap It should read the _other_ way round.
15:25:43 kashyap Let me update it
15:25:59 lyarwood kashyap: kk, lets get the spec updated and chat there :)
15:26:02 kashyap You cannot migrte from 7.7 to 7.6
15:26:14 kashyap But you can jolly well migrate from 7.6 to 7.7 :)
15:26:15 kashyap Yes
15:26:17 kashyap A sec
15:30:33 kashyap aarents: Noted :)
15:30:33 artom I feel like this whole mess could be solved if we tracked machine type on a per-instance basis
15:31:00 artom Though the problem that raises is live-migration from an N+1 to an N compute
15:31:14 artom The dest N might now know the machine type, as it's newer
15:31:37 kashyap Per-instance tracking is just too damn fragile and messy
15:31:47 kashyap I'd say per-Compute based is better for debugging, too.
15:31:51 artom Maybe, but how/why?
15:31:55 kashyap We should not forget the Operator's predicmanet
15:32:02 kashyap s/predicmanet/predicament/
15:32:10 artom This whole discussion shows that per-compute isn't super clean either :)
15:32:22 kashyap artom: The live migration from N+1 to N always remains a problem.
15:32:54 artom True
15:33:06 artom Could we not incorporate machine type into our LM checks?
15:33:10 kashyap Can you tell more what do we gain more per-instance tracking solve? Just asking sincerely... :)
15:42:44 sean-k-mooney kashyap: if we dont track the machine type and you upgreade the host the vm might not work after a hardreboot
15:43:14 sean-k-mooney e.g. if it had a conflciting image peroperty like hw_vif_model=e1000 or hw_disk_bus=ide
15:44:09 sean-k-mooney so if its not set in the image and is just being chosen by our default or the host config then we need to recored it to not break existing instnace on upgrade
15:44:35 sean-k-mooney hopefuly that makes sense
15:50:55 gibi nova meeting starts in 10 minutes on #openstack-nova
15:51:12 gibi nova meeting starts in 10 minutes on #openstack-meeting-3
15:51:18 gibi /o\
15:52:30 lyarwood elod / melwitt: https://review.opendev.org/#/c/720587/ - I think this is ready right? We aren't waiting on actual failures to show up first in stable/stein?
15:53:11 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Make RBD imagebackend flatten method idempotent https://review.opendev.org/708615
15:53:20 kashyap sean-k-mooney: Will respond in a few
15:53:57 sean-k-mooney kashyap: no rush
15:53:59 kashyap sean-k-mooney: lyarwood: So, I just double-confirmed with upstream QEMU: as I guessed, depsite KM-long threads, there's no agreement whether to not add new 'pc' variants or not -- it is strictly a RHEL-only decsion
15:54:31 kashyap So, I'll add "suitable words"
15:54:31 kashyap And also other long-term distributions (SUSE, et al)
15:54:33 kashyap (In the end this spec might even not be needed ... but at least it allows to flesh out ideas)
15:55:18 sean-k-mooney kashyap: yep. ill try to review it more properly on monday but at least it s place to collect and discuss the alternitives
15:56:46 kashyap sean-k-mooney: Sure, yeah. It at least keeps the ideas in one place
15:58:00 openstackgerrit Ghanshyam Mann proposed openstack/python-novaclient master: [Community goal] Update contributor documentation https://review.opendev.org/722391
15:58:07 openstackgerrit Ghanshyam Mann proposed openstack/os-vif master: [Community goal] Update contributor documentation https://review.opendev.org/722392
15:58:14 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: [Community goal] Update contributor documentation https://review.opendev.org/722393
16:02:31 elod lyarwood: according to logstash the failure disappeared, so maybe we could merge that now
16:04:53 melwitt lyarwood: it is ready yes. tbh I'm surprised it's 100% gone from logstash bc I expected to see it on older branches (train and earlier). I wonder if logstash does only master branch only? I'm not sure
16:05:23 lyarwood I thought it did all of the supported releases tbh
16:05:31 lyarwood train and stein still are
16:05:38 melwitt that's what I had thought too
16:05:46 lyarwood but anyway lets merge that
16:05:48 melwitt but I guess they get much less traffic
16:06:12 lyarwood yup very true
16:41:07 lyarwood melwitt / elod ; following up on the stable discussion in the meeting can you hit https://review.opendev.org/#/c/708578/
16:41:19 lyarwood melwitt: can you also hit https://review.opendev.org/#/c/708615/
16:41:36 lyarwood and I think we should be ready to cut a release once these have merged
16:41:47 melwitt sure
16:41:50 lyarwood many thanks
16:42:52 bauzas lyarwood: I'll look at those stable/stein changes
16:44:36 lyarwood thanks
16:46:05 gibi bauzas: I will check back in couple of hours to update the RC1 release patch
16:46:20 bauzas gibi: want me to do it this evening ?
16:46:40 gibi bauzas: I will cover this. you covered the novaclient
16:46:46 bauzas cool
16:46:48 gibi loadsharing :)
16:48:03 bauzas well, I'm a bit depressed by something with my house, so I would just turn into work to forget it :p
16:51:33 openstackgerrit Merged openstack/nova-specs master: move implemented spec for train https://review.opendev.org/706276
16:56:46 openstackgerrit Ghanshyam Mann proposed openstack/python-novaclient master: [Community goal] Update contributor documentation https://review.opendev.org/722391
17:16:11 openstackgerrit Ghanshyam Mann proposed openstack/os-vif master: Fix doc build job for wanring turn into error https://review.opendev.org/722407
17:16:41 openstackgerrit Ghanshyam Mann proposed openstack/os-vif master: [Community goal] Update contributor documentation https://review.opendev.org/722392
17:22:53 openstackgerrit Merged openstack/nova master: FUP: Amend ussuri prelude to add docs for policy concepts https://review.opendev.org/722220
17:30:05 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Make Q35 machine type the default for x86 https://review.opendev.org/631154
18:06:57 openstackgerrit Merged openstack/nova stable/train: Add retry to cinder API calls related to volume detach https://review.opendev.org/722142
18:12:26 openstackgerrit Elod Illes proposed openstack/nova stable/stein: Reject boot request for unsupported images https://review.opendev.org/708578
18:41:03 artom I've set one bug to fix released, because that's what it was, and another as wontfix, because while super impressive, it's just not a concern in practice.
18:41:17 artom I've also looked at a dozen others, all of which have ended with "I have no idea"
18:55:26 artom What's vmware's driver status?
18:56:43 artom IIRC dansmith was talking about deprecating it? Do we have anyone working on it?
18:57:01 dansmith we marked it as deprecated this cycle
18:57:06 dansmith it'll be a few before we can remove it
18:57:21 artom OK, so for a bugin that driver, it'd be fair to say wontfix?
18:57:35 artom In order to set realistic exptectations?
18:57:55 dansmith that's really for the owners of the driver to say I guess
18:58:14 dansmith I would maybe mark it as triaged or whatever, if it looks valid and tag it so it's clearly vmware-related
18:58:35 dansmith and maybe comment that it's unlikely to get fixed, but marking it as wontfix is probably too aggressive
18:58:46 artom It's already tagged, I have no idea if it's valid, I'll leave it alone then
18:59:45 openstack Launchpad bug 1800204 in OpenStack Compute (nova) "n-cpu.service consuming 100% of CPU indeterminately" [Undecided,Won't fix]
18:59:45 artom And now you're making me doubt closing https://bugs.launchpad.net/nova/+bug/1800204 as wontfix

Earlier   Later