Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-07
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 mriedem or acronyms
15:14:04 stefan_amann https://blueprints.launchpad.net/nova/+spec/linux-ficon-support
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
15:35:42 bauwser the fix itself is not really intrusive
15:36:07 bauwser in general, I'd -1 such things, but I think the benefits go over the risk
15:36:20 dansmith yeah
15:36:31 mriedem seems fine to me
15:36:32 dansmith super tiny and it's a really stupid problem to have
15:37:06 dansmith "ownership" in the commit message -> security -> fine.. right? :)
15:37:08 mriedem +2 for you
15:38:52 bauwser mriedem: dansmith: thanks to both of you
15:39:23 mriedem you can pay me back by reviewing some stable/ocata backports
15:39:46 mriedem oh wait jesus
15:39:47 mriedem https://review.openstack.org/#/c/454593/
15:39:58 mriedem is that in ocata?
15:40:11 mriedem oh it is
15:40:13 mriedem ok whew
15:40:18 mriedem i thought that was master for some reason

Earlier   Later