Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-05
17:43:52 melwitt I see
17:44:47 sean-k-mooney tssurya: were you discussing this with dansmith yesterday? someone else was having issues with cellsv1 and instance_extra
17:45:02 tssurya sean-k-mooney: yes belmiro was talking about this
17:45:15 sean-k-mooney tssurya: ah yes
17:45:22 tssurya we are from the same team at CERN (he is my supervisor :D)
17:45:48 sean-k-mooney tssurya: he will be happy to know your contunuing to follow up so
17:46:09 tssurya sean-k-mooney: :)
17:46:42 openstackgerrit Eric Fried proposed openstack/nova master: [placement] Fix incorrect exception import https://review.openstack.org/558916
17:50:23 efried mriedem, melwitt: ^
17:51:00 mriedem o
17:51:04 mriedem already looking at it
17:51:15 mriedem agree with all of your comments about mock usage in PS2 btw
17:52:14 jaypipes mriedem: honestly, if some operator sets an image property called traits_required=foo, I really don't care.
17:52:43 jaypipes mriedem: traits were all about trying to standardize this mess of completely random string key/values.
17:53:11 jaypipes mriedem: we can add all the unit tests you want for these edge cases, but I don't feel they add much value. Just MHO.
17:54:52 arvindn051 btw, since we call _set_attr_from_trait_names method after the _set_attr_from_current_names, i can just overwrite over the other property just to be safe
17:56:07 arvindn051 i currently just have a check if "'traits_required' not in self" i can also check for if traits_required is also not a list, then i overwrite it...would that make sense?
17:56:07 openstack Launchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New]
17:56:07 melwitt owalsh: do you know if/how things got resolved here? https://bugs.launchpad.net/nova/+bug/1717915
17:57:01 jaypipes after a certain point, I just don't feel like doing any reviews -- or at least don't feel like leaving any *positive* reviews. seems like we go out of our way sometimes to -1 for things that just aren't particularly important.
17:58:34 jaypipes efried: speaking of negative reviews... what is the current status on the whole "use case" around granular request groups *not* meaning that the resource providers will be different for each group?
17:59:57 arvindn051 jaypipes: just taking it as constructive criticism...you guys have been at this a lot more than i have :)
18:00:36 efried jaypipes: I recently wrote up a decent synopsis in a spec review. Finding...
18:00:39 arvindn051 i am sure there are more edge cases...but if we want to guard against known one by adding few lines of code...should be fine
18:01:23 jaypipes scenario described for this test case.")
18:01:23 jaypipes efried: since I "solved" that "use case" with the whole "sum the inventories for like resource classes for a tree" and that was -1'd by you (https://review.openstack.org/#/c/534339/) because it would not make sense ("No, I think that, under the current design, if you want two VFs, you should specify them in separate granular request groups, even if they're identical, so that you'll still get a viable candidate in the
18:02:34 efried jaypipes: https://review.openstack.org/#/c/555081/4/specs/rocky/approved/cpu-resources.rst@412 while I go read that...
18:02:39 jaypipes arvindn051: I'm referring to my own frustration... not even considering whether you may or may not be frustrated by the constant back and forth (I would be if I were you)
18:03:18 jaypipes efried: yeah, I've read that over and over. And it directly contradicts your own statement on the sum resources patch.
18:04:47 efried jaypipes: Sorry, which statement/patch?
18:05:22 mriedem arvindn051: if you want to handle the edge case check in a follow up that's fine with me
18:05:28 arvindn051 jaypipes: thanks. i am just starting out with contributing to the project...so learning pains is how i am taking it. So close to getting it checked in :)
18:05:34 jaypipes efried: "No, I think that, under the current design, if you want two VFs, you should specify them in separate granular request groups, even if they're identical, so that you'll still get a viable candidate in the scenario described for this test case."
18:05:47 mriedem arvindn051: add the check on top and i'll approve this
18:07:42 efried jaypipes: We talked about that some more in IRC afterwards IIRC, and I gave up on the idea that we would separate out the *results* for that kind of request. But there's nothing contradictory there. Specifying two identical VFs in separate numbered request groups allows you to get viable results whether you have (available inventory in) one PF or multiple.
18:08:07 efried jaypipes: I also realized later that we can't separate out the results without changing the response format, because dict.
18:08:52 efried jaypipes: So I accepted that, in such cases where placement had to combine those results, the caller would have to pick them apart again (based on their request, I guess).
18:09:40 efried jaypipes: In any case, like I said in that comment, we're going to need both semantics at some point. It's just a matter of which one is the default.
18:10:08 efried Someone who feels strongly that it should be opposite to what's in the spec should propose an amendment to that spec.
18:10:29 efried and/or an addition to the syntax that will enable the other.
18:10:30 openstackgerrit Matt Riedemann proposed openstack/nova master: [placement] Fix incorrect exception import https://review.openstack.org/558916
18:11:20 efried mriedem: Do I get to +2 this again now? ^ :P
18:11:42 efried (jk, need to wait for melwitt to relook anyway)
18:11:45 mriedem efried: i'm sure melwitt would be fast to hit it
18:12:11 efried I can't believe I made a typo on the word whose typo I was fixing.
18:12:14 melwitt yeah geez yall
18:12:27 efried I blame the one-handed dvorak typing because fried chicken in the other hand.
18:13:00 melwitt fried chicken, good excuse
18:13:28 jaypipes numbered groups."
18:13:28 jaypipes valid for e.g. DISK_GB. If you want to be able to split, use separate
18:13:28 jaypipes While such a split could be seen to be sane for e.g. VFs, it is clearly not
18:13:28 jaypipes *resource_class*:*count* will never be split across multiple RPs.
18:13:28 jaypipes efried: from the spec: "* For both numbered and un-numbered ``resources``, a single
18:14:06 jaypipes efried: that, I believe, is the source of much confusion.
18:16:18 melwitt guh the server_group func tests are such a thorn in our side. another random failure http://logs.openstack.org/84/534384/24/check/nova-tox-functional/94444cd/testr_results.html.gz
18:16:35 efried jaypipes: How is that unclear?
18:17:28 efried If it said, "If you want to split," instead of "If you want to *be able to* split," perhaps.
18:18:27 efried And the third bullet in that same list is clear.
18:20:45 jaypipes efried: I strongly disagree that this is clear. otherwise we wouldn't have such strong disagreement about what was meant.
18:21:20 jaypipes melwitt: s/server_group func tests/server_group/
18:22:13 melwitt fair :)
18:22:42 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM: Cold Migrate & Resize https://review.openstack.org/553583
18:22:42 efried There wasn't disagreement about what was meant. People either didn't care at the time, or changed minds afterwards.
18:23:06 efried I'll grant that part of the problem may have been "too many words in spec". I've been working on that issue in subsequent specs.
18:24:12 jaypipes efried: or thought it meant one thing when in actuality it meant another.
18:25:09 efried I'm sure I'm having trouble seeing it because I wrote it, but to me this is crystal: "Separate groups (numbered or un-numbered) may return results from the same RP. That is, you are not guaranteeing RP exclusivity by separating groups. (If you want to guarantee such exclusivity, you need to do it with traits.)"
18:25:46 jaypipes efried: it's a subtle but extremely important distinction that "use_same_provider=True" meant (for you) that the resources from the single request group would be met by the same provider, which dansmith and I thought it meant that the resources in granular request groups would be met by different providers.
18:26:09 odyssey4me Hi everyone. I wonder if someone could help just verify whether this is normal or not. I'm trying to use the openstack client to disable a service, but it errors out. This is on a test environment which was deployed with Pike, then upgraded to Queens. I've tried this with the scheduler, consoleauth and conductor services, all with the same result.: https://gist.github.com/odyssey4me/5cec9c69dcf0f118f7a62464df64b480#file-output-log-L74
18:26:09 openstackgerrit Merged openstack/nova master: Use a pythonic delete. https://review.openstack.org/554792
18:26:58 efried we're talking about the code now? (Cause use_same_provider isn't part of the spec.) There's no way use_same_provider=True could be construed (or even used) to signify anything *between* request groups.
18:26:58 jaypipes odyssey4me: hi Jesse, yes, that's normal. you need to reconcile your cell to host mappings.
18:27:24 jaypipes efried: use_same_provider=False is set on numbered request groups.
18:27:46 jaypipes efried: which makes it seem that resource providers will not be the same for each numbered request group.
18:27:48 odyssey4me jaypipes apologies for my ignorance - what exactly does that mean? got a doc link or something for me?
18:27:55 efried vice versa jaypipes
18:28:05 jaypipes efried: I'm not saying you meant to cause this confusion, just that it obviously is confusing to some people.
18:28:11 efried in any resource provider in the same tree, or a sharing provider.
18:28:11 efried provider. If False, represents a request for resources and traits
18:28:11 efried resources and traits which must be satisfied by a single resource
18:28:11 efried If True, (the default) this RequestGroup represents requests for
18:28:11 efried :param use_same_provider:
18:28:42 jaypipes odyssey4me: yeah, sec, grabbing one
18:28:44 efried To put it in context, though, a RequestGroup is *one* request group. This says nothing of how this RequestGroup interacts with other RequestGroups.
18:29:05 odyssey4me tyvm, appreciate your time jaypipes
18:29:05 jaypipes odyssey4me: https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-cells-v2
18:29:33 jaypipes odyssey4me: also try this:
18:29:34 jaypipes https://docs.openstack.org/nova/latest/cli/nova-status.html#upgrade
18:29:39 jaypipes nova-manage status check
18:30:31 odyssey4me ooh, a new command :)
18:30:53 jaypipes odyssey4me: sorry, that should have been nova-status upgrade check
18:31:13 odyssey4me with return codes and everything, fancy :)
18:31:22 odyssey4me yeah, got that - it says all is well
18:31:23 jaypipes odyssey4me: you can thank mriedem for it.
18:32:00 mriedem i think that's microversion 2.53 you're hitting
18:32:05 odyssey4me many thanks to mriedem then - we shall make use of this in ways similar to keystone doctor
18:32:20 mriedem odyssey4me: the services API only allows enabling/disabling 'compute' services once you're on cells v2
18:32:43 mriedem b/c those compute service are mapped to a cell in the api db, but other non-compute services aren't
18:32:45 mriedem plus,
18:32:56 mriedem it doesn't make sense to disable non-compute services, as that doesn't mean/do anything
18:33:07 odyssey4me ok, then something's probably wrong in our config or something - because this started life as pike, so cellsv2 should have just been there from the start

Earlier   Later