| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-30 | |||
| 17:01:30 | openstackgerrit | Gábor Antal proposed openstack/nova: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225 | |
| 17:02:42 | bauzas | mriedem: FYI, I'll also write a bit of explanation about cellsv2 in the prelude section | |
| 17:02:55 | mriedem | bauzas: don't do the cells v2 prelude | |
| 17:03:06 | mriedem | bauzas: unless you plan on updating this https://review.openstack.org/#/c/424737/ | |
| 17:03:13 | mriedem | ^ will be the reno for any cells v2 stuff that's missing | |
| 17:03:36 | bauzas | mriedem: the prelude section works differently from the other sections | |
| 17:03:55 | bauzas | mriedem: so I'd like to only have one change for the prelude section | |
| 17:04:01 | bauzas | because that's not bullets | |
| 17:04:08 | bauzas | I mean bullet points | |
| 17:04:58 | bauzas | mriedem: but I can do the prelude change that would be a follow-up of https://review.openstack.org/#/c/424737/8/releasenotes/notes/ocata-cellsv2-support-4b3b5e70e76bc756.yaml | |
| 17:05:09 | bauzas | so we would be sure that we don't miss them | |
| 17:05:16 | bauzas | mriedem: WFY ? | |
| 17:05:27 | mriedem | sure | |
| 17:14:20 | openstackgerrit | Jordan Pittier proposed openstack/nova: Fix unspecified bahavior on GET /servers/detail?tenant_id=X as admin https://review.openstack.org/426259 | |
| 17:16:17 | jordanP | the question remains: why do we ignore tenant_id if all_tenants=0, I can't answer to this, it's probably unspecified, undefined but it's been like this for a long long time. | |
| 17:16:20 | jordanP | I have to go | |
| 17:19:57 | mriedem | artom: comments inline https://review.openstack.org/#/c/426030/ | |
| 17:20:22 | artom | mriedem, woot! | |
| 17:20:41 | mriedem | artom: mostly ok, just some nits | |
| 17:21:10 | artom | mriedem, sweet, lemme fix those and respin | |
| 17:33:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs: Fix tag attribute disappearing https://review.openstack.org/426030 | |
| 17:37:46 | mriedem | artom: +2 | |
| 17:38:53 | openstackgerrit | Stephen Finucane proposed openstack/nova: console: Move proxies to 'console/proxy' https://review.openstack.org/408192 | |
| 17:38:54 | artom | mriedem, phast | |
| 17:40:22 | mdbooth | I didn't notice this one missed -3: https://review.openstack.org/#/c/423392/ | |
| 17:40:36 | mdbooth | It's trivial, but it needs to go in to Ocata because it's upgrade related. | |
| 17:41:15 | mdbooth | mriedem: Is there anywhere I can add stuff like ^^^ in your etherpad? | |
| 17:41:26 | mdbooth | mriedem: Or maybe somewhere else? | |
| 17:45:00 | jaypipes | mriedem: k, doing final run of tests now for the Ironic inventory patch. | |
| 17:45:11 | jaypipes | mriedem: hopefully will be pushed in <30 minutes | |
| 17:45:21 | dansmith | artom: link me to the actual fix? | |
| 17:45:41 | artom | dansmith, https://review.openstack.org/#/c/424759/ | |
| 17:51:05 | openstackgerrit | Sylvain Bauza proposed openstack/nova: Add prelude section for Ocata https://review.openstack.org/426864 | |
| 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? | |