| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-01 | |||
| 16:30:13 | mriedem | oh i know why | |
| 16:30:36 | mriedem | we're using neutron on master, but nova-net on mitaka | |
| 16:30:43 | andreykurilin | oh | |
| 16:30:48 | mriedem | yeah https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/v2/legacy/test_fixedips.py#L26 | |
| 16:30:50 | mriedem | i'll push a fix quick | |
| 16:30:53 | mriedem | good catch | |
| 16:31:07 | andreykurilin | mriedem: thanks | |
| 16:31:28 | andreykurilin | mriedem: what about making mitaka-functional job voting? | |
| 16:33:25 | mriedem | we could... | |
| 16:33:35 | mriedem | I haven't put any thought into it | |
| 16:34:25 | mriedem | bbiab | |
| 16:40:48 | dims | thorst : Anyone around to merge this PR and cut a release for pypowervm? https://github.com/powervm/pypowervm/pull/1 | |
| 16:41:20 | thorst | dims: Yeah, we're working on getting a new rev of that. It'd be pypowervm 1.0.0.4.1 to take in the new req. adreznec is working on it. | |
| 16:41:33 | dims | great thanks thorst and adreznec | |
| 16:41:42 | adreznec | dims: thorst Yep, just working on that now | |
| 16:41:43 | thorst | thx for letting us know! | |
| 16:42:58 | cfriesen | bauzas, you around? | |
| 16:43:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602 | |
| 16:43:51 | jaypipes | dansmith: finally addressed your PS5 coments ^. thanks for your patience. | |
| 16:44:36 | dansmith | jaypipes: will look in a bit | |
| 16:50:35 | bauzas | cfriesen: yup but with terrible connection | |
| 16:50:40 | bauzas | So lots of lags | |
| 16:51:23 | bauzas | cfriesen: Wazzup? | |
| 16:51:45 | cfriesen | bauzas: I think there's a bug in the handling of ignore_hosts. We set it on resize if CONF.allow_resize_to_same_host is False, then we save the RequestSpec and use the same RequestSpec on a subsequent rebuild/evacuate | |
| 16:52:31 | cfriesen | we reset force_hosts/force_nodes, but not ignore_hosts | |
| 16:53:15 | bauzas | Mmmm | |
| 16:53:39 | bauzas | Looks like a miss indeed | |
| 16:54:02 | bauzas | cfriesen : patch it up in the object helper then | |
| 16:54:19 | cfriesen | in reset_forced_destinations() ? | |
| 17:00:36 | dtp | is there a cells meeting today? | |
| 17:01:33 | bauzas | cfriesen: yup | |
| 17:01:43 | dansmith | oops | |
| 17:02:01 | bauzas | cfriesen: But I need to dig into code | |
| 17:02:29 | bauzas | Because I remember a similar issue that I fixed | |
| 17:03:12 | sneti | johnthetubaguy, can you please review this when you have time: https://review.openstack.org/#/c/396420/ | |
| 17:03:54 | johnthetubaguy | sneti: ah, yes, opened that, hopefully will get there soon | |
| 17:04:21 | sneti | thanks johnthetubaguy | |
| 17:10:22 | mriedem | sdague: i want to reuse your FakeResponse thing https://github.com/openstack/nova/blob/master/nova/tests/unit/test_identity.py#L25 | |
| 17:10:27 | mriedem | but need to adjust the nonzero | |
| 17:10:36 | mriedem | to be True for status_code < 400 | |
| 17:10:49 | mriedem | to match requests.Response https://github.com/kennethreitz/requests/blob/v2.12.5/requests/models.py#L658 | |
| 17:10:53 | mriedem | sdague: you ok with that? | |
| 17:15:37 | cfriesen | bauzas: bug 1669054 has been opened to track the issue | |
| 17:15:37 | openstack | bug 1669054 in OpenStack Compute (nova) "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Undecided,New] https://launchpad.net/bugs/1669054 | |
| 17:16:36 | sdague | mriedem: sure | |
| 17:18:18 | andymccr | what is the correct order for nova-manage (api_db/db sync & cell_v2 commands) in an upgrade? i'm running into an issue where greenfield works, but upgrades don't unless the order is slightly different | |
| 17:19:44 | andymccr | or rather - is there an order that works for both upgrades and greenfield? :) | |
| 17:20:24 | mriedem | andymccr: https://docs.openstack.org/developer/nova/cells.html#setup-of-cells-v2 | |
| 17:20:32 | mriedem | and https://docs.openstack.org/developer/nova/cells.html#step-by-step-for-common-use-cases | |
| 17:21:32 | andymccr | mriedem: those docs only cover the cell setup bits - which is working fine afaict. the issue im running into is that in greenfield i have to have done an api_db sync before i can do the cell_v2 map_cell0 - otherwise it fails because certain tables are missing in the nova_api database | |
| 17:22:05 | andymccr | but in an upgrade scenario (from a non-cell_v2 --> cell_v2 deploy, or say N->O) if i run the api_db sync before the cell exists it will bomb saying that the cell needs to exist | |
| 17:22:10 | mriedem | yes you need the api db synced to get the cell mapping model | |
| 17:22:15 | andymccr | which means that the approach for upgrades doesn't work for greenfield | |
| 17:22:19 | mriedem | map_cell0 creates a cell_mappings record in the nova_api db | |
| 17:22:35 | andymccr | so then should api_db sync fail if cell0 doesn't exist yet? | |
| 17:22:37 | mriedem | andymccr: tripleo? | |
| 17:22:42 | andymccr | mriedem: OpenStack-Ansible | |
| 17:22:49 | andymccr | although im sure the tripleo ppl have already figured this one out :P | |
| 17:22:50 | mriedem | do you already have flavors created? | |
| 17:23:02 | mriedem | yes owalsh hit the same thing | |
| 17:23:05 | mriedem | in tripleo | |
| 17:23:14 | mriedem | and we relaxed something in the api db schema migration | |
| 17:23:17 | andymccr | mriedem: in testing, no - in practice yes | |
| 17:23:47 | cfriesen | bauzas: I don't think changing reset_forced_destinations() is sufficient by itself given how we handle ignore_hosts in ConductorManager.rebuild_instance(). | |
| 17:24:20 | mriedem | andymccr: assuming you have this change? https://github.com/openstack/nova/commit/f781409f366904362b36bb8047fc371c17301c5e | |
| 17:24:52 | melwitt | I thought upgrade scenario meant not a greenfield? | |
| 17:25:26 | mriedem | yeah i'm confused | |
| 17:25:27 | melwitt | like, you're upgrading a deployment that already has a api db with a schema in it | |
| 17:25:36 | mriedem | if you've synced the api db in newton, you have the cell mappings table and can run map_cell0 | |
| 17:25:44 | mriedem | to create an entry in the cell_mappings table in the nova_api db | |
| 17:26:06 | andymccr | mriedem: melwitt: sure but the issue is the process is then diff for greenfield vs upgrade, which means i need to have 2 code paths to manage 1 thing | |
| 17:26:13 | mriedem | if it's a completely fresh install, the api db schema migration checks for that by seeing if you have created flavors yet | |
| 17:26:16 | andymccr | e.g. in greenfield i do api_db sync --> cell_create --> the other things | |
| 17:26:27 | andymccr | and in upgrade im going to have to do cell_create --> api_db sync --> the other things | |
| 17:26:27 | owalsh | andymccr: yes, we had to re-order the db sync for upgrades in tripleo | |
| 17:26:38 | andymccr | owalsh: so do you do different ordering for upgrade vs greenfield? | |
| 17:27:11 | digvijay2016 | how to restrict the nova service from changing hostname of created instance ? | |
| 17:27:58 | melwitt | I see. I think maybe you could have the same process for both if you have potentially an extra sync in there. I'd have to think about it more | |
| 17:28:05 | mriedem | andymccr: to be clear, on the newton side the api db is already all synced up yes? | |
| 17:28:08 | mriedem | before upgrading to ocata | |
| 17:28:09 | melwitt | mriedem: does it hurt to do a sync twice? I guess it could | |
| 17:28:14 | andymccr | mriedem: yes | |
| 17:28:15 | mriedem | melwitt: no | |
| 17:28:21 | mriedem | melwitt: db sync is idempotent | |
| 17:28:31 | mriedem | if you're already at the latest version, it's a noop | |
| 17:28:41 | mriedem | there is a migrations table created in the db that tracks the version you're synced to | |
| 17:28:51 | mriedem | i.e. you can do something like nova-manage db sync --version | |
| 17:29:07 | melwitt | okay, so maybe it could be api_db sync --> cell_create --> api_db sync --> other things for both? | |
| 17:29:14 | andymccr | is there anyway we could get the rc for nova-manage api db_sync to be something that isn't 1 if it fails because the cell doesnt exist? | |
| 17:29:34 | mriedem | melwitt: that's how it works for grenade https://github.com/openstack-dev/grenade/blob/stable/ocata/projects/60_nova/from-newton/upgrade-nova | |
| 17:29:44 | owalsh | melwitt: no, can't run api_db sync for upgrades until the end | |
| 17:29:59 | andymccr | ^ yeah the issue is in upgrade you cant run the api_db sync unless the cell exists | |
| 17:30:04 | mriedem | newton is all done, then in grenade we create the cell0 db, map_cell0, run simple_cell_setup to create the main cell and host mappings | |
| 17:30:08 | andymccr | but in greenfield you cant run the cell unless api_db has been run | |
| 17:30:29 | owalsh | andymccr: this is the tripleo upgrade (ansible) tasks https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/nova-api.yaml#L225 | |
| 17:30:43 | melwitt | I guess I don't understand why you can't run it twice | |
| 17:30:49 | mriedem | andymccr: no, the whole point of the blocker migration is to make sure you've setup cells before starting ocata services | |
| 17:31:07 | mriedem | melwitt: yeah i also don't see how this is working in grenade but not for anything else | |
| 17:32:08 | andymccr | mriedem: so is there a status command we can check that could be a decider around "hey you haven't run api_db sync yet so you need to before cell create" | |
| 17:32:52 | andymccr | mriedem: i imagine its working in grenade because you arent using the same path for upgrade vs greenfield - to me it seems silly to have to carry a separate "upgrade" play and it also means we have to determine whether you are upgrading or not - which is tricky. ideally it will just get you to the correct state | |