| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-30 | |||
| 17:51:55 | bauzas | shit, forgot the dep | |
| 17:52:01 | openstackgerrit | David Medberry proposed openstack/nova: Explain how allow_resize_to_same_host is useful https://review.openstack.org/426531 | |
| 17:54:13 | dansmith | artom: okay, no +1s on that from the API folks | |
| 17:54:30 | mriedem | dansmith: api folks are pretty much all out right now | |
| 17:54:33 | mriedem | either holiday or tz | |
| 17:54:36 | artom | dansmith, Chinese new year I think | |
| 17:54:52 | openstackgerrit | Sylvain Bauza proposed openstack/nova: Add prelude section for Ocata https://review.openstack.org/426864 | |
| 17:54:52 | openstackgerrit | Sylvain Bauza proposed openstack/nova: WIP: Collected release notes for Ocata CellsV2 https://review.openstack.org/424737 | |
| 17:54:56 | mriedem | mdbooth: how would you feel about writing up something in the nova devref about the image cache? | |
| 17:55:05 | mriedem | mdbooth: b/c as far as i can tell, that's not really documented anywhere | |
| 17:55:16 | dansmith | mriedem: ugh, okay | |
| 17:55:33 | artom | dansmith, though gmann should be around, and he said he'd look at the new patchset | |
| 17:55:44 | dansmith | mriedem: are you gonna review/+2 that? I usually get those guys to look before I hit stuff like that | |
| 17:55:45 | dansmith | artom: okay | |
| 17:55:46 | mriedem | it should be pretty straightforward though, i just haven't gotten to it yet since i was reviewing the spec first | |
| 17:55:49 | dansmith | should we wait for him to +1? | |
| 17:55:50 | dansmith | okay | |
| 17:55:52 | mriedem | dansmith: yes it's on the list | |
| 17:55:57 | mriedem | gmann won't be around until tonight | |
| 17:56:12 | dansmith | mriedem: well, I'll wait for you, but I've gone through it | |
| 17:56:20 | artom | At least they weeded out the obvious stuff in a first pass, hopefully it's been adresses like they wanted :S | |
| 17:56:25 | artom | *addressed | |
| 17:58:12 | artom | And at this point, what's another microversion if we mess up again :D | |
| 18:07:58 | ekhugen- | question on the cells patch that just went in https://review.openstack.org/#/c/319379/84 the test in api.py of cells.enable sounds like it's a check between cells v1 and cells v2, but isn't that option for cells enabled at all? If cells is disabled, it goes down the schedule_and_build_instances path and eventually gets caught in that there's no host-to-cell mapping, right? | |
| 18:09:54 | dansmith | ekhugen-: cells.enabled is cellsv1 only | |
| 18:10:09 | dansmith | ekhugen-: cellsv2 has no "enable" flag as it's always "on" | |
| 18:11:01 | ekhugen- | dansmith so there's no choice for "no cells (v1 or v2) at all" anymore, right? | |
| 18:11:15 | dansmith | ekhugen-: it's complicated (tm) | |
| 18:11:44 | dansmith | ekhugen-: there is no turning cellsv2 on or off, and if you have cellsv1 you still have cellsv2 enabled, but inside your existing cellsv1 cells | |
| 18:11:46 | dansmith | for now | |
| 18:11:59 | dansmith | eventually there will be a migration path out for cellsv1 users to remove the extra layer | |
| 18:12:28 | mriedem | dansmith: reviewed https://review.openstack.org/#/c/426826/ | |
| 18:13:17 | mriedem | we only test n-1 computes but do we have anything anywhere that says we don't support n-2? | |
| 18:13:59 | mriedem | i.e. the assertion here https://review.openstack.org/#/c/423392/2/nova/virt/libvirt/imagecache.py@a137 | |
| 18:15:51 | dansmith | mriedem: it's always been the rule | |
| 18:16:01 | mriedem | dansmith: is that documenteD? | |
| 18:16:09 | mriedem | sans the big D | |
| 18:16:52 | dansmith | probably in the upgrades devref somewhere, I can go look in a sec | |
| 18:17:12 | sdague | mriedem: the upgrades tag for the TC defines things that way | |
| 18:17:55 | ekhugen- | thanks dansmith | |
| 18:17:55 | sdague | that's probably the most definitive answer from an OpenStack wide perspective - https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html | |
| 18:18:06 | dansmith | mriedem: thanks for those notes, I'll hit it again in a sec | |
| 18:18:08 | mriedem | http://docs.openstack.org/developer/nova/upgrade.html just mentions n and n+1, nothing about no n-2 | |
| 18:18:08 | openstackgerrit | Jay Pipes proposed openstack/nova: placement: RT now adds proper Ironic inventory https://review.openstack.org/404472 | |
| 18:18:16 | dansmith | mriedem: I'm refreshing the cells reno now | |
| 18:18:53 | jaypipes | jroll, JayF, mriedem, bauzas, dansmith, edleafe, johnthetubaguy, cdent: pls see latest rev above on Ironic inventory. | |
| 18:19:05 | mriedem | sdague: yeah that says config from n-1 works in n | |
| 18:19:06 | cdent | jaypipes: noted | |
| 18:19:10 | jroll | jaypipes: thanks | |
| 18:19:18 | mriedem | sdague: not sure it's really the same as what i'm thinking, but maybe it implies the same restriction | |
| 18:19:27 | sdague | mriedem: so maybe https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html should be explicit about n-1 | |
| 18:19:36 | mriedem | sdague: was mainly asking because of the assertion made here https://review.openstack.org/#/c/423392/2/nova/virt/libvirt/imagecache.py | |
| 18:20:26 | sdague | mriedem: well, I agree with service versions the code could probably enforce the n-1 instead of just hoping that's all that exists | |
| 18:21:50 | openstackgerrit | Dan Smith proposed openstack/nova: Collected release notes for Ocata CellsV2 https://review.openstack.org/424737 | |
| 18:21:58 | dansmith | sdague: no, we can't use service version for that | |
| 18:22:11 | sdague | dansmith: ok | |
| 18:22:26 | dansmith | sdague: unless we start recording which version goes with which release and just do a static check that is always having to get updated or something | |
| 18:22:41 | dansmith | it doesn't make sense for CD people either | |
| 18:23:41 | mriedem | i'm not really following. https://review.openstack.org/#/c/423392/ mentions a commit in newton. couldn't the ocata change check the service version based on when that newton commit happened to know if it's in there or not? | |
| 18:23:55 | mriedem | i.e. if you're min compute is past https://review.openstack.org/#/c/320910/ | |
| 18:24:14 | dansmith | mriedem: you can use the service version to check for specific things, sure | |
| 18:24:47 | dansmith | mriedem: using it to tell that you're adding a mitaka compute to an ocata-only deployment isn't easy | |
| 18:25:19 | mriedem | adding? | |
| 18:25:44 | dansmith | checks in ocata to see if there are mitaka-level services could be done, but with a static version that would have to be updated over time | |
| 18:25:59 | dansmith | I haven't looked at the actual patch, I'm just commenting on using it to detect N-2 | |
| 18:27:39 | mriedem | ok my point was, at the time that 2c389ccc8c266175a71a29358bec7fe219e64fe0 (the newton change referenced in the commit message) was merged, the service version was 11. so in the ocata change that depends on that newton change, i'd think you could only do the ocata thing if the minimum nova-compute service version in the deployment was > 11 | |
| 18:28:06 | dansmith | sure, that's not N-2 though right? | |
| 18:28:10 | dansmith | that's what service_version is for | |
| 18:28:16 | mriedem | right | |
| 18:28:25 | openstackgerrit | Dan Smith proposed openstack/nova: Allow scheduler to run cell host discovery periodically https://review.openstack.org/426826 | |
| 18:29:06 | mriedem | i'm confusing things. the n-2 question was really about an assumption made in that code that if we land this ocata patch, it means nothing is running n-2 mitaka code, which i'm saying we can't assume, and can figure out using service versions | |
| 18:29:29 | openstackgerrit | Chris Dent proposed openstack/nova: Add placement request id to log when GET aggregates https://review.openstack.org/426874 | |
| 18:30:06 | dansmith | okay | |
| 18:40:41 | openstack | Launchpad bug 1658877 in OpenStack Compute (nova) "live migration failed with XenServer as hypervisor" [High,In progress] - Assigned to Bob Ball (bob-ball) | |
| 18:40:41 | mriedem | pkoniszewski: ignore the earlier ping about https://bugs.launchpad.net/nova/+bug/1658877 - you didn't report that | |
| 18:40:44 | edleafe | jaypipes: reviewing now | |
| 18:40:52 | mriedem | BobBall: on ^ it's not a specific nova change that regressed this right? | |
| 18:41:04 | mriedem | BobBall: it's just that nova doesn't support xenserver 7? | |
| 18:41:33 | mriedem | i'm not sure what "1) the change in network name" means | |
| 18:52:46 | mriedem | diana_clarke: suggestion on wording in https://review.openstack.org/#/c/422171/ | |
| 18:53:13 | diana_clarke | mriedem: looking. I'm over here struggling with english wording too. | |
| 18:58:18 | diana_clarke | mriedem: oh that... yeah. I remember trying to come up with something better but was really mostly just concerned with not lying about return values. | |
| 19:08:54 | openstackgerrit | Dan Smith proposed openstack/nova: Allow scheduler to run cell host discovery periodically https://review.openstack.org/426826 | |
| 19:10:14 | zer0c00l | The _heal_instance_info_cache is just going to heal the first instance on the list, https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5881 | |
| 19:10:23 | zer0c00l | Is that the right behaviour of this method? | |
| 19:11:02 | zer0c00l | It loops through instance_uuids, picks up the healable instance and breaks out of that loop | |
| 19:11:29 | zer0c00l | which means only first healable instance will get its info cache refreshed | |
| 19:11:41 | zer0c00l | Am i missing something? | |
| 19:12:18 | dansmith | zer0c00l: the next time it runs it uses the list it made, until the list is empty, then gets a new list | |
| 19:12:21 | dansmith | i.e. one heal per cycle | |
| 19:12:54 | zer0c00l | dansmith: i see, so one heal per cycle is by design | |
| 19:13:00 | dansmith | yes | |
| 19:13:26 | zer0c00l | dansmith: we have the interval set to 1800 in our production, so for us it takes forever | |
| 19:13:38 | zer0c00l | i guess i will have to reduce that number to something sane | |
| 19:13:40 | mriedem | zer0c00l: so change your interval | |
| 19:13:43 | zer0c00l | yes | |
| 19:13:45 | zer0c00l | thanks | |
| 19:13:47 | dansmith | zer0c00l: the healing really shouldn't need to happen anyway, but yeah | |
| 19:13:48 | mriedem | default is 60 seocnds | |
| 19:13:51 | dansmith | it's supposed to be slow | |