| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-11 | |||
| 20:29:52 | dansmith | right | |
| 20:29:53 | mriedem | there is a security issue for that | |
| 20:30:05 | dansmith | and it's broken because it requires using specific flavors for bfv | |
| 20:30:15 | mriedem | https://github.com/openstack/nova/commit/763fd62464e9a0753e061171cc1fd826055bbc01 | |
| 20:30:22 | melwitt | yeah, just wanted to make sure I understood what the definition of "fixed" was in the convo | |
| 20:30:30 | mriedem | i have to run, be back in a few | |
| 20:30:44 | mriedem | dansmith: let's add the release note and change related-bug to partial-bug (for my ocd) and then i'm +2 | |
| 20:30:53 | dansmith | ack | |
| 20:33:57 | dansmith | mriedem: I'll remind you I added related-bug for you :) | |
| 20:36:27 | dansmith | damn, you said "link" not specifically related | |
| 20:36:30 | dansmith | I' | |
| 20:36:33 | dansmith | I'll get you next time | |
| 20:39:40 | openstackgerrit | Dan Smith proposed openstack/nova master: Avoid requesting DISK_GB allocation for root_gb on BFV instances https://review.openstack.org/580720 | |
| 21:02:25 | mriedem | muwahahaha | |
| 21:08:15 | mriedem | dansmith: see my hedge in the release note | |
| 21:08:38 | mriedem | i wonder if we should be clear that if you're not using the FilterScheduler (and/or using the DiskFilter) this is still a problem | |
| 21:08:42 | dansmith | sure makes sense | |
| 21:08:52 | mriedem | but, CachingScheduler is deprecated and DiskFilter should be disabled if using FilterScheduler | |
| 21:10:43 | dansmith | how's this: | |
| 21:10:45 | openstackgerrit | Dan Smith proposed openstack/nova master: Avoid requesting DISK_GB allocation for root_gb on BFV instances https://review.openstack.org/580720 | |
| 21:11:17 | mriedem | lgtm | |
| 21:11:20 | mriedem | pew pew | |
| 21:12:43 | mriedem | at some point we should drop the ironic flavor migration stuff, since then we can drop the remaining allocation stuff in the report client for the RT | |
| 21:13:05 | mriedem | the only driver that reports allocations in the compute is the ironic driver | |
| 21:14:29 | mriedem | requires_allocation_refresh = True | |
| 21:14:29 | mriedem | # migration has been completed. | |
| 21:14:29 | mriedem | # TODO(johngarbutt) we should remove this once the resource class | |
| 21:14:47 | mriedem | what's our signal that the resource class migration has been completed? | |
| 21:15:05 | dansmith | time and I think it's passed now | |
| 21:15:27 | mriedem | we do have a nova-status check for the ironic instance embedded flavor migration | |
| 21:15:33 | mriedem | and the online data migration | |
| 21:15:35 | mriedem | online/offline | |
| 21:15:55 | mriedem | # baremetal node class in an atomic, singular unit. | |
| 21:15:55 | mriedem | # and DISK_GB resource classes in early Queens when Ironic nodes will | |
| 21:15:55 | mriedem | # TODO(jaypipes): Completely remove the reporting of VCPU, MEMORY_MB, | |
| 21:15:55 | mriedem | and | |
| 21:15:55 | mriedem | # *always* return the custom resource class that represents the | |
| 21:16:32 | mriedem | so we could dump all of that now, or wait until early stein | |
| 21:16:49 | mriedem | i'd like to start dropping compat code that's hung around since newton/ocata times | |
| 21:17:21 | mriedem | jroll: penick: do you guys have your ironic/nova deployment fully migrated to using resource classes? | |
| 21:17:39 | jroll | mriedem: I did that patch already: https://review.openstack.org/#/c/565841/ | |
| 21:17:44 | jroll | just haven't taken the time to rebase | |
| 21:17:58 | jroll | we're still on juno, so... no. but will do in ocata afaik | |
| 21:18:16 | mriedem | the bm cloud is juno and the vm cloud is ocata? | |
| 21:18:25 | jroll | yeah | |
| 21:18:36 | jroll | still working on ocata for bm | |
| 21:18:42 | mriedem | ok, | |
| 21:18:55 | mriedem | would be nice to know people have rolled bm deployments through this transition and there aren't any major issues | |
| 21:18:59 | mriedem | before we drop all of that code | |
| 21:19:44 | mriedem | everyone seems to want an 18-24+ month window of support on transition code... | |
| 21:20:06 | jroll | TheJulia or dtantsur|afk might have people that have been through that | |
| 21:20:20 | mriedem | cern has bm and they are on queens now, | |
| 21:20:39 | mriedem | tssurya: do you know if the cern baremetal deployment has gone through the custom resource class transition for ironic flavors? | |
| 21:21:18 | tssurya | mriedem: yes | |
| 21:21:31 | jroll | \o/ | |
| 21:22:20 | jroll | mriedem: I can get back to 565841 next week maybe, or someone can take it over if they want | |
| 21:22:42 | tssurya | meaning we use resource classes for ironic flavors (reading the convo to find out what transition) | |
| 21:23:21 | jroll | tssurya: there's an online data migration for existing instances | |
| 21:23:23 | edmondsw | mriedem I think your changes in https://review.openstack.org/#/c/528835/ are related to a bug I just opened... take a look when you get a chance? https://bugs.launchpad.net/nova/+bug/1781286 | |
| 21:23:25 | openstack | Launchpad bug 1781286 in OpenStack Compute (nova) "CantStartEngineError in cell conductor during rebuild" [Undecided,New] | |
| 21:23:40 | TheJulia | jroll: mriedem: I'm sure some folks have in our org... That being said unless it is a stated policy I've noticed people upstream tend to try and push the envelope... and downstream seems to pay for it... I guess I'm just rambling that long, but not too long is preferable to short windows | |
| 21:24:18 | jroll | TheJulia: dropping it now would be two cycles | |
| 21:25:07 | mriedem | TheJulia: downstream consumers would have upstream maintain everything forever if possible | |
| 21:25:09 | TheJulia | to support skip-leveling, two would be necessary, right now most people seem to be focused on fast forwarding since that is essentially what we end up testing | |
| 21:25:22 | TheJulia | mriedem: :( | |
| 21:25:30 | TheJulia | mriedem: I do not disagree | |
| 21:25:36 | mriedem | one release is necessary for FFU | |
| 21:25:39 | mriedem | there is no skip level | |
| 21:25:58 | jroll | oh there is skip level :P | |
| 21:26:05 | mriedem | FFU means rolling through each release, not going directly from ocata to queens | |
| 21:26:13 | TheJulia | jroll: heh | |
| 21:26:14 | mriedem | sure, there is, but it's totally undefined | |
| 21:26:19 | mriedem | and therefore impossible to support | |
| 21:26:28 | jroll | right | |
| 21:26:52 | jroll | and having to deal with online data migrations gone missing in skip level is already an issue | |
| 21:27:02 | mriedem | given we're close to the end of rocky, i don't know if we just punt until early stein for the big drop or do it now | |
| 21:27:24 | TheJulia | Anyway folks, I'm going to go like... enjoy... the big blue room. | |
| 21:27:33 | jroll | at any rate, there's a patch up that needs rebasing, I'm fine either way | |
| 21:27:34 | mriedem | we might as well just wait | |
| 21:27:35 | TheJulia | +1 to punting | |
| 21:28:01 | jroll | mmmkay | |
| 21:28:53 | TheJulia | lol | |
| 21:32:31 | openstackgerrit | Merged openstack/nova master: Add queued for delete to instance_mappings table. https://review.openstack.org/566788 | |
| 21:32:47 | openstackgerrit | Merged openstack/nova master: Fix TypeError in prep_resize allocation cleanup https://review.openstack.org/581548 | |
| 21:32:52 | mriedem | jroll: ok added to https://etherpad.openstack.org/p/nova-ptg-stein | |
| 21:33:00 | openstackgerrit | Merged openstack/nova master: Add functional regressions tests for server_group_members OverQuota https://review.openstack.org/580755 | |
| 21:33:07 | openstackgerrit | Merged openstack/nova master: Fix server_group_members quota check https://review.openstack.org/580684 | |
| 21:33:56 | mriedem | i have no idea what the big blue room is | |
| 21:34:25 | mriedem | oh i see, the cool way to say go outside | |
| 21:37:29 | mriedem | edmondsw: "The nova_cell1.conf does have [database]connection set:" - that's not the db we're failing on | |
| 21:37:43 | mriedem | edmondsw: build requests are in the api db, which devstack won't configure for n-cond-cell1 | |
| 21:37:51 | mriedem | since the cell shouldn't be able to reach the api db | |
| 21:38:07 | mriedem | edmondsw: if you have a recreate, | |
| 21:38:24 | mriedem | can you add a debug line to dump filter_properties? | |
| 21:38:25 | edmondsw | yeah, I thought it might be the api db from a comment in your other change | |
| 21:38:26 | mriedem | 'retry', {}).get('num_attempts', 1) | |
| 21:38:26 | mriedem | num_attempts = filter_properties.get( | |
| 21:38:26 | mriedem | because | |
| 21:38:36 | edmondsw | otp right now, will check back in a min | |
| 21:38:43 | mriedem | is it a rolm phone? | |