Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-19
16:25:34 dansmith broken fundamentally I mean
16:25:59 efried cdent: I thought we talked about the fact that you want to hide the whole cluster-ness anyway?
16:26:20 efried Represent the whole thing as a single RP, and then vmware virt would do the individual node business under the covers.
16:26:32 cdent efried: yes, dan's saying that's broken
16:26:34 dansmith efried: that's what it does today, and it's breakable
16:26:58 dansmith efried: because nova will not know that one node is out of CPU but has some memory available, where another node has the opposite.. nova will think it can schedule to that, but it can't
16:27:07 gjayavelu @cdent @dansmith @efried I'm catching up on the discussions about the resource pools spec
16:27:45 efried dansmith: Okay, I agree with that. But I think the virt can probably mitigate
16:27:53 dansmith efried: it can't
16:27:55 efried ...by cleverly spoofing the inventories.
16:28:05 dansmith oh, it could work around it that way sure
16:28:13 dansmith that's fairly wasteful though :)
16:28:17 efried Basically by representing the least common denominator of the pool, as the inventory.
16:28:24 efried Is it?
16:28:30 dansmith sure
16:28:33 efried Because you wouldn't be able to schedule more than that anyway, wouldja?
16:28:59 dansmith well, maybe you're right
16:29:06 cdent yeah, you either fail to get allocation candidates, or you fail later
16:29:07 dansmith well, no,
16:29:13 cdent better to fail to get allocation candidates
16:29:43 dansmith you could have a node with small memory, small cpu, lots of disk, and another node with zero disk but lots of other resources.. you have to report yourself as fully committed at that point right?
16:29:47 efried Okay, I see, if you had one node with 1VCPU/1024MEM and one with 2VCPU/512MEM, you would wind up representing 1/512 even though you could technically schedule 1/1024 or 2/512.
16:29:49 dansmith cdent: also that
16:30:00 efried dansmith: Yeah, I think we're saying the same thing.
16:30:04 dansmith yar
16:30:23 cdent at the moment that is an accepted shortcoming
16:30:35 cdent mostly because the common case is for everything in the cluster to be the same
16:30:58 efried Yeah, was gonna say, homogeneity would make most of the issue moot.
16:31:02 dansmith right but your flavors have to basically fit together perfectly like puzzle pieces to avoid too much fragmentation
16:31:15 cdent ENOPARSE
16:31:18 openstackgerrit sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457
16:31:35 efried I think it's a pretty solid 80/20 that's worth going forward with.
16:32:32 efried Hypothetically the DRS will also reshuffle things to maintain/restore homogeneity, nah? That's kind of its job?
16:32:54 cdent yes
16:32:58 cdent well
16:33:09 cdent it will shuffle things. but it can't move hardware
16:33:21 efried understood.
16:33:21 dansmith that doesn't fix anything if your flavors are different sizes
16:33:27 efried It can
16:33:46 efried because it can consolidate VMs in ways that maximize utilization of a node.
16:33:50 efried If it's clever enough.
16:34:25 dansmith it may be able to if things fit right, yes
16:34:26 cdent even if its not clever enough, if vmware is being wasteful, that's vmware's problem, right?
16:34:27 efried But anyway, IMO it's acceptable to state that we know this solution is not 100% perfect, and move forward with it, because it will work *mostly* well, *most* of the time.
16:34:45 openstackgerrit Merged openstack/nova master: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553035
16:46:05 melwitt cool, thanks gibi
16:48:01 melwitt gibi, bauzas: I'd like to bring to your attention the draft for runways during the rocky cycle, if you have any feedback about it https://etherpad.openstack.org/p/nova-runways-rocky I'd like to kick of the process later this week so we can try it out and adjust it as we go
16:53:07 gibi melwitt: I opened that etherpad and I will try to check it tomorrow
16:53:17 gibi melwitt: seem like a pretty comprehensive doc
16:54:41 melwitt gibi: cool, thanks. yeah, there's been a lot of feedback already last week, so np if there's nothing else you'd like to add or ask
16:55:19 gibi melwitt: I will try to read it anyhow :)
16:55:36 melwitt thanks. I'll ping bauzas again tomorrow as it looks like he's on PTO today
16:57:02 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094
16:58:35 gibi mriedem_away, alex_xu_ , mlavalle: thanks for the awesome review feedback on the bandwidth spec. I tried to answer the questions inline https://review.openstack.org/#/c/502306
16:59:24 mlavalle gibi: will take a look again soon. Thanks!
17:00:26 gibi mlavalle: thanks
17:03:09 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Remove version/date from CLI documentation https://review.openstack.org/553903
17:10:28 jaypipes sorry y'all. off phone call now. reading back..
17:13:52 tssurya dansmith: I had a question about the reset cache implementation on the scheduler manager as a part of the cell disable spec, is it a good time now ? If you are busy I can come back later
17:14:05 dansmith tssurya: sure
17:14:31 tssurya So I was implementing the reset cache option on the scheduler manager , however when using the scheduler client from nova manage to call this reset on the cache in the manager, doesn’t this become an upcall which we don’t support ?
17:15:03 tssurya or am I not supposed to call this using the client from nova-manage ?
17:15:12 dansmith tssurya: I was saying this should be done in a reset() handler on scheduler manager, which gets triggered on SIGHUP
17:15:30 dansmith tssurya: correct, not from nova-manage or anything else, I thought I commented to that effect on the spec
17:15:49 tssurya yes you did, I guess I didn't understand the SIGHUP very well
17:15:53 dansmith tssurya: this is the example of a similar thing we have: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L543-L546
17:16:17 dansmith tssurya: so you can SIGHUP compute manager now to get it to clear the service version cache and rpc pin, which is the same sort of activity you're doing
17:17:21 tssurya right,
17:17:47 tssurya I need to "SIGHUP" the scheduler manager basically
17:20:36 dansmith tssurya: yeah, we have a couple other signal handlers for things like guru meditation, etc
17:33:40 lennyb Hi, my nova instance got stuck in 'deleting' when I try to delete instance that failed to be deployed via ironic n-cell-child.service.log
17:33:41 lennyb http://paste.openstack.org/show/704774/
17:41:16 openstackgerrit Eric Fried proposed openstack/nova-specs master: Mention (no) granular support for image traits https://review.openstack.org/554305
17:42:33 efried jaypipes, mriedem: ^
17:46:23 oomichi melwitt: cdent: hi, do we have an approval at the PTG for https://blueprints.launchpad.net/nova/+spec/placement-extract ?
17:46:27 jaypipes dansmith, mriedem: would you mind looking at https://review.openstack.org/#/c/534339/ please and letting me know if you agree with efried? I'm thinking I agree with him and if so, will abandon that and the following patch to it.
17:46:54 cdent oomichi: the decision at ptg was to make progress in rocky, but not complete it, and not as a priority
17:47:57 oomichi cdent: I see, thanks. I just wanted to see the bp as approved
17:48:54 cdent oomichi: I didn't actually create the bp until late last week, because efried suggested it would be useful. We hadn't really declared "let's have one" but it does seem like a good idea.
17:50:01 melwitt oomichi, cdent: yeah, seems useful to have it to track the work. I'll approve it
17:50:07 oomichi cdent: yeah, bp is good for tracking patches
17:50:14 oomichi melwitt: cool, thanks :)
17:55:23 efried cdent, jaypipes: (how) does forbidden traits play into glance image traits?
17:57:01 cdent efried: i would guess the same as flavors? I haven't put that much thought into that side of things, just the api side
17:57:30 jaypipes efried: I would expect that the format of specifying a forbidden trait would be the same. I would also expect that if there was a conflict between flavor's forbidden traits and image required traits (and vice versa), that we would bomb out.
17:57:53 efried cdent: Oh, right (rereading the spec now), we haven't even tried to talk about how forbidden traits will be expressed in flavors, have we?
17:58:07 efried Is that simply not planned for R?
17:59:02 jaypipes efried: I would have thought that s//required/forbidden in the extra spec value field would be how we'd do it.
17:59:36 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457
18:02:38 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Fix typos in release notes https://review.openstack.org/554175
18:06:16 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553817
18:09:05 melwitt dansmith, mriedem: looks like we have an interesting bug here during an upgrade ocata -> pike where while reading a service record, if it doesn't have a uuid, we generate one and try to save it back to the object, but that fails with "Can't upgrade a READER transaction to a WRITE" because a read will start off with @pick_context_manager_reader and we can't upgrade to a writer in the middle of the transaction https://bugs.launchpad.net/n
18:09:05 melwitt ova/+bug/1746509/comments/4
18:09:14 melwitt dangit
18:09:16 melwitt https://bugs.launchpad.net/nova/+bug/1746509/comments/4
18:09:17 openstack Launchpad bug 1722404 in OpenStack Compute (nova) ocata "duplicate for #1746509 Database transactions can fail with "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" because of scatter_gather_cells" [Undecided,In progress] - Assigned to Matt Riedemann (mriedem)
18:10:41 dansmith hmm, I'm not sure why it'd be different for scatter/gather
18:10:59 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553817
18:11:22 melwitt I don't think it's different. I think this is a separate different bug, but was highlighting the comment where someone explained what was going on
18:11:54 dansmith yeah, that explanation makes sense but I'm not sure why we weren't hitting that immediately is what I mean

Earlier   Later