| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-07 | |||
| 12:36:59 | mriedem | but all weighers are loaded and run automatically i believe | |
| 12:37:34 | bauzas | holy fuck, how can I pdb nova-manage commands ? | |
| 12:37:46 | bauzas | looks like my raw_input is crapped | |
| 12:38:17 | bauzas | I just wanna know which kind of string we're getting from the conf object | |
| 12:38:32 | bauzas | in a py2 world | |
| 12:38:42 | bauzas | unless someone can answer this ^ | |
| 12:39:58 | mriedem | raise Exception | |
| 12:40:06 | mriedem | debug like a pro | |
| 12:41:31 | sfinucan | https://sd.keepcalm-o-matic.co.uk/i/keep-calm-and-printf-debugging.png | |
| 12:42:34 | bauzas | please no | |
| 12:43:29 | artom | If that fails because stdout gets lost somwhere, open a temp file and write to it | |
| 12:44:12 | bauzas | mriedem: do you have a pattern ? I can raise some exception, but that's not helping me | |
| 12:44:41 | artom | Well damn, looks like my idea is actually useful :D | |
| 12:44:55 | sfinucan | mriedem: RE: what happens with the PCIWeigher if you don't have NUMATopologyFilter enabled? | |
| 12:45:47 | sfinucan | mriedem: It should work the exact same. The PCI-wanting instances will fail to schedule (because that filter is disabled) and the PCI-hating instances will get the hosts with the least free PCI devices | |
| 12:47:01 | sfinucan | I'm not sure if you'd need to note that the NUMATopologyFilter must be enabled because you'd never even get to the weighting stage without it | |
| 12:47:38 | sfinucan | ...so it's a bit like noting that you must have OpenStack deployed :) | |
| 12:51:19 | bauzas | nvm, found where we unset the output stream | |
| 12:54:10 | sean-k-mooney | mriedem: regarding https://review.openstack.org/#/c/441183/15/nova/network/model.py@87 i dont have a problem with the current name given that it is already used in there nuetron plugin. in future it would be good to consider amending as you suggested but for pike i think its fine as is. | |
| 12:54:30 | sean-k-mooney | mriedem: ill review the latest version of the patch fully now | |
| 12:58:39 | sean-k-mooney | mriedem: yes looking at https://review.openstack.org/#/c/441183/17 i think its in a good state now | |
| 13:00:32 | alex_xu | nova api meeting is running at #openstack-meeting-4 | |
| 13:03:41 | mriedem | sfinucan: fair enough | |
| 13:03:46 | alex_xu | sdague: mriedem the spec for quota-classes bug fix is waiting for feedkback https://review.openstack.org/468619 | |
| 13:04:48 | mriedem | sfinucan: ok so i think if we can fix the typo in the config option and link to https://docs.openstack.org/developer/nova/filter_scheduler.html i'll be ok | |
| 13:05:12 | mriedem | alex_xu: ok | |
| 13:05:44 | stvnoyes | mriedem: I'm working on not using bdm to store the old attachment_id. I think I can add this info to migrate_data.old_attachments as a dict ({bdm_id: old_attachment_id} during pre-migrate, and I don't think it ever needs to be persisted (it would not be in Migrate object). Do you know if there's a reason it needs to be persisted in the db? or will this be ok? | |
| 13:07:53 | alex_xu | dansmith: mriedem can we change the field type like this https://review.openstack.org/#/c/430608/24/nova/objects/migration.py@56, I remember the review guide said we can't change the field type | |
| 13:07:53 | mriedem | stvnoyes: stashing it in the MigrateData object is probably good enough if that works for us | |
| 13:09:45 | stvnoyes | ok cool... what's the reason for persisting that Migration object in the db. Some kind of migration recovery if the control node goes down? that seems challenging. | |
| 13:10:09 | mriedem | stvnoyes: for one thing to list active migrations out of the REST API | |
| 13:10:40 | stvnoyes | mriedem: ah ok that makes sense. | |
| 13:10:47 | mriedem | alex_xu: we've done it before https://github.com/openstack/nova/commit/c37af848ceb7bd0509a8839fb6bc89af8d3a3c5b | |
| 13:11:45 | alex_xu | mriedem: ah..I see now | |
| 13:12:00 | mriedem | stvnoyes: but it's also used for things like resize where there are multiple operations, i.e. (1) and then (2) confirm/reject resize | |
| 13:12:06 | mriedem | (1) resize | |
| 13:12:38 | stvnoyes | got it, thx | |
| 13:12:51 | mriedem | stvnoyes: LiveMigrateData is the right place for temporary data that's only needed during a live migration, | |
| 13:13:05 | mriedem | so if we don't to ever get that information after the live migration, we should be ok | |
| 13:13:15 | mriedem | *don't need | |
| 13:13:51 | stvnoyes | it should be ok for this case, the old attach ids are not relevant after the migration | |
| 13:19:15 | dansmith | alex_xu: if it's entirely compatible with what we have, then we can | |
| 13:19:28 | dansmith | alex_xu: not sure how I feel about that status enum change, but I'll take a look | |
| 13:20:27 | alex_xu | dansmith: thanks | |
| 13:20:33 | mriedem | alex_xu: dansmith: at some point i should go over those again too, because in an earlier revision on that series i reviewed i was worried about the migration status enums being biased toward being able to abort a cold migration | |
| 13:20:47 | mriedem | it all seemed very tightly coupled to the api | |
| 13:21:27 | mriedem | https://review.openstack.org/#/c/430608/18/nova/objects/fields.py@1055 | |
| 13:22:38 | openstackgerrit | Merged openstack/nova master: Remove cells topic configuration option https://review.openstack.org/463218 | |
| 13:23:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add PCIWeigher https://review.openstack.org/379524 | |
| 13:23:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Prefer non-PCI host nodes for non-PCI instances https://review.openstack.org/379625 | |
| 13:23:18 | mriedem | given we have 20 different migration statuses and 4 different types of migration, getting this all right is a mess | |
| 13:23:38 | alex_xu | mriedem: I remember we said the reverting and confirming didn't have actualy data copy, and it can't be abort, so we didn't count those status as in-progress | |
| 13:23:40 | mriedem | plus when it's baked into the api it's going to be even more of a mess if we screw it up, because contracts | |
| 13:24:04 | mriedem | alex_xu: i think what's considered an "in-progress" migration shouldn't be coupled to what you can or can't abort | |
| 13:24:11 | mriedem | that's a higher-level whitelist in the API imo | |
| 13:24:27 | mriedem | so there might be 10 different in-progress states for a resize, but you can only abort 5 of those | |
| 13:24:30 | alex_xu | mriedem: oh, i probably get your point | |
| 13:24:47 | mriedem | the object layer should report the real in-progress states, the api should control which you can operate on | |
| 13:25:13 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Deactivate powervm compute until ready https://review.openstack.org/471773 | |
| 13:25:58 | alex_xu | mriedem: but we list in-progress migrations from the object layer, it still couple together? | |
| 13:27:36 | alex_xu | mriedem: oh, you mean in-progress and abort-able is different set | |
| 13:32:52 | mriedem | correct | |
| 13:33:08 | mriedem | i would prefer to not couple those | |
| 13:37:01 | alex_xu | mriedem: yea, agree with that, and I feel this patch fix a bug also https://review.openstack.org/#/c/459483/11/nova/compute/api.py@4030 | |
| 13:44:14 | mriedem | alex_xu: ok i went through https://review.openstack.org/#/c/468619/ | |
| 13:44:26 | mriedem | just some small things to fix | |
| 13:47:05 | mriedem | alex_xu: also replied in https://review.openstack.org/#/c/459483/11/nova/compute/api.py@4030 - it's confusing but i don't think it's a bug fix | |
| 13:59:30 | alex_xu | mriedem: replied | |
| 14:00:57 | alex_xu | sdague: for https://review.openstack.org/#/c/468619/, I want to hear from you whether we should fix it for legacy v2 API. I didn't remember we discuss what we should do for legacy v2, just want to ensure we consider that case. | |
| 14:01:37 | sdague | alex_xu: ok, I'm not going to have enough bw to comment usefully for a couple of days on that | |
| 14:02:24 | sdague | alex_xu: while you are still active though, https://review.openstack.org/#/c/468356/ is the last global_request_id call from nova | |
| 14:03:16 | alex_xu | sdague: ok, no problem, no rush for that fix, we have enough time | |
| 14:04:12 | alex_xu | sdague: will try review that after few mins | |
| 14:09:30 | bauzas | dansmith: melwitt: quick bugfix needing a +W https://review.openstack.org/#/c/471487/3 | |
| 14:09:39 | bauzas | I'll backport it to stables | |
| 14:09:56 | kashyap | sdague: I haven't run DevStack in a little while, do you have a minimal DevStack (Nova, Keystone, Glance and Neutron) config handy somewhere? | |
| 14:10:21 | kashyap | sdague: I'm asking as certain things have changed - like using systemd as opposed to `screen`, etc. | |
| 14:11:14 | sdague | kashyap: that should be the out of the box | |
| 14:11:33 | sdague | specify the 4 passwords, and you are fine (it will prompt you for them otherwise) | |
| 14:11:43 | bauzas | kashyap: unless you defined USE_SCREEN=yes, the config is not changed | |
| 14:12:06 | bauzas | kashyap: so you can take even a very old one | |
| 14:12:19 | kashyap | sdague: Noted. But I care about certain things like these - https://kashyapc.fedorapeople.org/virt/openstack/Minimal-DevStack-local.conf | |
| 14:12:38 | kashyap | And disable services (e.g. n-ec2) that I don't want | |
| 14:12:46 | kashyap | bauzas: Ah, noted. | |
| 14:12:48 | sdague | kashyap: n-ec2 isn't a thing any more | |
| 14:12:55 | bauzas | kashyap: and n-net too | |
| 14:13:03 | kashyap | bauzas: Yep, aware of the n-net; | |
| 14:13:06 | sdague | kashyap: honestly, I would delete all that | |
| 14:13:11 | bauzas | but yours is Neutron | |
| 14:13:11 | sdague | my minimal config is | |
| 14:13:17 | sdague | [[local|localrc]] | |
| 14:13:17 | sdague | ADMIN_PASSWORD=pass | |
| 14:13:17 | sdague | DATABASE_PASSWORD=pass | |
| 14:13:17 | sdague | RABBIT_PASSWORD=pass | |
| 14:13:19 | sdague | SERVICE_PASSWORD=pass | |
| 14:13:38 | sdague | all those networking things should not be required for working neutron anymore | |
| 14:14:10 | kashyap | sdague: Can you run this quick command -- `ps_mem` -- from inside the DevStack VM for me, and post the output somewhere? | |
| 14:14:22 | dansmith | bauzas: done | |
| 14:14:30 | sdague | kashyap: I'm not on a vm, I've got a real machine | |
| 14:14:37 | sdague | and ps_mem doesn't seem to be a command here | |