Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-29
14:46:34 efried kashyap: we're discussing https://review.openstack.org/#/c/575735/ in the nova meeting. Are you going to be able to take another look?
14:46:48 kashyap efried: Hi
14:47:18 mriedem KeithMnemonic: yup, you don't have to tell me :)
14:47:22 mriedem need another stable core
14:47:26 mriedem bauzas: dansmith: ^
14:47:41 KeithMnemonic sorry we have an inpatient customer ;-)
14:48:09 KeithMnemonic didnt mean to pester
14:48:41 mriedem KeithMnemonic: it's fine
14:48:50 mriedem we need reminders
14:50:11 bauzas yup, and good news, I'm almost done with all my internal cruft, so moar time upstream \o/
14:57:49 artom bauzas, mriedem, hey, so I https://review.openstack.org/#/c/599587/, would appreciate another round of reviews :)
14:58:00 artom Err, I accidentally the verb
14:59:18 bauzas artom: I'll, once I'm done with sean-k-mooney's one ;)
14:59:37 phasespace Question. I'm trying to use the AggregateImagePropertiesIsolation scheduler filter. I've set up two availability zones (which themselves are host aggregates and contain all hosts in total), and created another host aggregate intended for windows VMs, with only a subset of the hosts. I've set the os_type metadata for the host aggregate to windows, and likewise with the image metadata. Still I'm able to launch instances on hosts not in the
14:59:37 phasespace windows host aggregate. Is this because the AZ host aggregates also need the metadata properties?
14:59:44 artom bauzas, SRIOV live migration? I should proll'y circle back to that as well :
14:59:45 artom :/
15:00:00 bauzas :)
15:01:25 cfriesen mriedem: thanks for the heads-up on the other hpet bug
15:02:29 mriedem yw
15:03:56 mriedem phasespace: that is likely the problem,
15:04:09 mriedem the windows aggregate can only host images with the matching images,
15:04:20 mriedem but that doesn't *exclude* the other hosts, not in the windows aggregate, from hosting those same images
15:04:46 mriedem phasespace: there is a nova spec describing this exact issue, sec
15:04:56 mriedem phasespace: https://review.openstack.org/#/c/609960/
15:05:44 rambo_li__ hi,all. I find it is important that live-resize the instance in production environment. We have talked it many years and we agreed this in Rocky PTG, then the author remove the spec to Stein, but there is no information about this spec, is there anyone to push the spec and achieve it? The link:https://review.openstack.org/#/c/141219/
15:06:01 rambo_li__ if anyone can tell me the actual progress?
15:06:24 mriedem rambo_li__: there were actually a series of PoC patches for that blueprint https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/instance-live-resize
15:06:44 sean-k-mooney cfriesen: mriedem by the way i have been asked to enable a feature that is very simlar to hpet in that it jsut a feture booling to set in the config. should i propsoe a spec an basically copy what we agreed for hpet or specless blueprint?
15:07:11 mriedem rambo_li__: the problem is while there is general agreement on supporting live resize, it is a somewhat complicated change and low priority, which therefore means it does not really get attention
15:07:45 mriedem sean-k-mooney: i would start with specless and bring it up in open discussion in the nova meeting
15:08:40 sean-k-mooney mriedem: ok the feture is jsut enable/disbaleing the PMU (performce monitoring unit) to reduce latency for realtime guests
15:08:45 sean-k-mooney ill write it up
15:10:45 rambo_li__ ok,thank you,last one ,:)Currently openstack does not support limiting the total number of block volumes that can be attached to an instance. It can be a useful quota which, on after implementation, will restrict the deterioration of VM performance disallowing a unlimited number of block volumes attachments to a VM. The link:https://blueprints.launchpad.net/nova/+spec/block-volume-limit-per-instance
15:11:03 rambo_li__ what do you think of it ?
15:11:21 mriedem sean-k-mooney: why does that need to be a config option rather than an image property?
15:11:45 mriedem rambo_li__: i thought there was already a duplicate spec for this, sec
15:11:58 mriedem rambo_li__: https://blueprints.launchpad.net/nova/+spec/conf-max-attach-volumes
15:12:27 sean-k-mooney mriedem: oh i ment the libvirt xml sorry config was bad phrasing on my part
15:13:04 mriedem rambo_li__: that one also had a spec https://review.openstack.org/#/c/597306/
15:13:06 rambo_li__ oh,I'm sorry about it
15:13:08 mriedem and a lot more discussion
15:13:11 sean-k-mooney mriedem: you could use a flaver extra_spec or image metadata to turn it on of off
15:13:54 rambo_li__ ok,ok,
15:13:58 mriedem rambo_li__: no problem; if that fits your use case then great.
15:14:06 mriedem it's not quota,
15:14:16 mriedem it's per-driver configuration for the max number of block devices per guest.
15:15:03 rambo_li__ yeah,it is necessary in some case
15:15:09 rambo_li__ cases
15:15:28 rambo_li__ :)
15:16:07 mriedem ok i will mark the other blueprint as superseded
15:17:51 rambo_li__ mriedem:goodbye
15:18:01 mriedem rambo_li__: good night
15:18:26 mriedem melwitt: johnthetubaguy: am i missing something or does this spec intentionally not support the block device limit for boot from volume? https://review.openstack.org/#/c/597306/
15:19:09 mriedem because it doesn't mention boot from volume with >26 bdms, and if we support that for attach volume, i expect people are going to want it for bfv later - so if there is good reason for not supporting it on bfv that should probably be amended to the spec
15:21:11 mriedem phasespace: also see https://bugs.launchpad.net/nova/+bug/1677217
15:21:11 openstack Launchpad bug 1677217 in OpenStack Compute (nova) " AggregateImagePropertiesIsolation filter return unwanted compute nodes" [Undecided,In progress] - Assigned to Md Nadeem (mail2nadeem92)
15:37:54 openstackgerrit Matthew Booth proposed openstack/nova master: Add BFV, ephemeral, and swap test cases for bug 1550919 https://review.openstack.org/620917
15:37:54 openstack bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9)
15:37:54 openstackgerrit Matthew Booth proposed openstack/nova master: Address nits from change I5619728d https://review.openstack.org/620941
15:39:39 openstackgerrit Matthew Booth proposed openstack/nova master: libvirt: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846
15:45:54 artom What are those "Cannot load <field> in the base class" errors again? I remember getting a few of them when writing tests for new code
15:48:11 artom Do they happen because you forgot to load a field with expected_attrs? Or does that only exist for Instances?
15:48:16 artom dansmith, ^^ awake yet?
15:48:40 dansmith artom: it means you're trying to lazy-load a field for which there is no handler
15:49:09 dansmith lazy-loading isn't magic, the object has to implement it specifically, because it may or may not mean "go back to the database"
15:49:17 artom dansmith, ah, there we go, thanks!
15:59:42 phasespace mriedem: thanks!
16:13:53 openstackgerrit Monty Taylor proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345
16:14:34 mordred mriedem_afk, efried: ^^ there's an initial stab at updating that patch
16:16:26 openstackgerrit Monty Taylor proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345
16:17:50 efried mordred: ack
16:22:17 mriedem_afk i do have this easy peasy workaround for sorrison now too https://review.openstack.org/#/c/620738/
16:36:13 mordred mriedem: yes. I like that - I'm going to rebase the other thing on top of it
16:38:44 openstackgerrit Monty Taylor proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345
16:57:15 mriedem mdbooth: you're getting lucky in https://review.openstack.org/#/c/620917/ because of defaults in the cinder fixture and api code
16:58:22 openstackgerrit Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
17:03:23 mdbooth \o/ I'm lucky :)
17:07:38 mdbooth mriedem: Thanks, will fix.
17:11:45 mriedem i also left some comments in https://review.openstack.org/#/c/620941/ - if we were to move that functional test module to a non-regressions location (since it's not a regression), i would think you'd want to do that before proposing backports and such, but just something to think about
17:17:11 mdbooth mriedem: Ok. Agree it's not a regression, put it there because I had the (incorrect) impression that's where we were putting this kind of 'assert the broken behaviour, fix it and update the test' stuff.
17:17:37 mriedem yeah that's the usual pattern, but doesn't always have to be a regression to do that,
17:17:47 mriedem just nice for the hairier things that need a big functional test
17:24:34 openstackgerrit Matthew Booth proposed openstack/nova master: Add BFV, ephemeral, and swap test cases for bug 1550919 https://review.openstack.org/620917
17:24:34 openstack bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9)
17:24:34 openstackgerrit Matthew Booth proposed openstack/nova master: libvirt: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846
17:24:43 mdbooth mriedem: Thanks.
18:16:00 mriedem jaypipes: dansmith: before yikun spends too much time on writing a PositiveFloatOpt, i'd like to get your input/agreement on it https://review.openstack.org/#/c/602804/12/nova/conf/compute.py@481
18:16:30 mriedem he started that in oslo.config https://review.openstack.org/#/c/620547/
18:19:31 dansmith mriedem: tbh, I'd just do the min=0 thing and just log error and treat the value as 1.0 if it's invalid
18:19:42 jaypipes mriedem: ok, I'll try to look at that. right now, just fighting to keep myself from throwing myself off a cliff.
18:19:42 dansmith just seems like a really minor detail to go to all this trouble
18:19:57 dansmith but if it's really important, I'd say do it in nova as you suggested.
18:22:06 dansmith commented on both
18:57:29 mriedem it's not really important, which is also what i said in my comment. if we were going to ignore <1 and make it 1.0 anyway, then the min should be 1.0
19:01:32 efried jaypipes: Nudge (not off a cliff): Is https://review.openstack.org/#/c/615646/ green?
19:04:19 artom Cliff? That's stephen's thing
19:04:45 dansmith mriedem: I meant ignore if ==0
19:06:42 mriedem yeah i replied in there and just said leave as is and we'll change later if it's a problem
19:12:47 mriedem bauzas: your turn https://review.openstack.org/#/c/599587/9

Earlier   Later