Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-11
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
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 efried mriedem: I've poked aspiers a couple of times about the merge conflict, so yeah.
15:59:25 tssurya mriedem: hmm I guess we could, I'll add some using your fake driver suggestion
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 sean-k-mooney e.g. it need to be reworked but no active engagment form the owner
16:00:21 tssurya and I guess I have to bump microversion
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
16:33:03 artom I must have `git rebase -i` to edit that middle patch, and forgotten that I'd updated the remote?
16:33:31 mriedem git review -R
16:33:56 artom Aha, noted
16:42:44 openstackgerrit Dustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for node.list https://review.opendev.org/656027
16:42:44 openstackgerrit Dustin Cowles proposed openstack/nova master: Introduces SDK to IronicDriver and uses for node.get https://review.opendev.org/642899
16:42:45 openstackgerrit Dustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for setting instance id https://review.opendev.org/659690
16:42:45 openstackgerrit Dustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for validating instance and node https://review.opendev.org/656028
16:42:46 openstackgerrit Dustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for getting network metadata from node https://review.opendev.org/670213
16:42:46 openstackgerrit Dustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for add/remove instance info from node https://review.opendev.org/659691
16:45:59 efried rebase = false
16:45:59 efried [gitreview]
16:45:59 efried mriedem: artom: or in .gitconfig, so you don't have to remember -R each time:
16:46:29 melwitt mriedem: do you know if the add/remove security group to/from instance API is a candidate for deprecation? was just looking at this abandoned patch after noticing the bug in launchpad https://review.opendev.org/535510
16:46:56 mriedem efried: i don't personally want it in config since i make the decision each time
16:48:51 mriedem melwitt: i want to say it wasn't in https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/deprecate-api-proxies.html because it's an operation on the server which is not deprecated
16:48:54 mriedem even if it's a proxy to neutron
16:49:10 mriedem but we're not very consistent about that b/c the floating IP things in https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/deprecate-multinic-proxy-api.html are similar
16:49:49 melwitt mriedem: yeah, was thinking similar. at first I was comparing to attach interface but that's different bc you can't do that without nova. whereas it looks like you could do the add/remove secgroup to port without nova
16:49:51 mriedem addFloatingIP and removeFloatingIP would be in the same group as add/removeSecurityGroup on a server
16:51:23 melwitt ok, yeah. just wanted to ask bc the patch was abandoned on that basis (the potential for deprecation). otherwise, someone said they had tested the patch and it worked to fix the concurrent update problem
18:04:54 mriedem efried: i'm +2 on gibi's big heal_allocations change now https://review.opendev.org/#/c/637955/35
18:05:03 efried oh goodie
18:05:13 mriedem i'm sure you can just rubber stamp it with no effort
18:05:27 efried I'm sure
18:05:37 efried been waiting for you to quit hammering at it before looking again
18:05:42 efried I'm sure it's nigh unrecognizable now.

Earlier   Later