Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-11
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 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:06 kenperkins ``rebuild`` process.
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: docs: Rewrite host aggregate, availability zone docs https://review.opendev.org/667133
15:22:28 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Keeping going with docs https://review.opendev.org/670332
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
15:53:45 sean-k-mooney but ya that is proably more likely the reason for the delta in performance
15:54:31 mriedem sean-k-mooney: of course
15:54:40 Zara it's the other way around, though; the member role is the slow one and the admin role is the fast one
15:55:02 mriedem sounds like it's time to do some profiling
15:57:26 mriedem tssurya: can't we have some functional test on https://review.opendev.org/#/c/645611/ ?
15:58:46 mriedem efried: don't we have some rules about removing things from a runway slot if they've been in merge conflict for over a week and the author is not responsive?
15:59:08 mriedem "The code author must be ready for quick iteration on the patch reviews and responding to review comments. The author will be consulted before moving the blueprint to a runway to make sure the next 2 weeks are suitable for quick iteration on the reviews. If the next 2 weeks are not suitable, the next blueprint in line will be tried and the deferred blueprint will maintain its place in line."
15:59:10 efried mriedem: if not, we should.
15:59:21 mriedem ok i'm going to remove the sev stuff
15:59:25 tssurya mriedem: hmm I guess we could, I'll add some using your fake driver suggestion
15:59:25 efried mriedem: I've poked aspiers a couple of times about the merge conflict, so yeah.
15:59:32 efried thanks
15:59:37 sean-k-mooney mriedem: i think in general if the authour is not responcive that is enough to kick it
15:59:44 sean-k-mooney assuming it has -1 form a core
16:00:21 tssurya and I guess I have to bump microversion
16:00:21 sean-k-mooney e.g. it need to be reworked but no active engagment form the owner
16:15:29 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Convert nova-next to a zuul v3 job https://review.opendev.org/670196
16:21:14 mriedem artom: pro tip, if rebasing https://review.opendev.org/#/c/667177/ is not necessary, don't do it
16:21:55 sean-k-mooney mriedem: gerrit need a diff diff setting
16:22:56 sean-k-mooney e.g. generate teh diff for the old patch against old base + new patch against new base and display the diff of those two diff per file
16:23:36 sean-k-mooney aka the eye ball diff we currently do but automated
16:24:31 melwitt yeah, been wanting that to exist for years. does git-review support something like that locally? I keep forgetting
16:25:31 sean-k-mooney not that i know of but it could
16:25:49 sean-k-mooney a 4 way diff is not that uncommon a thing
16:26:10 Zara (thanks for the suggestions so far btw; I disappeared to stare at the output of `nova list --debug` :) )
16:27:43 dansmith git review does have a thing
16:31:41 artom mriedem, I know, not sure what happened
16:32:33 artom I guess I was careless

Earlier   Later