| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-12 | |||
| 16:25:24 | sean-k-mooney | yes but to reset if its an old source node it wont create the binding but we could do that in do_migrate on the destination. | |
| 16:25:39 | mriedem | pre_live_migration runs on the dest host and i think that's where the dest host port binding was going to be created, but i'm not sure | |
| 16:25:42 | sean-k-mooney | if you have a new source node and old destination there is no way to update the xml | |
| 16:26:01 | mriedem | ok so we create the dest host port binding from the source node? | |
| 16:26:48 | mriedem | live_migrate runs on the source node, calls pre_live_migration on the dest node, and then live_migrate on the source starts doing it's thing | |
| 16:26:54 | sean-k-mooney | mriedem: ill duble check i have been confusing myself with this most of the afternoon so kindo of mixed up what happens where | |
| 16:27:02 | mriedem | use https://docs.openstack.org/nova/latest/reference/live-migration.html | |
| 16:28:29 | kashyap | kaisers: When you're back; glad you noted the correction in the bug: "1) correction regarding my last comment (#6): block commit -> blockRebase" | |
| 16:28:37 | kashyap | kaisers: They're both completely opposite. | |
| 16:29:32 | sean-k-mooney | right ok ill work on the spec and use https://docs.openstack.org/nova/latest/reference/live-migration.html to keep it straight | |
| 16:31:39 | sean-k-mooney | mriedem: basically what i wanted to know was is it ok to change the sematic in the event that we need an xml update but cant do one and fail the migrate instead of migrating and haveing broken networkin that is then fixed with a hard reboot | |
| 16:32:21 | mriedem | sean-k-mooney: it seems to me we shouldn't be allowing that today anyway | |
| 16:32:25 | mriedem | so yes i'd be ok with that | |
| 16:33:27 | sean-k-mooney | ok ill capture that in the spec with the different combinations. thanks | |
| 16:35:07 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Remove barbican from scope of ksa adapter work https://review.openstack.org/511524 | |
| 16:35:10 | efried | sdague FYI, crickets in -barbican | |
| 16:35:23 | efried | sdague mriedem ^ updated spec accordingly. | |
| 17:02:37 | openstackgerrit | Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 17:06:00 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 17:17:53 | openstackgerrit | Merged openstack/nova master: api-ref: add warning about force evacuate for ironic https://review.openstack.org/511477 | |
| 17:42:21 | openstackgerrit | melanie witt proposed openstack/nova stable/pike: Fix target_cell usage for scatter_gather_cells https://review.openstack.org/511538 | |
| 17:54:38 | mriedem | dansmith: on this migrations API paging spec https://review.openstack.org/#/c/506030/ i don't think we need to do the elaborate scatter/gather thing like you did for instance listing probably, with the built in merge sorting and all | |
| 17:55:07 | dansmith | mriedem: migrations are per instance right? | |
| 17:55:11 | mriedem | we could build in the scatter/gather on it's own if we wanted, but it seems we could just merge sort the results once we pull them out of the db, the user can't pass in sort keys and this is admin-only anyway so performance shouldn't be a huge concern | |
| 17:55:12 | dansmith | if so, there's no scattering | |
| 17:56:02 | mriedem | not sure i follow, | |
| 17:56:13 | mriedem | couldn't we use the scatter/gather thing on this today? https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3995 | |
| 17:56:29 | dansmith | mriedem: you list migrations for an instance, right? | |
| 17:56:29 | mriedem | it would just run the db query concurrently per cell and munge the results | |
| 17:56:37 | mriedem | not this api | |
| 17:56:46 | mriedem | this is all migrations regardless of instance | |
| 17:56:49 | dansmith | oh | |
| 17:57:14 | dansmith | don't we have one that is per instance? | |
| 17:57:17 | mriedem | we do | |
| 17:57:24 | dansmith | *awesome* | |
| 17:57:33 | mriedem | but paging that one would be more like paging simple tenant usage i think, | |
| 17:57:36 | mriedem | which was weird | |
| 17:57:46 | dansmith | anyway, | |
| 17:58:46 | dansmith | I would think just doing linear paging for that would be fine yeah | |
| 17:58:49 | dansmith | until someone complains | |
| 17:59:41 | mriedem | yup cool | |
| 18:00:01 | mriedem | only cburgess would have that many migration records to page anyway | |
| 18:00:07 | cburgess | Do what? | |
| 18:00:21 | mriedem | migrating like a mofo | |
| 18:00:24 | cburgess | yes | |
| 18:00:26 | cburgess | yes we do.. | |
| 18:00:28 | cburgess | *sigh* | |
| 18:00:39 | mriedem | well then do we have the spec for you! https://review.openstack.org/#/c/506030/ | |
| 18:10:02 | _ix | Hello friends. I can think of a way to do this, but I was hoping there might be a better way. I'm looking to determine whether some of our nodes that are believed to be running in an HA capacity are in fact running on the same hypervisors. | |
| 18:10:35 | _ix | Is there a way to determine from the guest VM which hypervisor host it's running on, at instantiation or otherwise? | |
| 18:12:03 | dansmith | _ix: you can do this from the nova api | |
| 18:13:04 | _ix | I'm familiar with that approach, but I was hoping to register a custom fact with puppet, and instead just used puppetdb to keep an eye on the status of these nodes. | |
| 18:14:35 | _ix | I would suspect that the guest never needs to know who its host is. | |
| 18:15:25 | dansmith | or shouldn't | |
| 18:15:41 | dansmith | I don't know that we expose the sanitized host id or not | |
| 18:15:44 | dansmith | in metadata I mean | |
| 18:15:50 | dansmith | I kinda expect not, but I'd have to look | |
| 18:16:22 | mriedem | i looked, didn't see it | |
| 18:34:57 | mriedem | we should be able to remove the safe_connect decorator now can't we? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L56 | |
| 18:35:04 | mriedem | that was for the newton->ocata transition | |
| 18:35:12 | mriedem | placement is definitely required at this point and a hard failure if it's not there | |
| 18:35:39 | mriedem | and in ocata nova-compute doesn't start either if placement isn't configured for the compute node | |
| 18:37:44 | dansmith | it's also confusing, | |
| 18:37:48 | dansmith | because 404 -> None | |
| 18:37:50 | dansmith | instead of explody | |
| 18:43:09 | mriedem | yeah that's what made me think of it, per gibi's comment in your change | |
| 18:43:24 | dansmith | yeah I just saw that | |
| 18:44:01 | mriedem | shall i patchify the removification? | |
| 18:44:56 | dansmith | if and as you wishitifcate | |
| 18:48:57 | edleafe | dansmith: question on serializing: for returning the list of lists of Selection objects over RPC, will they be automagically primitivized? Or do they need to be manually converted? | |
| 18:49:22 | dansmith | edleafe: should be automatic | |
| 18:49:30 | edleafe | dansmith: thx | |
| 18:49:35 | dansmith | edleafe: because of the NovaObjectSerializer we pass to rpc setup | |
| 18:57:53 | melwitt | couple of easy reviews if anyone can look https://review.openstack.org/#/c/509968 and https://review.openstack.org/#/c/510823 | |
| 18:59:02 | melwitt | gibi might be interested in the first one ^ | |
| 19:06:58 | mriedem | done and done | |
| 19:08:58 | melwitt | thx mriedem | |
| 19:52:14 | openstackgerrit | Merged openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077 | |
| 20:31:42 | openstackgerrit | Merged openstack/nova master: Elevate existing RequestContext to get bandwidth usage https://review.openstack.org/509968 | |
| 20:32:22 | openstackgerrit | Merged openstack/nova master: Make expected notifications output easier to read in tests https://review.openstack.org/510823 | |
| 20:59:12 | mriedem | nova tastic meeting in 1 minute | |
| 20:59:32 | melwitt | be there or be a rhombus | |
| 21:05:04 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239 | |
| 21:05:04 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add alternate hosts https://review.openstack.org/486215 | |
| 21:05:05 | openstackgerrit | Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/510159 | |
| 21:05:05 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854 | |
| 21:05:06 | openstackgerrit | Ed Leafe proposed openstack/nova master: WIP - Make conductor pass and use host_lists https://review.openstack.org/511358 | |
| 21:05:06 | openstackgerrit | Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357 | |
| 21:27:26 | openstackgerrit | Merged openstack/nova master: Nix bug msg from ConfGroupForServiceTypeNotFound https://review.openstack.org/511261 | |
| 21:29:53 | efried | woot. 5 rechecks. | |
| 21:35:11 | takashin | mriedem: Would you take a look at https://review.openstack.org/#/c/334732/ ? I fixed response codes in the spec. | |
| 21:36:47 | mriedem | takashin: i'll add it to my list | |
| 21:37:26 | takashin | mriedem: Thank you. | |
| 21:38:04 | mriedem | takashin: btw, you might be interested in this https://review.openstack.org/#/c/511351/ | |
| 21:38:14 | mriedem | really anything related to migration status i'm going to send your way now | |
| 21:39:32 | takashin | mriedem: okay. I will check it. | |
| 21:47:13 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Spec for flavor description https://review.openstack.org/501017 | |
| 21:48:55 | sapd_ | Hi everybody! | |
| 21:50:56 | sapd_ | I'm upgrade from openstack ocata to pike version. But I had an error when I use admin to list all server in all tenants | |
| 21:51:10 | sapd_ | The error is: TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction | |