Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-08
10:22:27 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migrate from 'ip' commands to 'pyroute2' https://review.openstack.org/484386
10:48:49 openstackgerrit chenpengzi proposed openstack/nova master: For a pre-generated example of the latest policy.yaml https://review.openstack.org/531713
11:10:27 openstackgerrit chenpengzi proposed openstack/nova master: For a pre-generated example of the latest policy.yaml https://review.openstack.org/531713
11:41:28 openstackgerrit chenpengzi proposed openstack/nova master: Add reference to policy sample https://review.openstack.org/531713
11:45:56 openstackgerrit Jianle He proposed openstack/nova-specs master: Back up volume-backed-instance https://review.openstack.org/530214
12:09:26 gibi bauzas: left some questions / nits in https://review.openstack.org/#/c/514763/ Merry Christmas! ;)
12:14:09 openstackgerrit Merged openstack/nova master: Remove 'nova-manage host' and 'nova-manage agent' https://review.openstack.org/521837
12:20:12 ameeda bauzas: can you please review my code here https://review.openstack.org/#/c/526900/
12:45:37 hrw stephenfin: https://review.openstack.org/#/c/530965/ got +1 from zuul, has test coverage. can you +2 again?
12:47:01 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/531737
12:47:52 ameeda Hello
12:48:10 ameeda FutureWarning: fake is an invalid UUID. Using UUIDFields with invalid UUIDs is no longer supported, and will be removed in a future release. Please update your code to input valid UUIDs or accept ValueErrors for invalid UUIDs. See https://docs.openstack.org/oslo.versionedobjects/latest/reference/fields.html#oslo_versionedobjects.fields.UUIDField for further details
12:48:10 ameeda I got this error when I run tox -e py27
12:48:23 ameeda any idea ?
12:49:27 sean-k-mooney ameeda: when using oslo versioned objects the validator for uuid fields check that the value is really a uuid. fake is not a uuid hence the error
12:49:44 sean-k-mooney ameeda: is that from https://review.openstack.org/#/c/526900
12:51:51 ameeda sean-k-mooney: thanks for reply, no its from this https://review.openstack.org/#/c/528385/ when I move my code to _cleanup_volumes and modify the unit test for that
12:53:40 ameeda sean-k-mooney: here is my edit http://paste.openstack.org/show/640858/
12:53:41 sean-k-mooney oh ok you can use uuidgen on the commandline to generate a uuid for the tests for example e21d0851-3c56-4b9d-a133-a2c1ba59778a whcich you can use instead of fake to resolve the warning
12:54:49 ameeda sean-k-mooney: so I should use this uuid inside my code ? since the error appears in another file
12:56:03 sean-k-mooney only if its cause by your code. if the warning is present without your patch you dont need to fix it.
12:56:09 ktibi Hi, do you think it's good if nova doesn't check if neutron have free IP before spawn instance ?
12:57:02 ktibi because I have a strange case where user spawn 200 vms with 50 free IP, and all my compute become disabled with "consecutive_build_service_disable_threshold"
12:57:46 sean-k-mooney ameeda: oslo versioned objects uuid filed not emit this warning if invalid uuids are used but at present its only a warning to allow projects to fix there tests. in the future it will be changed to an error but only once most project have updated there tests
12:58:55 ameeda sean-k-mooney: when I remove my code, the test success completely, and the error appears at another file where I add my code
12:59:53 sean-k-mooney ktibi: strictly speaking nova has no requirement that a vm will have an ip. it just requires that vms have mac adressses.
13:00:11 ameeda sean-k-mooney: if I do this http://paste.openstack.org/show/640870/ it will success ?
13:00:48 sean-k-mooney ameeda: i would guess that uuids.instance on line 6 of http://paste.openstack.org/show/640858/ is the root of the warning
13:02:03 sean-k-mooney ameeda: try using e21d0851-3c56-4b9d-a133-a2c1ba59778a instead and see if it resolves the issue
13:02:33 ameeda sean-k-mooney: thanks alot, I will try that and let you know
13:03:08 ameeda sean-k-mooney: I have another issue with openstack overcloud image build in dib, can you help me with that ?
13:04:00 sean-k-mooney ktibi: regarding your issue i dont think the compute nodes should become disabled just because a user ran our of ips in there subnet. was there any error reported in the n-cpu or n-sch logs?
13:04:12 ktibi sean-k-mooney so, with the default value for consecutive_build_service_disable_threshold, any user can disable all compute ?
13:06:05 sean-k-mooney ktibi: interesting looks like that is a new option in pike https://review.openstack.org/#/c/463597/
13:06:57 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Fix possible TypeError in VIF.fixed_ips https://review.openstack.org/531745
13:06:58 sean-k-mooney ktibi: it is intended to disable a compute node if there is an issue with the hypervisor like libvirt crashed or something like that. this would seam to be an edgecase
13:07:25 ktibi compute node fail to spawn instance with error ==>Failed to allocate the network(s), not rescheduling
13:07:38 bauzas gibi: thanks for the review, will upload a new change in 1 hour-ish
13:08:13 ktibi sean-k-mooney user spawn 200 instances, so I have 20 fail on each compute, all my compte become disable !! very dangerous !!
13:08:14 sean-k-mooney ktibi: as a work around you can set the config value to 0 to disable auto disable.
13:08:21 ktibi I think this option need to be disable by default
13:09:53 sean-k-mooney ktibi: i actully tend to agree that this probably should not be enabled by default. that said i understand why you might want this
13:10:50 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ocata: Fix possible TypeError in VIF.fixed_ips https://review.openstack.org/531746
13:11:42 ameeda sean-k-mooney: same error after change instance.uuids to e21d0851-3c56-4b9d-a133-a2c1ba59778a . see the error here http://paste.openstack.org/show/640881/
13:12:37 sean-k-mooney stephenfin regarding https://review.openstack.org/#/c/463597/6 do you recall why consecutive_build_service_disable_threshold is not disabled by default.
13:22:10 sean-k-mooney ameeda: so it looke like the varning changed form fake is an invalid UUID to fake_vol so im guessing the volume id is not set in the bdms object
13:22:20 sean-k-mooney ameeda: you are extending https://github.com/openstack/nova/blob/master/nova/tests/unit/compute/test_compute_mgr.py#L278-L304
13:25:22 ameeda sean-k-mooney: I try to do this http://paste.openstack.org/show/640891/, but it show me error said that instance doesn't has get_by_uuid attribute.
13:27:49 ameeda sean-k-mooney: what you guess me to do ? if I remove my changes, everything working fine
13:30:02 ameeda sean-k-mooney: when I do this http://paste.openstack.org/show/640894/ "note line 5" that will work fine.
13:30:26 sean-k-mooney ameeda: am i have to run to a meeting sorry.
13:30:43 ameeda sean-k-mooney: no worries. thanks for your time :)
13:31:12 stephenfin sean-k-mooney: If I recall correctly, it's something to do with lack of upcall support with a cells v2 deployment
13:31:54 stephenfin or because it happened often enough to warrant enabling that feature by default
13:32:00 stephenfin I don't really recall, tbh :/
13:41:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459
13:41:01 ygl sean-k-mooney: hi, I need some help on nova
13:41:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297
13:42:31 ygl stephenfin: hi, i need some help on nova
13:47:03 ktibi stephenfin sean-k-mooney I guess we have two solutions : 1/ disable by default this features 2/ change the detection which inscrease the trigger by detect only fail or error which does not concern quota or free IP
13:48:01 stephenfin ktibi: IMO, you'd be better waiting for dansmith and/or mriedem to pop up in an hour or two. I don't think you're the first person to have issues with this
13:48:12 ktibi because for now, I can disable all compute on a fresh install !! with a simple user. Create a network with 20 IP and spawn 90 instances !
13:50:50 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: create vGPU for instance https://review.openstack.org/528832
13:50:50 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: Provide VGPU inventory for a single GPU type https://review.openstack.org/514763
13:50:51 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt : Force a specificly static UUID for a mediated device https://review.openstack.org/531752
13:53:59 hrw stephenfin: hello ;)
13:56:36 efried Scheduler meeting in 4 minutes in #openstack-meeting-alt
13:57:15 bauzas damn, needs coffee then
14:55:46 openstackgerrit Merged openstack/nova master: Add index on token_hash and instance_uuid for console_auth_tokens https://review.openstack.org/531477
15:01:13 efried cdent Yes, if update_provider_tree comes back with a provider removed, that means report client needs to delete that provider.
15:01:29 cdent efried, jaypipes it would be great if we could do some of this discussion in email, so the results end up somewhere digestible. but if that's no good, we can carry on here (I'm in cafe land again, so don't want to hang out, now, but could another time)
15:02:42 cdent doesn't it mean instead that it is not used in this context? If we're including sharing providers in the ProviderTree, is there weirdness? I don't know, it's hard to think about in the abstract, and without whiteboards etc
15:03:23 mriedem yikun: https://review.openstack.org/#/c/531633/ looks ok once some nits are addressed and you can squash it into https://review.openstack.org/#/c/330406/
15:04:46 efried cdent Yeah, that's a place we'll have to tread carefully. If a virt decides it's no longer going to be associated with a sharing provider, it should remove itself from that aggregate... but should it also remove that provider?
15:05:03 jaypipes efried: if the provider is gone, then yeah.
15:05:23 jaypipes efried: but if the virt driver doesn't *own* that provider, then no.
15:05:33 jaypipes efried: I think this is highly dependent on the virt driver.
15:05:35 efried jaypipes What does "own" mean?
15:05:57 jaypipes efried: in the case of vCenter and PowerVM, the virt driver "owns" these shared pools of resources, right? so the virt driver can delete them.
15:05:59 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
15:06:25 efried jaypipes But how does the driver know it's the last one associated with the sharing provider?
15:06:26 jaypipes efried: but for libvirt, it doesn't own any sharing providers. something else does and therefore it shouldn't delete sharing providers.
15:06:37 jaypipes efried: that's up to you, baby.
15:06:38 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
15:06:50 efried jaypipes Without talking to placement...
15:07:02 jaypipes efried: powervm and vcenter, being virt drivers for clustered resource nodes, are going to have to handle that on their own.
15:07:17 jaypipes efried: zookeeper maybe? I don't know :)
15:07:45 cdent of just talk to the local third party agent which is talking to placement anyway, even though nova want "let" them
15:07:52 cdent s/want/won't/
15:08:22 mriedem vcenter is no longer a clustered thing right? and powervm never was
15:08:34 mriedem ironic is our only 1:M virt driver
15:08:35 efried mriedem Clustered shared storage pool
15:08:39 mriedem oh
15:08:51 efried The quintessential shared provider case.
15:09:18 openstackgerrit Claudiu Belu proposed openstack/nova master: hyper-v: autospec classes before they are instantiated https://review.openstack.org/342211
15:09:18 mriedem how would that not also affect libvirt?
15:09:26 mriedem if you're using NFS or Ceph for local disk/
15:09:27 mriedem ?
15:10:29 efried mriedem I think because those guys are going to manage the shared provider from some other control point.
15:10:44 cdent mriedem: indeed. the assumption has been that "something else" is managing in that context, but I'm not sure we've really thought it all the way through

Earlier   Later