| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-07 | |||
| 15:01:16 | luksky | INFO nova.filters [req-6553ad52-40f0-41d3-a11e-3682bdccf589 f0b6fd8f6a1a421094fd6259fa0a8d6c a17c1ce3cc114f05b5da8c9553e5e4d1 - default default] Filtering removed all hosts for the request with instance ID 'dbaecc98-c097-4b7b-b4f8-459f1ed1fecc'. Filter results: ['RetryFilter: (start: 22, end: 22)', 'IsolatedTenantFilter: (start: 22, end: 4)', 'AggregateMultiTenancyIsolation: (start: 4, end: 4)', 'AvailabilityZoneFilter: (start: 4, end: 4)', | |
| 15:01:34 | efried | edleafe: "capabilities don't change dynamically. State does." What an FPGA is "capable" of doing *does* change dynamically, when the thing is programmed. | |
| 15:02:02 | cfriesen | efried: thanks for the update. :) You caught me just after I left. | |
| 15:02:14 | efried | cfriesen: yw | |
| 15:02:24 | sean-k-mooney | luksky: the retry filter will only get the set of host that passed the first iteration - the one that was tried and failed | |
| 15:02:51 | luksky | (os-client) (PROD)[root@test1 ~]# openstack compute service list --service nova-compute | grep nova-compute | wc -l | |
| 15:02:52 | luksky | 26 | |
| 15:02:52 | luksky | WARNING: Failed to import plugin clustering. | |
| 15:02:53 | edleafe | efried: an FPGA region is capable of all available bitstreams for that model. When it is programmed, it is still capable of running any of the other bitstreams | |
| 15:03:26 | edleafe | Calling the current program a capability instead of the current state of the region is kind of a twist in language | |
| 15:04:06 | luksky | hm... don | |
| 15:04:12 | luksky | hm... don't get it | |
| 15:04:40 | edleafe | cdent: try #openstack-etymology instead :) | |
| 15:04:49 | luksky | shouldn't see "'RetryFilter: (start: 26, end: 26)" instead: "'RetryFilter: (start: 22, end: 22)" | |
| 15:04:50 | luksky | ? | |
| 15:04:54 | cdent | naw, I think we need to go deeper | |
| 15:05:26 | efried | again, realizing it's not perfectly pure, this is the best way to get where we want to be. Which is why we've ended up here several times after having discussed it the same way every time. | |
| 15:06:03 | sean-k-mooney | luksky: no | |
| 15:06:38 | sean-k-mooney | luksky: the retry filter on subsequet iterations does not retry host it knows cant pass | |
| 15:07:16 | edleafe | I think calling something "perfectly pure" is a bit condescending. I'm just pointing out that this approach is not the way placement is designed to work, and there may be downsides. If you all have agreed to go ahead with that, your eyes are wide open. | |
| 15:07:47 | sean-k-mooney | luksky: if its the first iteration and no filter have ran then the delta between 26 and 22 is because placemnt determined the other 4 instace did not have space for the instance and elminated them | |
| 15:08:56 | mriedem | jaypipes: i've gone fishing in the ML for the mystery of the server_group_members counting logic | |
| 15:09:02 | mriedem | maybe someone like tim bell will remmeber | |
| 15:10:28 | jaypipes | mriedem: to understand the mystery of the server group member counting, one must first understand the mystery that is the server groups implementation. | |
| 15:11:25 | mriedem | you said you're cool with server groups | |
| 15:12:07 | luksky | sean-k-mooney: thank You, does it can have some relation with not running discovered_host on some (i.e 4 compute) computes ? | |
| 15:16:17 | luksky | sean-k-mooney: I mean "nova-manage cell_v2 discover_hosts" | |
| 15:22:38 | jaypipes | mriedem: the concept? yes. the implementation... erm, not so much. | |
| 15:23:46 | mriedem | efried_mtg: bauzas: commented on the semver version for the novaclient release https://review.openstack.org/#/c/641678/ | |
| 15:23:48 | mriedem | i'm a bit torn | |
| 15:23:56 | mriedem | because of the first bullet here https://docs.openstack.org/releasenotes/python-novaclient/unreleased.html#upgrade-notes | |
| 15:24:41 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Raise error when force_raw_images and images_type are incompatible https://review.openstack.org/640271 | |
| 15:25:21 | bauzas | mriedem: great comment | |
| 15:25:25 | bauzas | I missed that one | |
| 15:25:50 | kashyap | Dead-simple +2/+W, can anyone put this out of its misery: https://review.openstack.org/#/c/640866/ | |
| 15:26:54 | mriedem | kashyap: uh... | |
| 15:27:08 | mriedem | kashyap: if that change isn't going to land in stein, the spec has to be re-proposed for train anyway, | |
| 15:27:20 | mriedem | so why not just make that change in the re-proposed spec with a note in the history abou the change? | |
| 15:28:03 | kashyap | Whatever works; alex_xu was also onboard with the above, FWIW. | |
| 15:28:09 | kashyap | mriedem: Will it / can it land for Stein? | |
| 15:28:37 | kashyap | mriedem: So, to be clear: you want me to repropose the whole spec fo Train? | |
| 15:28:44 | mriedem | kashyap: it would have to merge today | |
| 15:28:57 | kashyap | mriedem: Ah ... right, the freeze | |
| 15:29:14 | mriedem | i see alex_xu and stephenfin were reviewing it, but stephenfin was only reviewing docs | |
| 15:29:17 | mriedem | it looks like | |
| 15:29:36 | kashyap | See Alex's comment on line 548. | |
| 15:30:05 | stephenfin | Nah, it was just the docs/config opt naming that I had comments on | |
| 15:30:11 | stephenfin | rest of it is noddy | |
| 15:30:14 | stephenfin | (IMO) | |
| 15:31:00 | kashyap | stephenfin: Did you see this: https://review.openstack.org/#/c/640866/3 | |
| 15:31:04 | kashyap | dansmith: LOL | |
| 15:31:30 | kashyap | dansmith: Typing: 'define noddy' in Google shows this: | |
| 15:31:39 | kashyap | (1) [DATED] a foolish person. | |
| 15:31:46 | kashyap | (2) a tropical tern with mainly dark-coloured plumage. | |
| 15:31:56 | stephenfin | oops. noddy = easy or simple | |
| 15:32:10 | dansmith | kashyap: yes, I know how to use google and did.. still don't know | |
| 15:32:33 | kashyap | dansmith: Wasn't daring to tell you to LMGTFY ... just sharing the amusement | |
| 15:32:41 | dansmith | stephenfin: as in "something you nod (in agreement) at" ? | |
| 15:32:58 | kashyap | (That's how I read it) | |
| 15:32:58 | dansmith | stephenfin: homonym-wise, sounds like "naughty" as in "not good" | |
| 15:33:29 | mriedem | i want to say something about being offended as an american that i don't understand the language being used here | |
| 15:33:34 | stephenfin | I guess? I've never really though about it, to be honest | |
| 15:33:55 | mriedem | and how i need to take to social media to express my language victimizatoin | |
| 15:33:57 | mriedem | *ion | |
| 15:34:10 | kashyap | mriedem: Do you do social media besides IRC? I doubt that | |
| 15:34:20 | dansmith | I could sue stephenfin in portland for micro-aggression | |
| 15:34:35 | dansmith | (and probably win) | |
| 15:34:45 | kashyap | Yes, you will be quarantined into a "safe space" | |
| 15:35:02 | mriedem | kashyap: i have a linkedin account | |
| 15:35:05 | mriedem | does that count? | |
| 15:35:23 | dansmith | and he treats it like facebook | |
| 15:35:23 | kashyap | mriedem: Nah ... unless you're actively talking about marketecture there | |
| 15:35:39 | mriedem | dansmith claims to be an angry old man, but i think i have him beat | |
| 15:35:41 | dansmith | mriedem: so what's the deal with the user_id patch? what's the plan? | |
| 15:35:52 | dansmith | I don't want to be around late into the afternoon dealing with this | |
| 15:36:28 | mriedem | dansmith: i agree with what you said earlier, | |
| 15:36:29 | mriedem | "(8:49:57 AM) dansmith: mriedem: yeah I think we've been over that before.. definitely doesn't seem like something we can change on a whim regardless of the reason" | |
| 15:36:50 | dansmith | so, we add user_id, and user_id/project_id then yeah? | |
| 15:37:21 | mriedem | if we assume the server group member quota count is going to continue to be user_id only yeah | |
| 15:37:33 | mriedem | even if we don't, the additional index doesn't hurt does it? | |
| 15:37:37 | mriedem | jaypipes: ^ | |
| 15:37:39 | dansmith | no | |
| 15:37:58 | jaypipes | no, it doesn't really hurt anyuthing | |
| 15:38:07 | dansmith | I've got the set pulled down, I'll fix up the index | |
| 15:38:12 | mriedem | ok so the actual counting functions later in the series don't need to merge in stein | |
| 15:38:55 | dansmith | right, so maybe I'll just orphan them | |
| 15:40:36 | mriedem | sure | |
| 15:40:41 | mriedem | i'm targeting to get to https://review.openstack.org/#/c/633351/ | |
| 15:49:33 | jaypipes | +1 | |
| 15:52:19 | bauzas | mriedem: thanks for giving us the path to the legacy job for comparing, it helps | |
| 15:52:27 | bauzas | context being https://review.openstack.org/#/c/640181 | |
| 15:53:15 | openstackgerrit | Dan Smith proposed openstack/nova master: Add user_id field to InstanceMapping https://review.openstack.org/633350 | |
| 15:53:15 | openstackgerrit | Dan Smith proposed openstack/nova master: Add user_id column to the instance_mappings table https://review.openstack.org/633349 | |
| 15:53:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351 | |
| 15:53:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules https://review.openstack.org/638574 | |
| 15:54:19 | bauzas | mriedem: I guess you just copy/pasted the job definition YAML ? | |
| 15:54:57 | bauzas | or do I really need to do my job and diff the files ? | |
| 15:56:29 | sean-k-mooney | luksky: sorry i was on a call. im just runnig to another one but you only need to run discover hosts wehn you add new nodes | |
| 15:57:07 | efried | mriedem, bauzas: done | |
| 15:57:18 | sean-k-mooney | luksky: and you only need to run nova-manage cellv2 discover_hosts on the contoler nodes not on the compute nodes | |