| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 14:41:46 | nicodemus_ | hello | |
| 14:41:46 | mriedem | we do | |
| 14:41:48 | bauwser | it's passed in the Spec AFAIK | |
| 14:41:54 | mriedem | see ^ | |
| 14:42:48 | bauwser | oh fuck, I thought you were talking of the Affinity filters verifying the group | |
| 14:42:50 | nicodemus_ | how can I modify the OS-EXT-SRV-ATTR properties on an instance? I've migrated five instances but had to do a rollback on the DB, and although the instances are in the new host the attributes show the old host... | |
| 14:43:09 | bauwser | mriedem: ServerGroup is an API DB thing ? | |
| 14:43:16 | bauwser | I didn't recall that | |
| 14:43:19 | mriedem | bauwser: yes | |
| 14:43:36 | bauwser | a-ha then sorry, s/3/4 indeed | |
| 14:43:52 | bauwser | but | |
| 14:43:56 | mriedem | nicodemus_: what does rollback on the db mean? | |
| 14:44:07 | bauwser | the 4th upcall is because we know it's racy | |
| 14:44:15 | mriedem | nicodemus_: and which specific field? | |
| 14:44:39 | bauwser | I do wonder if claims in the scheduler could help that race | |
| 14:44:51 | mriedem | bauwser: yes that's the idea for the workaround | |
| 14:44:59 | mriedem | is it's temporary until we have claims in the scheduler | |
| 14:45:02 | mriedem | per my understanding | |
| 14:45:04 | nicodemus_ | mriedem, two DB nodes went down and the remaining node didn't update the migration. The attributes I'd like to change are OS-EXT-SRV-ATTR:host and OS-EXT-SRV-ATTR:hypervisor_hostname | |
| 14:45:05 | mriedem | and the commit message | |
| 14:45:17 | bauwser | mriedem: well, the race still exists even if claims | |
| 14:45:41 | mriedem | nicodemus_: you can see here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extended_server_attributes.py#L34 that hypervisor_hostname comes from the instances.node column | |
| 14:45:51 | mriedem | and host comes from instances.host | |
| 14:46:41 | nicodemus_ | mriedem, great! Thanks :) | |
| 14:46:42 | melwitt | jbernard: hey, I was wondering if you had made any progress on throttling down the concurrency of the ceph job (described on L142 in https://etherpad.openstack.org/p/nova-ptg-pike) | |
| 14:47:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add description to policies in server_password.py https://review.openstack.org/452259 | |
| 14:50:03 | bauwser | mriedem: dansmith: I'm confused by the help message of https://review.openstack.org/#/c/442736/21/nova/conf/workarounds.py | |
| 14:50:18 | bauwser | mriedem: dansmith: do we plan to allow upcalls by default ? | |
| 14:50:35 | bauwser | the same would go for reschedules | |
| 14:50:38 | dansmith | bauwser: we can't have upcalls if you have isolated your mq, so you have to disable that in that case | |
| 14:50:54 | bauwser | ie. we could switch the MQ by default unless the operator wanted isolation | |
| 14:51:01 | bauwser | dansmith: of course | |
| 14:51:20 | bauwser | dansmith: I mean, do we plan to do the MQ switch by default and leave a conf opt for that ? | |
| 14:51:37 | dansmith | bauwser: I dunno what you mean by "do the MQ switch" | |
| 14:51:40 | bauwser | if so, would it make sense to have a single opt like "mq_isolated" ? | |
| 14:52:20 | bauwser | dansmith: I mean, in the compute node, if a reschedule is required, do call super conductor by switching the MQ connection string | |
| 14:52:38 | dansmith | bauwser: we can't switch the mq string as we have no idea what it is or should be | |
| 14:52:39 | dansmith | IMHO, | |
| 14:52:46 | dansmith | we should be moving completely to no upcalls, | |
| 14:53:04 | dansmith | but until we have claims and some other stuff like affinity in placement, we'll lose features if we just cut them off right now | |
| 14:53:09 | dansmith | which is why it is a workaround | |
| 14:53:13 | bauwser | dansmith: that's my point | |
| 14:53:21 | dansmith | and no, I don't have to have a catch-all "is isolated" config, | |
| 14:53:24 | bauwser | dansmith: I'm unclear on the reschedule case | |
| 14:53:28 | dansmith | because fixing each thing will be separate | |
| 14:54:24 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in security_groups.py https://review.openstack.org/452309 | |
| 14:54:29 | bauwser | dansmith: ie. what happens in a v2 world where currently computes do conductor_api.do_this() for a reschedule ? | |
| 14:55:23 | mriedem | in a single cell you have a single conductor and reschedules are fine, i believe | |
| 14:55:30 | dansmith | right, | |
| 14:55:41 | dansmith | and we don't have multi-cell capability until my series merges | |
| 14:55:44 | dansmith | so if we get all that in, | |
| 14:55:54 | dansmith | we still have that caveat on reschedules | |
| 14:56:05 | dansmith | and we said we'd discuss in boston and decide what to do with feedback | |
| 14:56:08 | bauwser | that's my point, I'm past cells-aware | |
| 14:56:14 | bauwser | okay | |
| 14:56:32 | bauwser | sorry if I'm unclear, I'm not talking of the choice we would make | |
| 14:57:05 | mriedem | dansmith: we don't yet have a patch in your series that breaks reschedules do we? | |
| 14:57:12 | bauwser | I'm rather talking on whether it's technically possible for a message to be send to a queue (ie. if the API MQ is in the context or not) | |
| 14:57:18 | mriedem | i mean, that's a deployment option isn't it? | |
| 14:57:22 | dansmith | mriedem: right | |
| 14:57:25 | mriedem | ok | |
| 15:00:44 | liuyulong | hi there, https://review.openstack.org/#/c/375221/ and https://review.openstack.org/#/c/379128/ need some great reviewers, thanks. : ) | |
| 15:05:47 | mriedem | dansmith: https://awwapp.com/b/urxhemxkr/ | |
| 15:05:50 | mriedem | can you see that? | |
| 15:06:21 | dansmith | mriedem: I see a child's drawing | |
| 15:06:34 | mriedem | ha | |
| 15:06:43 | mriedem | so in multi-cell, | |
| 15:06:53 | mriedem | the super conductor casts to the cell compute to build right? | |
| 15:07:01 | dansmith | yup | |
| 15:08:11 | mriedem | and compute talks to cell conductor just for db? | |
| 15:08:58 | mriedem | i'm a bit fuzzy on what the cell conductor does | |
| 15:09:09 | dansmith | well, resizes and stuff hit the super conductor because of the scheduler requirement, so.. yeah that might be it | |
| 15:10:10 | mriedem | ok | |
| 15:10:25 | mriedem | this thing doesn't provide a box shape unfortunately | |
| 15:10:31 | mriedem | or a circle | |
| 15:13:11 | stefan_amann | mriedem we were working on supporting FICON / ECKD devices, in addition to FCP. But then paused the work because we did not have a CI ready. And there were dependencies to os-brick. We would like to release the support with Pike. The specless blueprint is in 'pending approval' state. Can you change this to allow us go forward? I would very much appreciate... | |
| 15:13:48 | mriedem | stefan_amann: link? | |
| 15:14:01 | mriedem | i also don't know what any of those devices are | |
| 15:14:04 | stefan_amann | https://blueprints.launchpad.net/nova/+spec/linux-ficon-support | |
| 15:14:04 | mriedem | or acronyms | |
| 15:14:58 | mriedem | stefan_amann: https://review.openstack.org/#/c/320536/ is abandoned | |
| 15:15:09 | mriedem | i marked the nova blueprint as blocked because it's dependent on the os-brick changes | |
| 15:15:12 | stefan_amann | FICON is a storage protocol, similar to FCP. Just that in case of FCP, different command blocks are transferred over Fibre-Channel. FICON is the standard protocol used on z Systems mainframes | |
| 15:16:00 | mriedem | https://review.openstack.org/#/c/342921/ is also very old | |
| 15:17:12 | mriedem | stefan_amann: i've re-approved the nova bp but left it in blocked state | |
| 15:17:36 | mriedem | maybe the approved status gets your manager to let you work on it :) | |
| 15:17:50 | stefan_amann | :-) | |
| 15:18:48 | stefan_amann | thank you! So if e will soon release the os-brick changes you will remove the 'blocked' state? | |
| 15:19:24 | stefan_amann | mriedem :-) thank you! So if e will soon release the os-brick changes you will remove the 'blocked' state? | |
| 15:19:52 | mriedem | well, | |
| 15:20:11 | mriedem | the os-brick change is going to depend on the cinder change, so i don't expect any of that happening soon for an os-brick release | |
| 15:20:18 | mriedem | but yeah once the os-brick stuff is in a better state let me know | |
| 15:20:34 | stefan_amann | mriedem ok... thanks much! | |
| 15:21:06 | mriedem | yw | |
| 15:22:47 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/453896 | |
| 15:34:38 | bauwser | mriedem: quick q before I leave (soonish), do you think https://review.openstack.org/#/c/454593/ could be a reasonable backport for a phase-II cycle ? :) | |
| 15:34:57 | bauwser | I know it's not a security bugfix, neither a critical one | |
| 15:35:27 | bauwser | but I think it could be worth it for operators wanting to ping-pong their migrations | |
| 15:35:29 | mriedem | so newton? | |
| 15:35:32 | bauwser | yup | |