Earlier  
Posted Nick Remark
#openstack-nova - 2019-07-11
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/
15:53:19 sean-k-mooney mriedem: well not jsut admins right. if you are uing custom roles to expose more data different roles could be slower depending on what is being returned for that role

Earlier   Later