Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-11
15:05:05 kenperkins if we don't where does it come from?
15:05:08 bauzas mriedem: actually, if we need to keep the same UX as it is now, nodename is optional
15:05:19 kenperkins maybe it's baked into the image? <thinking>
15:05:36 sean-k-mooney some images have it backed in yes
15:05:56 sean-k-mooney we may always generate one but i was not expecting us too
15:06:15 artom donnyd, so, just to be clear, http://project.fortnebula.com/ is your personal project with your personal hardware, and... you're the sole sysadmin for it?
15:07:10 donnyd yep
15:07:29 kenperkins sean-k-mooney https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L581 perhaps?
15:07:56 kenperkins then here i think https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1206
15:08:09 artom donnyd, I'm worried about gate resources with a 1 person bottleneck :) For your sanity as much as cloud stability
15:08:33 donnyd artom: I am also the sole funder, maintainer, electrician, and cooling engineer
15:08:36 donnyd LOL
15:08:46 sean-k-mooney kenperkins: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.inject_password
15:09:04 sean-k-mooney kenperkins: by defualt we do not inject admin password in the vm wit libvirt
15:09:11 artom donnyd, the bus factor is *really* high with you :)
15:09:21 kenperkins where is the default libvirt config in code? :D
15:09:37 donnyd Well openstack isn't very hard, so maintenance is pretty low
15:09:42 sean-k-mooney and its a libvirt specific option so other virt dirvres proably dont do this
15:10:09 sean-k-mooney donnyd: artom just be aware that we cant have any voting jobs without at least 2 providers
15:10:17 mriedem bauzas: hypervisor_hostname *is* optional in the new microversion
15:10:20 mriedem as is host
15:10:21 artom donnyd, I'll trust you on that one - my experience has been with devstack mostly, and maintenance is definitely *not* low
15:10:28 mriedem same as it is with the zone:host:node hack
15:10:35 mriedem you can specify zone:host only, or zone::node only
15:10:38 kenperkins @sean-k-mooney thx for the pointer re: libvirt config
15:10:48 mriedem the *only* difference is in how the scheduler processes it
15:10:51 bauzas mriedem: yeah, that's what I just said
15:11:05 artom sean-k-mooney, yeah, that's fine, just having a thing in experimental that we can run as-needed is a great 1st step
15:11:09 sean-k-mooney kenperkins: https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L139 it there but we should not change it
15:11:14 sean-k-mooney in code that is
15:11:17 bauzas force_hosts supports only host, and evacuate/livemigrate do support only host too
15:11:24 sean-k-mooney kenperkins: feel free to set it in you local config
15:11:52 mriedem bauzas: force_hosts is only *hosts* because we also have the force_nodes field
15:11:59 mriedem you can also just have force_nodes
15:12:02 mriedem b/c zone::node
15:12:26 bauzas yup, and https://github.com/openstack/nova/blob/master/nova/compute/api.py#L958 allows you to only check the HostMapping
15:12:34 mriedem i don't see what evacuate and live migrate really have to do with this, you can't force those anymore on the latest microversion
15:12:47 mriedem and node doesn't really matter for those since migrations aren't supported for ironic anyway
15:12:55 mriedem evacuate might be, but who knows if it actually works
15:13:06 kenperkins ``rebuild`` process.
15:13:06 kenperkins wait, that contradicts a little bit sean-k-mooney; that link says that `False`: Allow the injection of an admin password for instance only at ``create`` and
15:13:19 kenperkins which reads like one value is only create/rebuild, the other is at any time
15:13:41 bauzas mriedem: well, we use the same internal object than livemig/evac https://review.opendev.org/#/c/645520/35/nova/compute/api.py@1056
15:13:57 mriedem bauzas: yes i know
15:13:59 mriedem and cold migrate
15:14:00 donnyd artom: Just lmk if you need anything custom, or a space to play
15:14:21 mriedem and rebuild if we'd get https://review.opendev.org/#/c/650376/ in
15:14:22 donnyd just an FYI I can only offer ipv6 access publically
15:14:30 sean-k-mooney kenperkins: the docs say "False: Disallows the injection. Any via the REST API provided admin password will be silently ignored."
15:14:32 artom donnyd, flavors with 2 NUMA nodes. This implies nested virt.
15:14:50 donnyd I don't have a bunch of ipv4 address because they cost lots of the $$$
15:14:53 sean-k-mooney kenperkins: https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L158-L159
15:15:18 donnyd I can work up anything needed
15:15:49 donnyd This gear was for a big data project I was working on, so if its just going to sit there... might as well do something fun with it
15:16:18 sean-k-mooney donnyd: the power load form ci testing can be high
15:16:53 artom donnyd, so, being blunt, is the gear availability "stable"? Or there's a chance that it'll get repurposed/offlined at some point in the future?
15:17:03 artom I realize we always have that doubt with any nodepool provider
15:17:19 artom But it seems it'll be higher with 1 dude than, say, Vexxhost
15:17:55 artom donnyd, don't get me wrong, I'm genuinely grateful that you're doing this, and frankly that no other company has stepped up before (including my own)
15:18:02 artom *and frankly angry
15:18:03 donnyd Well we started small at 10 instances, and from what I can measure (which is quite a lot) it seemed to me to be about 150W per 10 instances so about 1500W at scale
15:18:15 donnyd but we will go slow and test to see what is sustainable
15:18:18 bauzas mriedem: my only concern is that we don't replicate the same logic than in evac/rebuild/livemig and set the host field on the Destination object if not provided like in https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4627
15:18:34 bauzas that's why I can regression something like https://review.opendev.org/#/c/645520/35/nova/scheduler/host_manager.py
15:19:19 mriedem that happens in the scheduler
15:19:20 sean-k-mooney artom: well intel ran an nfv ci for 4 years
15:19:33 sean-k-mooney it should be comming back later this year
15:19:34 mriedem bauzas: see resources_from_request_spec
15:19:49 artom sean-k-mooney, past tense being the key word there ;)
15:19:50 mriedem https://review.opendev.org/#/c/645520/35/nova/scheduler/utils.py@528
15:19:54 donnyd At some point in the future sure... but it will likely be when this gear is used up completely and no longer functional
15:19:56 mriedem bauzas: you haven't been around, but ^ handles that
15:20:37 bauzas mriedem: thanks, just saw it
15:20:42 bauzas okay, I'm all good then
15:20:45 sean-k-mooney well i left and it had already been outsouce + osic happend and the lab that hosted it got decomissioned so ya.
15:22:11 BLZbubba hi guys, what is the proper way to switch the default nova acceleration from tcg to kvm?
15:22:28 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Keeping going with docs https://review.opendev.org/670332
15:22:28 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Rewrite host aggregate, availability zone docs https://review.opendev.org/667133
15:23:12 sean-k-mooney BLZbubba: set virt_type=kvm in the [libivrt] section in the nova.conf
15:23:19 sean-k-mooney then restart the compute agent
15:23:28 sean-k-mooney and hard reboot any vms on the host
15:24:22 BLZbubba thank you, i couldn't quite get the right google search terms to find that one
15:24:46 donnyd Well I am just happy I can help in whatever way I can... and it's both professionally and personally fun for me
15:25:13 sean-k-mooney BLZbubba: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.virt_type
15:25:23 donnyd LMK how I can help
15:27:37 sean-k-mooney BLZbubba: it should be defaulting to kvm by the way not the tcg backend
15:32:18 BLZbubba sean-k-mooney: this is the centos el7 version, maybe they were going for compatibility out of the box or something; who knows. the config had virt_type=qemu
15:34:11 Zara hi! I'm trying to work out why user roles would affect speed of api calls; does anyone know where docs for that area would live? (I'm having this problem: https://ask.openstack.org/en/question/123025/nova-api-calls-slow-for-non-admin-users ; asked in #openstack but no responses, so this is my last hope :) )
15:35:16 sean-k-mooney BLZbubba: its proably your installer not centos that changed it
15:35:17 mriedem stephenfin: i've dropped the -2s on the ec2 removal patches
15:35:32 stephenfin mriedem: Cheers
15:36:17 sean-k-mooney Zara: it proably resulting in addtional or more expencive calls to keystone to validate teh authtoken that is in the request has the correct roles
15:36:44 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Rewrite host aggregate, availability zone docs https://review.opendev.org/667133
15:40:23 stephenfin bauzas: There's the AZ doc rework promised, if you care to bookmark for later https://review.opendev.org/#/c/667133/
15:40:37 bauzas ack
15:47:48 Zara sean-k-mooney: hm, it seems odd since keystone itself seems to work fast (the POST auth/tokens calls seem to be the same length; it's the GET /servers/detail that's slow for the different roles. I'd've thought the token posting would be slow. maybe a dodgy assumption)
15:51:14 mriedem listing servers is going to be slower for admins b/c the api returns more data
15:51:15 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Convert nova-next to a zuul v3 job https://review.opendev.org/670196
15:51:32 mriedem also depends on if you're using all_tenants filtering in the request
15:52:19 stephenfin gibi: Is my comment about docs here correct? https://review.opendev.org/#/c/657796/

Earlier   Later