Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-07
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
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
15:42:46 bauwser mriedem: it's in master and stable/ocata
15:42:53 mriedem yeah i see now
15:42:59 mriedem thought you pulled one over on me
15:43:16 mriedem always like it when you red hat kids are doing customer bug duty on a friday
15:43:47 bauwser mriedem: see my reviewstats for the last 3 days, and you'll guess it's not only friday :(
15:44:21 mriedem i see #16 here http://stackalytics.com/report/contribution/nova/30
15:44:27 mriedem are you trying to impress me :P
15:44:59 mriedem we need these https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata+topic:bug/1678326
15:45:04 mriedem those are the regression backports for ocata
15:45:11 bauwser humpf http://russellbryant.net/openstack-stats/nova-reviewers-30.txt tells me 70-ish
15:45:14 mriedem and then i'll do an ocata release
15:45:33 mriedem ^ probably includes specs
15:45:55 bauwser oh, the stackalytics one doesn't ?
15:46:03 mriedem nope
15:46:05 mriedem this does i think http://stackalytics.com/report/contribution/nova-group/30
15:46:06 bauwser ah ok
15:46:12 mriedem nova-group is multiple nova projects
15:46:17 mriedem i'd have to see what's actually in there though
15:47:21 bauwser mmm, interesting, just looking over my stats for like a while ago
15:49:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle new hosts for updating instance info in scheduler https://review.openstack.org/454426
16:31:09 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add capabilities into the compute API https://review.openstack.org/454792
16:31:32 johnthetubaguy tonyb: I had a quick go at kicking this off, as I hadn't seen anything go up: ^
17:09:53 samarendra what does the nova.conf on the controller actually do if it isn't also an hypervisor ?
17:10:23 mriedem samarendra: different options are used by different services
17:10:30 samarendra it doesn't seem like it configures the api according to it because i am able to have and use different capabilities on the hypervisor than what is on the hypervisor
17:11:19 samarendra i have disk_cachemodes different on my compute node and controller and the compute node options take precedence when spinning up the vm
17:12:05 mriedem that's because disk_cachemodes is only read from the nova-compute service
17:12:23 samarendra mriedem: ok
17:12:39 samarendra so i can remove the option completely from controller ?
17:12:42 mriedem yes
17:12:50 samarendra ok.
17:13:40 samarendra mriedem: also on the same note, is there actually a detailed doc (apart from code :)) telling how disk_cachemodes can be configured?
17:13:49 samarendra last i saw in the doc it was a bit confusing
17:14:26 mriedem besides https://docs.openstack.org/developer/nova/sample_config.html you mean?
17:14:46 samarendra mriedem: yes
17:15:08 samarendra it talks of only file and block
17:15:17 mriedem there has been a multi-release effort underway to provide better help text to all of the config options, but unfortunately it looks like one hasn't been done yet
17:15:40 samarendra ok i just found another one on https://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure-nova.html
17:16:34 samarendra mriedem: ok. i will try and contribute something on that front from our experience
17:16:40 mriedem thanks

Earlier   Later