| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-03 | |||
| 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, | |
| 20:31:18 | mriedem | and i know this isn't voting right now, | |
| 20:31:50 | mriedem | but right now, devs have a reasonable shot at making changes in devstack to get things through nova that depend on devstack, but that learning curve gets higher if they have to touch devestack-gate or project-config or grenade, | |
| 20:32:02 | mriedem | adding this means to get things in nova done, they now have to learn a whole new set of tools, | |
| 20:32:08 | mriedem | i for one don't know puppet or ruby | |
| 20:32:35 | mriedem | i've learned to monkey my way through devstack and it's bashtasticness over the last 4 years that i'm able to sort of know what i'm doing, | |
| 20:32:39 | mriedem | until sdague hits me and tells me i'm wrong | |
| 20:32:55 | EmilienM | I don't think we asked Nova team to learn about TripleO or did we? | |
| 20:33:05 | EmilienM | what we ask is to tell us when that job is failing | |
| 20:33:16 | EmilienM | because we think it can provide useful feedback | |
| 20:33:17 | mriedem | no, but if we have changes that require deployment tooling changes to move forward, we can do that in devstack today | |
| 20:33:28 | mriedem | yeah i mean there will be a lot of hand-holding at the least | |
| 20:34:04 | mriedem | and it opens a door for the horde of other deployment projects (kolla, ansible, whatever else since fuel/chef/salt are dead i think) | |
| 20:34:14 | superdan | mriedem: are you cool with getting some stuff like this into rc2? https://review.openstack.org/#/c/428824/ | |
| 20:34:17 | superdan | or do you want to hold off | |
| 20:34:24 | superdan | we could backport too, but I think it should be in the ocata packages | |
| 20:34:35 | mriedem | superdan: i think docs are fine | |
| 20:34:44 | superdan | okay, agree | |
| 20:35:59 | mriedem | EmilienM: anyway you asked so those are the considerations, and which is why i'm not jumping on this right away | |
| 20:36:07 | mriedem | plus it's been a hectic week and i'm getting burned out | |
| 20:37:29 | EmilienM | mriedem: ok, let's talk about it next time you have free cycles. | |
| 21:05:45 | cmartin | Hey quick question about the upcoming PTG in Atlanta, roughly what time will the conference hours be? particularly on friday? I am trying to book my flight home after the conference ends on friday but am unsure what times I can select for the flight | |
| 21:06:19 | mriedem | i assume things start at 9am? | |
| 21:06:22 | mriedem | dhellmann: ^? | |