Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-28
10:01:11 sean-k-mooney also the verion in the prefilter has a bug
10:01:27 sean-k-mooney sure im just going to make coffee anyway
10:01:47 sean-k-mooney want me to wait untill you review all tree
10:01:57 sean-k-mooney then ill adress all your comments
10:02:36 openstackgerrit Balazs Gibizer proposed openstack/nova master: Allow resizing server with port resource request https://review.opendev.org/679019
10:11:30 stephenfin sean-k-mooney: done
10:12:48 sean-k-mooney thanks just looking at the scond one now
10:16:29 openstackgerrit Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895
10:22:35 bauzas stephenfin: wow, chilling ^
10:23:33 sean-k-mooney bauzas: is that like something taht is almost cool
10:23:54 bauzas I should wear a t-shirt saying "I love reshapes"
10:24:16 sean-k-mooney if you did we would make you write all of them
10:24:33 bauzas \o/
10:24:37 bauzas anyway, lunch now
10:45:49 openstackgerrit Luyao Zhong proposed openstack/nova master: Claim resources in resource tracker https://review.opendev.org/678452
10:45:50 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces https://review.opendev.org/678453
10:45:50 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: report VPMEM resources by provider tree https://review.opendev.org/678454
10:45:51 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup https://review.opendev.org/678455
10:45:51 openstackgerrit Luyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec https://review.opendev.org/678456
10:45:52 openstackgerrit Luyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory https://review.opendev.org/678470
11:03:12 openstackgerrit Luyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory https://review.opendev.org/678470
11:22:53 sean-k-mooney stephenfin: i hope that answers your question. https://review.opendev.org/#/c/665775/14/nova/scheduler/request_filter.py@176 im going to start reworkign the patches now but your comments make sense
11:28:46 openstackgerrit Brin Zhang proposed openstack/nova master: Add user_id and project_id colume to Migration https://review.opendev.org/673990
11:51:40 aspiers kashyap: I'm getting a parse error on your last sentence :)
12:06:41 aspiers kashyap: but what I don't understand is why a list of OS bootloader features would be subdivided into two sections called 'type' and 'readonly'
12:07:06 aspiers 'type' makes no sense as a category
12:20:16 kashyap aspiers: Err, sorry for the garbled sentence; I meant, why doesn't os.loader.features with type|readonly make sense.
12:20:51 kashyap aspiers: Okay, you don't think 'type' makes sense as as category...
12:24:59 kashyap aspiers: Anyway, I'll think a bit more on what I can do there.
12:26:28 aspiers kashyap: 'type' makes as much sense as a category as 'category' does
12:26:56 aspiers i.e. none
12:27:57 kashyap aspiers: Hmm. As you'll recall, it's the "type" ("category"? :-)) of loader. I'll see about reworking
12:41:25 kashyap aspiers: Also on your "not understanding" why a list of OS bootloader features would be subdivided into the two sections (enums) -- ask libvirt upstream :D
12:42:26 kashyap It _sounds_ like you temporarily forgot (but it's in the commit message, and you've seen it before :-)) the output spit out by getDomainCapabilities()
13:05:25 alex_xu aspiers: stephenfin in the end, I confused what the descision at here https://review.opendev.org/#/c/664420/42/nova/scheduler/request_filter.py@206
13:06:08 alex_xu in the end, we said use req filter or not...
13:24:08 stephenfin alex_xu: I thought we were going to copy the approach from https://review.opendev.org/#/c/671801/32/nova/scheduler/utils.py
13:24:38 stephenfin so that's why I dragged https://review.opendev.org/#/c/674894/ to the front of the series
13:25:25 stephenfin mriedem, dansmith: You have been summoned by efried https://review.opendev.org/#/c/675338/
13:26:45 stephenfin alex_xu: Yeah, that's what efried's comments are saying too. I guess aspiers is waiting to make sure that gets in first
13:27:09 mriedem stephenfin: why?
13:27:20 stephenfin Haven't a notion
13:27:52 mriedem the extra spec in those api samples could just as well be {'fart': 'sniffer'}
13:28:02 stephenfin Maybe because it's microversion related
13:28:11 stephenfin Yup, that's what I thought
13:28:27 mriedem it's not really,
13:28:36 mriedem but i see a good reason to -1 the shit out of your patch
13:28:47 mriedem oh drat https://review.opendev.org/#/c/675338/11/nova/tests/fixtures.py
13:28:48 mriedem you already got it
13:29:16 stephenfin #winning
13:30:15 mriedem +2
13:38:42 mriedem mdbooth: for https://review.opendev.org/#/c/677736/ i think we're just waiting for your customer to test it and ack it right?
13:38:44 aspiers stephenfin, alex_xu, efried: my understanding was that we were going to keep it in req filter for now and then change it later
13:39:24 aspiers kashyap: I don't have the slightest issue with features being split into two *meaningful* sections. But a section entitled "type" is totally meaningless.
13:39:42 mdbooth mriedem: So... they did test it but they didn't provide the same logs as last time. I've asked them for them, but they haven't been provided yet.
13:39:44 mriedem gibi: can i get a re-+W on https://review.opendev.org/#/c/637605/37 ?
13:40:00 mriedem mdbooth: did they notice the slow down?
13:40:18 aspiers kashyap: Let me take another tack. Please explain to me what this feature section entitled "type" is supposed to contain.
13:40:49 aspiers kashyap: And while you're at it, I'd like to understand what the section entitled "readonly" is supposed to contain.
13:41:11 mdbooth mriedem: Previously they were seeing compute hosts flapping, but that was only logged by n-api. We don't have logs for n-api.
13:41:12 mriedem stephenfin: i've re-ordered some of the less complicated changes in the cross-cell resize series to the bottom, could you take a look at this simple one to plumb passing the power_on flag down through driver.spawn()? https://review.opendev.org/#/c/642590/30
13:41:20 stephenfin I sure can
13:41:28 mriedem which incidentally is something i think mdbooth has asked for in the past - the ability to create a stopped server
13:41:30 mdbooth mriedem: They *are* experience other environmental issues.
13:41:31 mriedem or maybe i'm dreaming that up
13:41:40 mdbooth mriedem: Yep, I have asked for that.
13:41:41 kashyap aspiers: I agree that a generic section is meaningless. Maybe 'loader_type', which tells _where_ the guest memory should be mapped -- whether it s a 'rom' or 'pflash' ?
13:42:10 mdbooth mriedem: So what I wanted to see be sure is: in the presence of their environmental issues, are the compute nodes continuing to flap?
13:42:15 mdbooth I'm hoping the answer's no.
13:42:24 mriedem right
13:42:39 aspiers kashyap: https://libvirt.org/formatdomaincaps.html#elementsOSBIOS doesn't even make sense here
13:42:41 mdbooth However, I'm not convinced it's worth waiting, tbh.
13:43:07 aspiers kashyap: It says of "type": "Whether loader is a typical BIOS (rom) or an UEFI binary (pflash). This refers to type attribute of the <loader/> element."
13:43:17 mdbooth It's a pretty clear bug, and the fix doesn't break anything we test, or a real environment.
13:43:55 aspiers kashyap: so it's portraying it as an either/or choice, but the schema places no restriction on the number of <value> elements, and indeed the example even lists *both* rom and pflash
13:44:23 aspiers kashyap: Also, there is no "type attribute of the <loader/> element"
13:44:45 aspiers kashyap: the docs for 'readonly' are even worse
13:44:56 kashyap aspiers: The docs _suck_ in this area
13:45:10 aspiers kashyap: and the example gives both yes and no as simultaneous values ... I mean, WT actual F
13:45:31 kashyap aspiers: On the either/or choice -- yeah, the docs say that, but the damn 'enum' implies there _could_ be more in future. Grrr
13:46:02 aspiers If it is supposed to be a choice between rom and pflash (and maybe others) then it should be <type>rom</type> or <type value="rom"/>
13:46:22 aspiers Likewise <readonly>yes</readonly> or <readonly value="yes"/> etc.
13:46:45 kashyap aspiers: Yeah, the upstream schema as it stands is not really ideal :-(
13:46:48 aspiers but a mapping from 'type' / 'readonly' to a list of values makes no sense
13:47:58 aspiers If multiple concurrent types are really allowed then I could get on board with <types>...</types>, or maybe even just about tolerate <enum name='types'>...</enum>
13:48:09 aspiers but 'type' (singular) rather than 'types' (plural) ... no
13:49:10 kashyap Right, so the "reality" is: it is a binary choice as it stands, not a multiple types at the _same_ time.
13:49:12 aspiers kashyap: Do you know whether rom and pflash are mutually exclusive values? Or can it actually be both at once?
13:49:21 aspiers What is actually valid here?
13:49:26 kashyap aspiers: Let me check with Michal Privoznik
13:49:33 kashyap (libvirt dev)
13:49:49 aspiers kashyap: Thanks. Maybe it's more that the example XML given is wrong
13:50:18 aspiers kashyap: I can imagine that they might have written that to show all the <value>s which are allowed, without realising that putting them all together at once is deeply confusing.
13:51:02 stephenfin mriedem: We don't need to post to the mailing list when we add a parameter to the virt driver interface like that, do we?
13:51:12 stephenfin (the 'power_on' parameter)
13:51:52 kashyap aspiers: I completely agree on the confusion there, libvirt upstream definitely needs to address this.
13:52:13 aspiers kashyap: thanks for the moral support ;-)
13:52:34 aspiers kashyap: I've just pinged Jim Fehlig about it too
13:53:04 mriedem stephenfin: "need" to? no. but i can.
13:53:13 artom stephenfin, depends on who you ask, but it won't hurt

Earlier   Later