| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-03 | |||
| 19:28:13 | sdague | EmilienM: any behavior in the nova osapi_compute_listen field is because of the way oslo.service works - https://github.com/openstack/oslo.service/blob/7fa34bf8e7a37a6d9355aaf55aa85b1931567cd6/oslo_service/wsgi.py#L127-L151 | |
| 19:28:33 | cdent | figleaf: it's all very bewildering and amazing | |
| 19:28:47 | superdan | EmilienM: no | |
| 19:28:53 | EmilienM | sdague: ok I see, thanks | |
| 19:30:05 | johnthetubaguy | cdent: I guess thats where all those fetch inventory calls come from, from the attempted update | |
| 19:30:41 | johnthetubaguy | cdent: hmm, I meant allocations | |
| 19:31:15 | cdent | I'm gonna escape for the evening unless there's something needing me? | |
| 19:31:36 | johnthetubaguy | cdent: I need to do the same really | |
| 19:31:39 | johnthetubaguy | I have the oven on | |
| 19:31:51 | figleaf | Have a great weekend, cdent and johnthetubaguy | |
| 19:33:04 | cdent | johnthetubaguy: yeah, dinner calls | |
| 19:35:43 | big_macsz | bon appetit | |
| 19:35:45 | cfriesen | mriedem: did anyone actually start on a spec for deprecating file injection? | |
| 19:36:04 | mriedem | cfriesen: no it was on my todo list at some point and then i forgot about it | |
| 19:36:10 | mriedem | i blame the holidays | |
| 19:36:23 | cfriesen | heh...so are we now looking at deprecating in pike? | |
| 19:36:31 | cfriesen | removing in q? | |
| 19:36:39 | mriedem | yeah | |
| 19:36:47 | mriedem | johnthetubaguy: it was on me | |
| 19:37:26 | cfriesen | heh...okay, I can write that one up if you like. | |
| 19:37:41 | openstackgerrit | Emilien Macchi proposed openstack/nova master: DNM - test tripleo without nova api in WSGI/apache https://review.openstack.org/429008 | |
| 19:38:23 | johnthetubaguy | figleaf: that last question I had was about the inventory, it seems odd to need to update it when updating the instances, surely thats been done already in the RT? | |
| 19:38:28 | EmilienM | mriedem: now rc1 is cut, can you look https://review.openstack.org/#/c/428424/ please? | |
| 19:42:12 | figleaf | johnthetubaguy: the only way inventory is updated there is if it doesn't match the number of allocations | |
| 19:42:47 | figleaf | johnthetubaguy: so it removes everything and rebuilds everything to the "correct" way (old and new style) | |
| 19:42:57 | johnthetubaguy | figleaf: which is for new instances too right? | |
| 19:43:16 | figleaf | johnthetubaguy: next pass through, it should find that len(cur_allocs) == len(inv_data), so it won't do that again | |
| 19:43:29 | johnthetubaguy | figleaf: but its not needed, if you look here: https://github.com/openstack/nova/blob/cab5dbfac7513d2cef1073787e49f6d063ec8fa7/nova/compute/resource_tracker.py#L575 | |
| 19:43:39 | figleaf | johnthetubaguy: well, what we might think are "new instances" is different | |
| 19:43:47 | johnthetubaguy | figleaf: we always update the inventory first | |
| 19:43:56 | figleaf | johnthetubaguy: as cdent mentioned, the tracker is cleared on every pass, so they are always "new" | |
| 19:44:15 | johnthetubaguy | yes, but thats a red herring here | |
| 19:44:29 | johnthetubaguy | I mean if you boot an instance, every time we would now re-write the inventory | |
| 19:44:37 | johnthetubaguy | (well attempt an update) | |
| 19:46:04 | figleaf | johnthetubaguy: what we need is to map this all out visually. It's all too confusing otherwise | |
| 19:46:43 | johnthetubaguy | figleaf: that probably would help | |
| 19:46:45 | figleaf | johnthetubaguy: I still trip myself up following the ironic vs. non-ironic paths | |
| 19:47:25 | johnthetubaguy | figleaf: so generally, the code updates the inventory, then updates the allocations | |
| 19:47:41 | johnthetubaguy | figleaf: I think this new code should do the same thing, rather than trying to re-update the inventory | |
| 19:47:54 | dtp | reading the release notes. do cells v1 deployments need to go through the cells v2 setup for Ocata? | |
| 19:48:17 | superdan | dtp: yes | |
| 19:48:25 | superdan | I thought it said that explicitly | |
| 19:49:01 | dtp | it does, but from discussions we had previously, i'm under the impression folks can still run v1 cells w/ the CELLS_ENABLED flag or whatever it was | |
| 19:49:02 | superdan | we've been through so many cells related renos I've lost track | |
| 19:49:12 | superdan | they can | |
| 19:49:17 | superdan | but they still have to do the cellsv2 stuff | |
| 19:49:40 | dtp | ok, including creating a cell 1? or just the cell 0? | |
| 19:49:51 | mriedem | both | |
| 19:49:54 | mriedem | dtp: also https://review.openstack.org/#/c/427981/ | |
| 19:51:02 | figleaf | johnthetubaguy: understood, but I'm not seeing where the problem is. I can only see that happening when the allocations don't match inventory for ironic | |
| 19:51:41 | johnthetubaguy | figleaf: no, its a bit different | |
| 19:52:22 | johnthetubaguy | ... trying to think of how to describe it | |
| 19:52:36 | johnthetubaguy | we have the inventory update, so it includes the new resource calss | |
| 19:52:39 | johnthetubaguy | class | |
| 19:52:40 | figleaf | johnthetubaguy: hey! how about writing a functional test! :) | |
| 19:52:46 | johnthetubaguy | we now call the update | |
| 19:52:51 | figleaf | (which is what we should have done from the outset) | |
| 19:52:53 | johnthetubaguy | figleaf: if it were not 7.50pm, sure | |
| 19:53:25 | johnthetubaguy | basically, we start with updating the inventory | |
| 19:53:37 | johnthetubaguy | then we have to check if the allocations match what should be in the inventory | |
| 19:53:49 | johnthetubaguy | thats not the case if its new, or we are hitting the upgrade bump | |
| 19:54:02 | johnthetubaguy | in that case we need to fix up the allocations, thats all good | |
| 19:54:12 | johnthetubaguy | but there is no need to update the inventory, its already been done | |
| 19:55:05 | figleaf | johnthetubaguy: so you're saying that they inventory always has to be correct? IOW, it's always the allocations that are out of whack? | |
| 19:55:30 | johnthetubaguy | I am saying the inventory is always updated before we update the allocations | |
| 19:58:16 | figleaf | johnthetubaguy: that could well be the case | |
| 19:58:36 | figleaf | johnthetubaguy: I think leakypipes must have trying the belts and braces approach | |
| 20:01:07 | figleaf | johnthetubaguy: the part I'm not clear on is where all the calls to RT._update_usage_from_instance() can be made, and whether those paths always update inventory first | |
| 20:01:34 | cfriesen | is there a writeup of the as-implemented behaviour for resource providers, or are the specs/code all there is currently? | |
| 20:03:01 | mriedem | didn't markus_z have a burndown chart somewhere for the config option cleanup work? | |
| 20:03:09 | figleaf | cfriesen: There have been several excellent posts to the ML by cdent | |
| 20:03:36 | cfriesen | figleaf: just saw his most recent one | |
| 20:04:35 | figleaf | cfriesen: but the fact that those of us working on it are still a little fuzzy about the edge cases is a good sign that we need to do something more | |
| 20:05:42 | mriedem | http://45.55.105.55:8082/config-options.html | |
| 20:14:10 | dtp | thanks mriedem superdan. left my comments on that review | |
| 20:14:22 | openstackgerrit | melanie witt proposed openstack/nova master: Add step-by-step examples for Cells V2 setup https://review.openstack.org/427981 | |
| 20:15:41 | melwitt | darn it, didn't see dtp's comments a minute ago | |
| 20:15:54 | dtp | we were very close :) | |
| 20:17:27 | mriedem | macsz: sfinucan: if you have open config option cleanup changes, move them to https://blueprints.launchpad.net/nova/+spec/centralize-config-options-pike please | |
| 20:17:55 | macsz | mriedem: i will move every single patch that is left | |
| 20:18:01 | mriedem | thanks | |
| 20:18:56 | macsz | mriedem can you re-assign me to it? | |
| 20:19:17 | mriedem | sure | |
| 20:19:22 | macsz | thanks | |
| 20:21:23 | EmilienM | mriedem: do you have a CI job that test Nova API deployed with SSL? | |
| 20:21:51 | EmilienM | I couldn't find one | |
| 20:22:05 | EmilienM | gate-grenade-dsvm-neutron-multinode-ubuntu-xenial seems to deploy non-ssl | |
| 20:22:19 | mriedem | EmilienM: dane-fichter and the john hopkins gang was working on creating a security-specific dsvm job that tests with that plus all of the other security features like signed images and using barbican as the key manager | |
| 20:22:32 | mriedem | but that's not done, and honestly i don't know the status of it right now | |
| 20:22:45 | EmilienM | ok | |
| 20:22:54 | EmilienM | because I found a bug, I'll probably report it | |
| 20:23:11 | mriedem | ok | |
| 20:25:39 | mriedem | EmilienM: so on your multinode nonha job, is that running in the same nodepool as the rest of infra or a special subset? | |
| 20:26:00 | EmilienM | mriedem: same | |
| 20:26:20 | mriedem | ok | |
| 20:26:54 | EmilienM | mriedem: I really see a value of using TripleO jobs here. We are testing SSL, IPv6, (WSGI but will be removed today), and all of that for free | |
| 20:29:31 | EmilienM | mriedem: is there something that you don't like in this idea? | |
| 20:30:03 | EmilienM | I might be wrong but I see some resistance that we didn't have with other projects | |
| 20:31:07 | mriedem | EmilienM: well i'm a bit distracted with other things right now | |
| 20:31:13 | mriedem | but also, | |