Posted	Nick	Remark
#openstack-nova - 2017-03-28
15:28:41	sfinucan	jaypipes: Okidok
15:28:57	dansmith	mdbooth: but you still connect via iscsi to that thing on the actual compute, yes?
15:28:58	kashyap	mdbooth: I had to at least ensure this boolean is set `setsebool -P virt_use_nfs on`
15:29:02	mdbooth	I'm guessing (no, really) that it's picked up an SELinux label which allows A to read it
15:29:09	mdbooth	dansmith: Nope, it gets mounted on the host
15:29:23	dansmith	mdbooth: ...really?
15:29:54	dansmith	I guess I've only used non-fs cinder drivers
15:30:01	mdbooth	dansmith: You can review my patch, btw: https://review.openstack.org/#/c/383859/ ?
15:30:02	mdbooth	;)
15:30:13	mdbooth	It does lots of mounty type things
15:30:14	dansmith	but I thought cinder-volume would just export via iscsi like it does for, say, lvm
15:30:27	dansmith	apparently I can't
15:31:22	mdbooth	I just reviewed this for the quobyte driver, which is very similar: https://review.openstack.org/#/c/428646/
15:31:34	mdbooth	They want to disable xattrs for performance reasons
15:32:06	mdbooth	Set me thinking about SELinux and shared filesystems in general
15:35:52	johnthetubaguy	mdbooth: you can't mount the same nfs share twice in two different locations then? I guess thats fairly stupid though
15:36:32	johnthetubaguy	mdbooth: the more I think about multi-attach, the more I kinda want an option for a set of read-only attachments to a volume snapshot as an explicit (simpler) special case
15:37:01	mdbooth	johnthetubaguy: You can, but **IIUC** the labelling on the individual file includes a MCS label specific to a particular domain(instance)
15:37:19	mdbooth	There *must* be a solution to this, though
15:37:36	mdbooth	It will definitely have come up before in libvirt
15:40:30	johnthetubaguy	mdbooth: yeah, i guess it should be possible, without re-labelling, presumably
15:40:41	mdbooth	https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Shared_storage_and_virtualization-Using_iSCSI_for_storing_virtual_disk_images.html
15:40:48	mdbooth	Ah, that's RHEL 5
15:40:59	mdbooth	That says no labelling on NFS, but that didn't sound right to me
16:34:05	openstackgerrit	Maxim Nestratov proposed openstack/nova master: libvirt: change images cache and backend lock path https://review.openstack.org/450879
17:10:33	openstackgerrit	Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992
17:24:08	openstackgerrit	dane-fichter proposed openstack/nova master: Use cursive for signature verification https://review.openstack.org/351232
17:26:04	efried	Is there a channel for openstackclient?
17:31:17	efried	Or... How do I create a VM with no network? Used to be I could say --nick none (which the usage statement & help claim is fine) - but that's now telling me "nics must be a list".
17:33:27	swebster	efried: somebody asked this in #openstack yesterday, and the answer was #openstack-sdks
17:33:39	efried	swebster Thanks!
17:34:48	luos	hi, i'd like to develop a filter scheduler for nova, what's the best method to get nova as a dependency? i mean i'd like to run some unit tests without actually installing the whole openstack
17:35:13	siva_krishnan	mdbooth, pkoniszewski can you please review this patch https://review.openstack.org/#/c/434870/ which fixes network interuption during post copy based on libvirt events
17:35:24	efried	luos requirements.txt?
17:35:35	efried	Assuming you're using tox/testr
17:36:43	luos	can you point me to the package? cause i could't find one where the actual nova scheduler api classes are in
17:37:29	luos	or you mean just point it to github? i did a quick search now and saw it's possible
17:43:11	luos	thanks efried,seems to be working
17:43:27	efried	luos Good deal ;-)
17:47:31	dansmith	is anyone else seeing this functional-py35 test fail?
17:53:35	efried	dansmith Allll over the place.
17:53:46	dansmith	efried: yeah?
17:53:51	efried	Seems to have gotten resolved some time last night, though.
17:54:03	efried	Yesterday there was a pretty serious rash.
17:54:08	dansmith	I just rechecked and I think I'm getting it again
17:54:17	efried	boo. Link?
17:55:15	dansmith	http://logs.openstack.org/25/438025/32/check/gate-nova-tox-functional-py35-ubuntu-xenial/9d28a16/testr_results.html.gz
17:55:22	dansmith	it's different than the one I saw yesterday,m
17:55:28	dansmith	but also in api_samples
17:55:48	dansmith	although the server groups one looks similar
17:56:12	dansmith	I've been in a hole for a while, have a pointer to what was being resolved?
17:57:08	efried	dansmith No, I didn't follow it that closely, just did some rechecks and walked away whistling when I saw green...
17:57:21	dansmith	hmm, okay
17:57:28	efried	But maybe I can resurrect a link to a failed one so we can see if it's the same.
17:57:34	efried	I wanna say mine wasn't even getting that far, though.
17:57:47	dansmith	this is the one from yesterday: http://logs.openstack.org/25/438025/32/check/gate-nova-tox-functional-py35-ubuntu-xenial/a773f20/testr_results.html.gz
17:58:41	efried	The ones I was seeing yesterday were actually in gate-nova-python35
17:58:53	efried	So - never mind \o/
17:59:01	dansmith	oh those are devstack on py35 right?
17:59:30	efried	Dunno about devstack. Example: http://logs.openstack.org/04/409404/19/check/gate-nova-python35/f8976ec/
17:59:34	efried	Didn't even run any tests.
18:00:26	dansmith	ah, unit tests
18:00:27	dansmith	hmm
18:01:11	dansmith	well, I have to upgrade locally before I can run py35 tests so I guess I'll do that
18:01:57	efried	Actually, that one is still failing, same way. So now I'm worried again.
18:06:26	efried	mriedem I'm getting the error "nics must be a list" when attempting to do openstack server create with --nic none. It looks like you added _validate_create_nics via https://review.openstack.org/#/c/353018/ which doesn't seem to account for 'none' (or None). Am I missing something, or can I open a bug?
18:28:22	mriedem	efried: --nic
18:28:24	mriedem	see the test https://review.openstack.org/#/c/353018/8/novaclient/tests/functional/v2/test_servers.py
18:28:35	mriedem	are you specifying the 2.37 microversion or using a client new enough to support that?
18:45:15	jaypipes	sfinucan: please see my comment/question to sahid on https://review.openstack.org/#/c/385364...
18:47:32	efried	mriedem I'm not specifying a microversion. How do I tell how old/new my client is?
18:48:01	efried	mriedem Oh, I see; I shouldn't have hit that branch if I was using 2.37+
18:48:30	efried	Does openstackclient get installed as part of devstack? Cause I *just* restacked.
18:53:37	efried	Perhaps not; but my installation appears to be from 3/10. So it's surely new enough to support. I don't know how to specify it, though.
18:59:30	efried	--os-compute-api-version 2.37 - that did the trick.
19:42:20	openstackgerrit	Samantha Blanco proposed openstack/nova master: Make flavor-rxtx policy more granular flavor-rxtx currently only has one policy it checks against, which is not restrictive enough when used in conjunction with other policies (e.g., flavor-manage). This allows users a greater degree of customization. https://review.openstack.org/444036
19:43:34	mriedem	efried: that's kind of odd because the default behavior in the CLI is to use the latest available supported version in the client if the server is new enough
19:44:07	mriedem	efried: which is 2.41 now https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L28
19:44:11	efried	mriedem I would have expected so. I checked my openrc and it wasn't specifying OS_COMPUTE_API_VERSION before.
19:44:19	mriedem	so --nic none should work automatically with latest devstack
19:44:21	melwitt	mriedem: I think he's using openstackclient, it must not do the same thing of defaulting to latest?
19:44:28	mriedem	if you're using osc, then idk
19:44:31	mriedem	all bets are off
19:44:35	melwitt	heh
19:44:58	efried	I had somehow gotten the impression that we were supposed to use osc rather than individual component CLIs. Not so?
19:44:59	mriedem	would have to ask stevemar or dtroyer,
19:45:11	mriedem	but i woudn't be surprised if osc defaults the cli to 2.1
19:45:11	melwitt	efried: if you use the novaclient 'nova boot ...' it should Just Work(tm)
19:45:26	mriedem	right the default cli behavior i was talking about was for novaclient
19:47:58	mriedem	efried: we should be using osc for cli stuff more now
19:48:02	melwitt	efried: no, I think that's right, we do say use osc for the most part but it doesn't know anything about microversions. it will work if you pass the api version the way you did, as that will get passed through to novaclient
19:48:10	mriedem	i personally haven't forced myself to do that yet
19:48:22	efried	I try to do it for the most part.
19:48:36	efried	Though I can't bring myself to say 'openstack server list' when 'nova list' will do ;-)
19:48:43	mriedem	well root beer scratch n sniff for you then
19:49:11	efried	mriedem Yup, looks like you're right about the default version: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/client.py#L26
19:49:26	efried	From what I can tell, that gets used for anything that doesn't have an explicit override in the env.
19:50:10	mriedem	makes sense
19:50:15	efried	or, duh, that file is just the compute client.
19:50:27	melwitt	I think one challenge with osc is the different client CLIs don't do the same thing by default. nova's defaults to latest but I think ironicclient defaults to base?

Earlier   Later