Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-23
10:53:27 kashyap mdbooth: This is what it does currently:
10:53:28 kashyap 489 super(LibvirtConfigGuestCPUFeature, self).__init__(name, **kwargs)
10:53:28 kashyap 488 def __init__(self, name=None, **kwargs):
10:53:28 kashyap 487
10:53:28 kashyap 486 class LibvirtConfigGuestCPUFeature(LibvirtConfigCPUFeature):
10:53:31 kashyap 490
10:53:33 kashyap 491 self.policy = "require"
10:53:36 kashyap 492
10:53:38 kashyap 493 def format_dom(self):
10:53:41 kashyap 494 ft = super(LibvirtConfigGuestCPUFeature, self).format_dom()
10:53:44 kashyap 495
10:53:46 kashyap 496 ft.set("policy", self.policy)
10:53:49 kashyap 497
10:53:51 kashyap 498 return ft
10:54:24 kashyap Okay, it inherits from the LibvirtConfigCPUFeature()...
11:01:23 openstackgerrit Zhenyu Zheng proposed openstack/nova-specs master: Add request_id field to migrations object https://review.openstack.org/536765
11:02:14 Spazmotic I need to maek my first nova-spec.. need to read up on how to do that.
11:06:39 Spazmotic sounds like a job for tomorrowwwwwman
11:09:42 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM: Test LM with encrypted volumes https://review.openstack.org/536350
11:12:14 cdent gibi, bauzas: this would be a useful debugging improvement to have for the post-freeze cleanup: https://review.openstack.org/#/c/519462/ Kenichi has a concern about a private member, but I think that's just the way it goes for now. Already has +2 from stephenfin
11:14:09 openstackgerrit Zhenyu Zheng proposed openstack/nova-specs master: Allow abort live migrations in queued status https://review.openstack.org/536722
11:17:06 kashyap stephenfin or anyone: Do we have a precendence in Nova where we allow comma-separated values for a config attribute?
11:17:26 stephenfin kashyap: Look at oslo_config.types
11:17:33 stephenfin I'm guessing ListOpt is what you want
11:18:13 stephenfin I _think_ ListOpt uses CSV, but it should be easy enough to verify (look for existing usages in the nova tree)
11:19:08 kashyap stephenfin: I see, will look once I make quick lunch
11:19:50 kashyap nova/conf/libvirt.py: cfg.ListOpt('hw_machine_type',
11:19:50 kashyap nova/conf/libvirt.py: cfg.ListOpt('disk_cachemodes',
11:19:50 kashyap $> git grep ListOpt nova/conf/libvirt.py
11:19:50 kashyap stephenfin: So there is some precedence:
11:19:51 kashyap nova/conf/libvirt.py: cfg.ListOpt('uid_maps',
11:19:53 kashyap nova/conf/libvirt.py: cfg.ListOpt('gid_maps',
11:19:55 kashyap nova/conf/libvirt.py: cfg.ListOpt('enabled_perf_events',
11:19:58 kashyap nova/conf/libvirt.py: cfg.ListOpt('vzstorage_mount_opts',
11:20:55 stephenfin kashyap: Then you're golden. That's the approach I'd take
11:21:06 stephenfin Offloads all the hard work (parsing) to oslo.config
11:22:06 kashyap I see, noted.
11:22:27 kashyap stephenfin: So, what I'm looking to do is something like:
11:23:03 kashyap If you specify:
11:23:10 kashyap cpu_model_extra_flags="+pcid,-mtrr,pdpe1gb"
11:23:10 kashyap cpu_model=IvyBridge
11:23:10 kashyap [libvirt]
11:23:28 kashyap Which means: Add the PCID feature and 'pdpel1gb' feature (assume '+' is
11:23:29 kashyap given if it's not specified), and *remove* the 'mtrr' feature.
11:23:38 kashyap Then Nova should be able to generate an XML something like:
11:23:46 kashyap <feature policy='require' name='pdpe1gb'/>
11:23:46 kashyap <feature policy='require' name='pcid'/>
11:23:46 kashyap <vendor>Intel</vendor>
11:23:46 kashyap <model fallback='forbid'>IvyBridge</model>
11:23:46 kashyap <cpu match='exact'>
11:23:49 kashyap </cpu>
11:23:56 kashyap stephenfin: Makes sense?
11:24:37 stephenfin Sounds sane. Why would you remove something though?
11:24:41 kashyap The +/- in nova.conf will be optional. If nothing is specified, assume '+'.
11:24:57 stephenfin I assume 'mtrr' would be added by default if you didn't explicitly add '-mtrr'?
11:25:16 kashyap stephenfin: If an advanced operator wants to generate a baseline CPU config, and a certain CPU flag is causing performance issue or other nuisance
11:25:34 kashyap And if she isolated the problem to _that_ specific CPU flag
11:25:40 kashyap Thens she may want to remove it.
11:25:43 kashyap Reasonable?
11:26:01 kashyap stephenfin: Yep, your assumption about 'mtrr' is true.
11:26:58 stephenfin Yum, that sounds reasonable to me
11:27:04 stephenfin *Yup
11:27:06 stephenfin :)
11:27:14 kashyap I.e. if you specified: 'mtrr', then it will be '+mtrr'. (Additional note: some named libvirt CPU models _already_ included 'mtrr')
11:27:25 kashyap Heh, noted.
11:27:29 kashyap Thanks
11:27:59 kashyap Now to figure out the XML spaghetti
12:00:21 openstackgerrit Chris Dent proposed openstack/nova master: Fix nits in allocation candidate limit handling https://review.openstack.org/536784
12:00:38 cdent stephenfin: that ^ gets some cleanups you asked for
12:02:42 ameeda alex_xu : can you please check this for me ? https://review.openstack.org/#/c/526900/
12:39:10 openstackgerrit int32bit proposed openstack/nova master: Set server status to ERROR if rebuild failed https://review.openstack.org/536268
12:43:04 openstackgerrit int32bit proposed openstack/nova master: Refix disk size during live migration with disk over-commit https://review.openstack.org/536351
12:49:37 ilyashakhat hi! may I have cores attention to https://review.openstack.org/#/c/519664/ ? the patch is approved, but Zuul did not merge it
12:49:55 ilyashakhat most probably needs another +W to trigger the gate
12:51:20 alex_xu ilyashakhat: done
12:51:22 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM: Test LM with encrypted volumes https://review.openstack.org/536350
12:51:43 ilyashakhat alex_xu: thanks!
12:52:46 alex_xu ameeda: sorry, really busy on freeze, will get chance after freeze
12:52:49 alex_xu ilyashakhat: np
12:54:25 ameeda alex_xu: np :)
13:17:44 openstackgerrit sahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/484997
13:29:15 lyarwood mdbooth: *facepalm* how did I screw up that if volume_id block *sigh*
13:29:33 mdbooth lyarwood: Hehe, it totally doesn't matter.
13:41:41 mdbooth lyarwood: Bet ^^^ is your fault :P
13:42:22 lyarwood mdbooth: you're welcome! :)
13:42:39 lyarwood mdbooth: pretty sure your swap volume test removal patch also caused a conflict this morning
13:42:49 lyarwood mdbooth: so it works both ways :)
13:43:10 Spazmotic This I will say is the one benefit from working the XenAPI drivers
13:43:14 mdbooth Indeed.
13:43:15 Spazmotic No merge conflicts :p
13:43:33 mdbooth Spazmotic: And also the curse :) How do you find getting core reviews on it?
13:43:49 Spazmotic Not sure if that burn was incidental or on purpose hehehehe
13:44:13 Spazmotic My last and first commit ac tually went through pretty quick, but that was back in Liberty
13:44:27 Spazmotic Now that i'm trying to get more active, struggling ot get any love with Xenapi, hence why i'm trying to learn placement
13:45:39 bauzas cdent: all cool
13:45:46 bauzas reviewing https://review.openstack.org/#/c/519462/
13:47:04 mdbooth Spazmotic: It's a perennial problem that it's harder to get core reviews in areas of the codebase cores are less familiar with. Doesn't even help to become a core, because you can't core review your own stuff :/
13:47:38 Spazmotic Hahah nah I certainly understand.. I know XenAPI isn't the hotness right now, so i try to be patient and wait :)
13:49:25 cdent efried_back_wed: you're not supposed to be here. I haven't rechecked the things you just rechecked yet to try to make less noise while the stuff before it is still being chewed on
13:50:56 efried_back_wed cdent It's a toss-up whether it'll be slower to check them serially (and have to wait for N to merge before rechecking N+1) or keep 'em all in the pipe in parallel so that maybe, just maybe, more than one will merge at once.

Earlier   Later