Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-05
16:39:27 mriedem dansmith: if you're done with your meeting, this will close out the cell-disable bp https://review.openstack.org/#/c/556459/
16:39:32 mriedem just the final docs patch
16:51:20 melwitt can someone remind me, in this last comment from belmiro, did he mean cells v2 instead of cells v1 or? https://bugs.launchpad.net/nova/+bug/1761197
16:51:20 openstack Launchpad bug 1761197 in OpenStack Compute (nova) "Not defined keypairs in instance_extra cellsV1 DBs" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
17:01:42 openstackgerrit Arvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits https://review.openstack.org/557795
17:02:29 arvindn051 dansmith: jaypipes: updated code per comment(changed name of the field)
17:14:35 jaypipes dansmith: you good with it, I'm good with it.
17:14:56 dansmith I'm under a pile of other stuff right now,
17:14:58 dansmith hence me ignoring pings
17:14:59 dansmith sorry
17:15:02 dansmith will look later
17:15:59 jaypipes dansmith: no worries. I left a +2 on it.
17:26:20 sean-k-mooney jaypipes: just thinking back over your cpu spec and some of the other granualr requests discussions. have we finalised on the fact that numbered request groups will be guraenteed to be form different RPs
17:29:53 efried sean-k-mooney: Nobody has proposed a spec change
17:31:18 sean-k-mooney efried: hum ok in the current form if they are in the same request group are all resouces in that group required form the same subtree?
17:31:56 sean-k-mooney efried: ill read the sepc to confim just tought i would ask if you knew off the top of your head
17:32:09 efried if in the same numbered request group, they'll land in the same provider
17:32:38 efried in the unnumbered group, can be spread around the tree
17:32:38 sean-k-mooney efried: same provider or "same proviers or one of its childern"
17:33:56 melwitt tssurya: in this bug in belmiro's last comment, did he mean keypair isn't in instance_extra with cells v2? the comment says "cells v1" https://bugs.launchpad.net/nova/+bug/1761197
17:33:56 openstack Launchpad bug 1761197 in OpenStack Compute (nova) "Not defined keypairs in instance_extra cellsV1 DBs" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
17:34:17 efried sean-k-mooney: same provider. The only thing we have today (impl or design) that uses children is the concept of grouping as a tree. Nothing in placement deals with hierarthies or branches or subtrees etc
17:34:57 efried hierarchies, that is
17:35:02 melwitt fwiw, I checked a recent devstack of mine and see keypairs in instance_extra in the nova_cell1 database, so if there's a bug in ocata, it looks like it got fixed somehow later
17:35:27 melwitt (assuming cells v2 was what he meant)
17:36:19 sean-k-mooney efried: so you can never have a numbered resouce group containig CPUs and virtual fucntions and find a host as they will be from diffrent RPs in a subtree of a compute host
17:36:21 tssurya melwitt: no its in cellsv1 that we have this issue
17:36:38 melwitt tssurya: ah, okay. thanks for confirming
17:37:03 jaypipes sean-k-mooney: that is correct.
17:37:11 jaypipes sean-k-mooney: and we are aware that is a problem.
17:37:16 sean-k-mooney jaypipes: ok
17:37:53 efried sean-k-mooney: That's correct, given your premise.
17:38:01 openstackgerrit Merged openstack/nova master: Add nova-status check for ironic flavor migration https://review.openstack.org/527541
17:38:01 tssurya no problem :), yea its a weird thing happening between the two migrations in newton, one moving keypairs from the cellsDB keypairs table to instance_extra.keypairs and two moving the instance_extra.keypairs up to the apidb
17:38:27 tssurya and for the new instance currently created we don't have any instance_extra.keypairs and instance_extra.vcpu_models
17:38:32 tssurya instances**
17:38:39 sean-k-mooney i was talking to xlinx at the ptg after teh cyborg session ended. they reached out to me during the week to follow up and i suggested a solution that should still work for them provided we require they come form the same provider
17:39:15 sean-k-mooney efried: jaypipes it would still work with subtrees potetailly but it may also not
17:41:58 melwitt tssurya: yeah ... the way cells v1 works is it will write the instance data to the API level DB first, then sync the instances table down to child cell, and I assume instance_extra must not be part of that
17:42:18 melwitt so you'll never see instance_extra in child cells AFAIK
17:42:34 tssurya yes , this is what we are also thinking
17:42:46 tssurya I mean we have instance_extra, but some fields are not being synced
17:43:02 melwitt oh, so some fields and not others
17:43:10 tssurya yea
17:43:22 mriedem jaypipes: dingers on that image meta props traits change
17:43:29 melwitt that would make sense if some writes are initiated while already in the child cell
17:43:32 tssurya like for now we know for sure instance_extra.keypairs and instance_extra.vcpu_models are not syncing
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 melwitt owalsh: do you know if/how things got resolved here? https://bugs.launchpad.net/nova/+bug/1717915
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 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: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 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:01:23 jaypipes scenario described for this test case.")
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 efried: from the spec: "* For both numbered and un-numbered ``resources``, a single
18:13:28 jaypipes *resource_class*:*count* will never be split across multiple RPs.
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 valid for e.g. DISK_GB. If you want to be able to split, use separate
18:13:28 jaypipes numbered groups."

Earlier   Later