| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 16:16:21 | bauzas | not the RH version | |
| 16:16:24 | hrw | bauzas: have rhel7 developer jacket in a closet ;D | |
| 16:16:30 | hrw | upstream first! | |
| 16:16:36 | bauzas | ;) | |
| 16:16:55 | bauzas | my hat is taking some dust | |
| 16:17:02 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728 | |
| 16:17:07 | bauzas | I only used it by 4 years ago | |
| 16:17:29 | hrw | year ago I used it at local opensource conf | |
| 16:17:31 | cdent | was I supposed to return my hat when I left? It never fit, and now collects dust in a wardrobe (probably trying to make its way to narnia) | |
| 16:17:35 | mriedem | hrw: bauzas: given the time constraints for queens rc1, i'm good with a release note / feature support matrix docs update for queens, and update the check on driver startup in rocky | |
| 16:17:58 | bauzas | mriedem: hrw just provided a new rev | |
| 16:18:15 | bauzas | mriedem: just reviewing it and if okay, +2ing it | |
| 16:18:51 | mriedem | bauzas: i've also got your queens prelude reno up https://review.openstack.org/#/c/541495/ | |
| 16:18:59 | bauzas | mriedem: <3 | |
| 16:19:05 | mriedem | and a fix for the pike prelude https://review.openstack.org/#/c/541498/ | |
| 16:19:16 | bauzas | mriedem: saw the Foundation point about the reno notes ? | |
| 16:19:27 | mriedem | umm | |
| 16:19:34 | bauzas | how to not call the PTL about new features ? | |
| 16:19:36 | mriedem | release highlights in the releases repo? | |
| 16:19:38 | bauzas | yup | |
| 16:19:42 | mriedem | yes i know about that | |
| 16:19:44 | bauzas | cool | |
| 16:20:22 | bauzas | hrw: lemme fix some thing in your relnote | |
| 16:20:35 | hrw | feel free. you know that stuff better | |
| 16:20:37 | bauzas | hrw: you need to pass a link | |
| 16:26:24 | efried | mriedem: waitwait, how did https://review.openstack.org/#/c/541008/2 pass the nova-next job?? | |
| 16:27:37 | mriedem | efried: b/c i commented out the service user token code | |
| 16:27:43 | mriedem | to verify that was the combo that was breaking it | |
| 16:28:21 | efried | mriedem: Oh, I must have been looking at the wrong patch set. | |
| 16:29:30 | hrw | bauzas: ok, will dig | |
| 16:31:20 | efried | mriedem: Looks to me like that strip_version deal is gonna be the key. Need to remind myself what our aversion was to fixing the actual glanceclient bug... | |
| 16:35:49 | bauzas | hrw: I'm amending your note | |
| 16:35:58 | hrw | thx bauzas | |
| 16:36:12 | bauzas | hrw: I just entered a meeting, but I can work concurrently :) | |
| 16:36:28 | hrw | bauzas: I am in a meeting too | |
| 16:39:03 | stephenfin | mriedem: Have we a nova-neutron sync planned for the PTG? Could I add https://review.openstack.org/#/c/541290/ to that list? | |
| 16:39:40 | sean-k-mooney | stephenfin: what day is that on? the monday or tuesday or later in the week | |
| 16:44:07 | mriedem | stephenfin: nothing specifically scheduled yet, we have nova/cinder penciled in for thurs morning, | |
| 16:44:18 | mriedem | thursday has historically been our xp day | |
| 16:44:41 | mriedem | mon/tues is going to be vm/bm (keystone) stuff too, plus whatever else people go to (FFU, API WG, etc) | |
| 16:44:47 | mriedem | friday is misc / everything else | |
| 16:45:03 | mriedem | wed is likely priority topics for nova in rocky, which generally ends up being all about placement | |
| 16:45:28 | mriedem | so i assume nova/neutron love fest would be sometime thursday afternoon | |
| 16:46:48 | bauzas | mriedem: do we have hot topics for nova/neutron except the pre-allocation of ports in the conductor that nobody signed off yet to continue ? | |
| 16:47:06 | bauzas | mriedem: because stephenfin had the NUMA affinity thing in mind | |
| 16:47:18 | bauzas | and I think it's quite important for a lot of people | |
| 16:47:30 | stephenfin | bauzas: Jinx :) Scroll up | |
| 16:47:46 | bauzas | damn | |
| 16:47:56 | bauzas | we're harassing mriedem | |
| 16:47:59 | bauzas | come on | |
| 16:48:49 | mriedem | once we're past RC1 i plan on organizing the ptg etherpad a bit | |
| 16:49:06 | mriedem | until then, just put your topic ideas in there and i'll deal with them later | |
| 16:49:10 | cdent | mriedem: I've been playing around locally with the ideas you've done in your 1000 instance create thing: https://review.openstack.org/#/c/507918/ Can be a bit slow, but seems to behave. Now I'd like to change the parameters a bit and I'm not sure if I can: | |
| 16:49:14 | stephenfin | mriedem: Sweet. Thanks for the info. It's noted in the doc | |
| 16:49:56 | cdent | What I want to do is create a large number of nova-cpu processes (with the fake driver), but something needs to constrain for the fact that the resource providers needs to have different names (which usually comes from the hostname). Is there an already established way to do that? | |
| 16:50:43 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make the InstanceMapping marker UUID-like https://review.openstack.org/539323 | |
| 16:51:07 | cfriesen | cdent: can't you specify the host name in the config file? | |
| 16:51:19 | cdent | cfriesen: I was hoping to avoid creating multiple config files | |
| 16:51:42 | mriedem | cdent: i've wanted to play around with doing something like that too using NUMBER_FAKE_NOVA_COMPUTE | |
| 16:51:50 | mriedem | not sure if that actually works properly anymore, which is what i wanted to test | |
| 16:51:53 | mriedem | so tinker with NUMBER_FAKE_NOVA_COMPUTE i think | |
| 16:51:57 | cdent | could I override the host name from the ciommand line somhow? | |
| 16:52:03 | cdent | mriedem: cool, looking | |
| 16:52:35 | mriedem | i'm not sure if/how it creates a unique hostname for the n-cpu process | |
| 16:52:48 | cdent | found it, it does | |
| 16:52:58 | mriedem | oh | |
| 16:52:59 | mriedem | iniset $fake_conf DEFAULT nhost "${HOSTNAME}${i}" | |
| 16:53:03 | mriedem | heh | |
| 16:53:05 | mriedem | \o/ | |
| 16:53:06 | cdent | just appends a number in a separate fake conf file | |
| 16:53:09 | cdent | woot | |
| 16:53:16 | cdent | I will get this started then | |
| 16:53:35 | mriedem | i've been meaning to kick this for months now to compare some different setups against placement | |
| 16:53:43 | cdent | ditto | |
| 16:53:44 | mriedem | like caching vs filter scheduler | |
| 16:53:59 | cdent | my goal is basically to see if I can get placement to break under pressure | |
| 16:54:11 | bauzas | caching vs. filter scheduler is a big deal | |
| 16:54:13 | cfriesen | has anyone ever heard of an instance getting information for another instance when querying the metadata server? Seems unlikely, but we've apparently hit it occasionally. (Assuming the test isn't mucked up.) | |
| 16:54:36 | sean-k-mooney | mriedem: i think jay did some benchmeraks comparing cacheing vs filtering a while back | |
| 16:55:31 | melwitt | mriedem: I was thinking this might be something for rc1? https://review.openstack.org/#/c/540258/ | |
| 16:55:38 | cdent | bbs | |
| 16:56:09 | melwitt | I think affinity scheduling doesn't work for multi-cell | |
| 16:56:22 | bauzas | sean-k-mooney: well, it requires a real nova deployment tbh | |
| 16:56:36 | mriedem | melwitt: that would be broken since pike right? | |
| 16:56:44 | openstackgerrit | Merged openstack/nova master: Test case: new standard resource class unusable https://review.openstack.org/539732 | |
| 16:56:49 | melwitt | mriedem: yes | |
| 16:56:54 | melwitt | for multi-cell only | |
| 16:57:00 | sean-k-mooney | bauzas: to test schduling. not really it really just needs the right db entries | |
| 16:57:01 | bauzas | because retries mechanism w/ caching has to be compared vs. no retries w/ placement | |
| 16:57:19 | bauzas | sean-k-mooney: I disagree | |
| 16:57:46 | sean-k-mooney | bauzas: if you include retries you are not testing just schduling you are also mesuing boot time and other factors | |
| 16:57:55 | mriedem | melwitt: can an instance group have members in multiple cells? | |
| 16:57:59 | bauzas | sean-k-mooney: if you wanna compare apples and apples, fire 1000 instances concurrently and see how many are in ERROR state and how long it took for booting the successful ones | |
| 16:58:10 | bauzas | that's for me the success criteria for comparison | |
| 16:58:32 | bauzas | mriedem: melwitt: I think we discussed that but we never implemented a solution | |
| 16:58:46 | sean-k-mooney | bauzas: sound like a rally test to me :) which is also valid just if you want to compare just the schduler part that is not need | |
| 16:58:46 | melwitt | mriedem: hmm. not sure | |
| 16:59:06 | sean-k-mooney | bauzas: rally is proably more meaning full however | |
| 16:59:10 | bauzas | melwitt: mriedem: I'm pretty sure the affinity filters don't take the cells awareness in mind | |
| 16:59:31 | bauzas | sean-k-mooney: I don't care about the tooling, I care more about the criterias | |