Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-19
14:46:24 bhagyashris jaypipes: cdent: Hi
14:49:58 mriedem need a +W on this https://review.openstack.org/#/c/421482/ so oslo.serialization can get their final release in for ocata today
14:51:01 mriedem harlowja: ^ it is done
14:52:26 vladikr mriedem, could you please remove your -2 from https://review.openstack.org/#/c/405951 ? - It's all rewritten now
14:52:51 mriedem done
14:53:00 vladikr mriedem, thanks
14:53:08 mriedem vladikr: so you were able to condense that whole series into 2 changes now?
14:53:53 vladikr mriedem, looks like it. removing all the classes in the middle, there is not much left
14:54:15 openstackgerrit Eric Fried proposed openstack/nova: Introduce base PowerVM driver (disk drv) https://review.openstack.org/409401
14:57:48 bauzas sdague: got a sec for a problem related to the placement call from the scheduler ?
14:58:14 bauzas sdague: it seems we default calling the placement service from the reportclient by not using the latest microversion
14:58:16 bauzas http://logs.openstack.org/61/417961/10/check/gate-tempest-dsvm-cells-ubuntu-xenial/8a974f7/logs/screen-n-sch.txt.gz?level=TRACE#_2017-01-19_14_17_38_980
14:58:47 bauzas sdague: since cdent is on PTO today, do you know how could I add this header ?
15:00:12 bauzas sdague: I mean, in https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L172
15:00:57 mriedem bauzas: jaypipes has a patch that does that, sec
15:01:10 bauzas mriedem: oh cool
15:01:25 mriedem https://review.openstack.org/#/c/407309/13/nova/scheduler/client/report.py
15:01:32 mriedem the problem there is he's requesting 'latest',
15:01:49 mriedem we don't want the report client to request 'latest', we want a specific version that we're opting into
15:02:02 mriedem because at some point latest in pike might break an ocata client
15:02:52 bauzas mriedem: I can try to amend that patch
15:03:11 bauzas mriedem: we're having a max version for our novaclient, right?
15:03:19 mriedem bauzas: yes
15:03:27 mriedem there is a max version in novaclient for what it knows how to understand
15:03:45 bauzas yeah, I remember
15:03:48 mriedem by default the python api in novaclient always requests the minimum
15:03:49 bauzas and a min one too
15:04:16 bauzas yeah, unless you're specifically asking for another version in your resource call
15:04:23 bauzas I remember that too
15:05:28 bauzas mriedem: I could be doing that, like calling MIN_VERSION by default and just ask for 1.4 for my placement call in the scheduler
15:05:37 mriedem bauzas: looks like you can just past the headers kwarg to session.get() https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L485
15:05:49 mriedem *pass
15:06:10 bauzas yeah
15:06:12 bauzas saw that
15:06:20 mriedem the question is what if the minimum available isn't new enough for what you need?
15:06:21 bauzas but I'd prefer to have our reportclient having that
15:07:05 mriedem now that i'm thinking about this, don't people usually upgrade the api last?
15:07:05 bauzas mriedem: I think the safe_connect deco should say sorry then
15:07:21 mriedem yeah but what does that mean for the filter scheduler?
15:07:25 openstackgerrit Sam Betts proposed openstack/nova: Change order of _cleanup_deploy and _unprovision in Ironic virt https://review.openstack.org/422678
15:07:57 bauzas mriedem: it would mean that you'd have to run the Ocata placement service before upgrading nova-scheduler
15:08:10 bauzas EmilienM: ^
15:09:00 EmilienM bauzas: that kind of orchestration is not easy to do, specially when you deploy in production
15:09:09 bauzas I know
15:09:40 mriedem bauzas: but that also means upgrading nova-api to ocata doesn't it? unless you package them as separate services
15:10:52 mriedem do i need to start a ML thread to think this through?
15:10:53 bauzas mriedem: that indeed depends on how it is packed
15:10:59 bauzas mriedem: that looks important
15:11:09 bauzas and we're 1 week away from FF
15:11:13 bauzas which makes me nervous
15:11:39 mriedem well let me start a thread first and we can stew in there
15:12:33 mriedem johnthetubaguy: keep me honest about the order of upgrade, with n-api coming last
15:12:55 mriedem it seems this changes every time i talk about it, might be n-cond -> n-api -> n-cpus
15:13:05 bauzas in general yes
15:13:26 mriedem http://docs.openstack.org/developer/nova/upgrade.html
15:13:32 mriedem " It is safest to start nova-conductor first and nova-api last."
15:13:35 bauzas we did the modification with dan's change so that newton computes auto-heal once they find a placement service
15:13:47 mriedem yeah i'm not worried about n-cpu
15:13:59 bauzas but we haven't tell'm what version of placement they should expect
15:15:30 johnthetubaguy mriedem: so it coming last is kind of a new thing
15:15:40 johnthetubaguy mriedem: we used to do it first, then n-cpu last
15:16:40 johnthetubaguy mriedem: so I should be clearer, it used to say turn off all non n-cpu, turn on the new ones, then restart the new n-cpu processes
15:17:02 mriedem but we've never been clear on n-api or n-sch having an order,
15:17:04 mriedem now it would
15:17:09 mriedem depending on how things are packaged
15:17:13 mriedem although,
15:17:26 johnthetubaguy yeah, I think before we were meaning, everything off, then everything back on
15:17:36 mriedem you could roll the new code, you just don't restart n-api until the end of the control services
15:17:42 mriedem you could still restart placement
15:18:15 johnthetubaguy oh, I see what you mean now
15:18:27 johnthetubaguy if you run placement on the same as n-api
15:18:32 johnthetubaguy its going to be really late
15:18:33 bauzas of course
15:18:58 bauzas but that still means we have an hard dependency on the restart conditions between placement and scheduler
15:19:13 bauzas you have to have the placement service be upgraded before n-sch
15:19:30 johnthetubaguy oh, scheduler hard depends on a new API microversion?
15:19:35 bauzas yup
15:19:40 johnthetubaguy dang
15:19:48 jaypipes johnthetubaguy: yep, absolutely.
15:19:53 bauzas because the resources field is a 1.4 microversion
15:20:16 johnthetubaguy its almost like it would be easier if its considered a separate project, that gets upgrade before nova
15:20:22 bauzas johnthetubaguy: jaypipes: proof here http://logs.openstack.org/61/417961/10/check/gate-tempest-dsvm-cells-ubuntu-xenial/8a974f7/logs/screen-n-sch.txt.gz?level=TRACE#_2017-01-19_14_17_38_980
15:20:34 bauzas johnthetubaguy: too soon IMO
15:20:56 bauzas we're already having most of our operators trailing with deploying a placement service for ocata
15:21:01 johnthetubaguy bauzas: probably
15:21:14 bauzas we can't expect them to package and manage a totally separate service right now
15:21:25 bauzas even for pike
15:21:35 johnthetubaguy feels like we should really support N and N-1 placement
15:21:36 edleafe johnthetubaguy: separate project, eh? Now there's a novel approach!
15:21:39 edleafe :)
15:21:58 bauzas honestly, I don't want to go that way
15:22:07 bauzas we already claim to support N-1 services
15:22:13 mriedem "we can't expect them to package and manage a totally separate service right now" ?
15:22:15 mriedem really?
15:22:21 bauzas so we should support the placement service being n-1
15:22:39 mriedem placement has been available since newton, it's already out there for the packaging before upgrading to ocata,
15:22:41 mriedem so i don't see a problem there
15:23:02 bauzas mriedem: you know that most of the time, people don't care unless we break them
15:23:16 mriedem then i guess they should care?
15:23:19 mriedem lest be broken?

Earlier   Later