Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-30
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?
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?

Earlier   Later