Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-30
15:27:00 bauzas for that, we're not needing searchlight, right?
15:27:19 mriedem what does multiple backends mean?
15:37:17 mordred efried: I started on the keystoneauth patches to implement all the things we've been poking at over the weekend
15:37:39 efried mordred Cool man. Please add me to the review(s).
15:38:14 efried mordred I still need to get caught up on the... "literature" backlog ;-)
15:38:19 mordred efried: https://review.openstack.org/#/q/status:open+project:openstack/keystoneauth+branch:master+topic:version-discovery
15:38:55 efried mordred Dig.
15:39:34 mordred efried: I still don't have list-of-interface done, nor the service-types aliases - but those should be easy enough to do as a follow on
15:40:43 efried mordred Okay. If you get a chance to comment in https://review.openstack.org/458257 as to how that guy should change as a result, please do.
15:45:10 openstackgerrit John Griffith proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285
15:47:04 sfinucan jaypipes: Are these scripts auto-generated by sqlmigrate? https://review.openstack.org/#/c/469147/1/nova/db/sqlalchemy/migrate_repo/versions/362_add_pci_devices_uuid.py
15:47:22 jaypipes sfinucan: no. hand written. why?
15:47:26 sfinucan sqlalchemy-migrate
15:47:33 mordred efried: done
15:47:38 sfinucan Just checking - reading up on the syntax now
15:47:39 efried mordred Thanks
15:47:58 mordred efried: it's possible we might be able to clean up more things once we start poking
15:48:35 efried mordred It would be neat if we could do away with the nova.utils bit entirely.
15:48:52 efried mordred But I wouldn't want the consumers to have to do more than a couple of lines.
15:49:09 efried mordred E.g. they shouldn't have to do the looping logic.
15:49:25 mordred yah- well, the looping logic will definitely go away
15:50:00 mordred but even if we can just get it down to 3 lines of load_from_conf_options calls, it's probably somewhat worthwhile to have as a function perhaps
15:58:59 jaypipes melwitt, mriedem: k, quotas base patch reviewed.
16:00:02 openstackgerrit John Griffith proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285
16:02:27 sfinucan jaypipes: That looks good to me, though I wonder if we need a reno for the online (inline?) migration?
16:02:34 sfinucan If not, I can +2
16:04:34 sfinucan I'll take a look at nested-resource-providers tomorrow, once I've sahid's trusted-vfs thing done
16:05:08 mriedem trusted-vfs?
16:07:34 jaypipes mriedem: https://review.openstack.org/#/c/458514/
16:07:58 clarkb mriedem: http://logs.openstack.org/03/415103/4/gate/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/4e7ec35/logs/screen-n-cpu.txt.gz?level=ERROR looking at that failure and trying to dig through the libvirt logs to see if there is any explanation for why that happened and not finding much. But am noticing libvirt complains that dmidecode is missing. Any idea if that is required for live
16:08:00 clarkb migration (so that it can check compatibility of hardware maybe?)
16:08:29 mriedem jaypipes: sfinucan: that's not an approved blueprint
16:14:20 jaypipes mriedem: nested resource providers?
16:14:45 clarkb actually nevermind its explicitly failign to exchange identification implying an auth problem?
16:19:58 mriedem jaypipes: no trusted vfs
16:20:10 jaypipes mriedem: understood.
16:30:19 mriedem clarkb: looks like the problem is "Failed to connect to remote libvirt URI qemu+ssh://stack@ubuntu-xenial-2-node-rax-ord-9016742-596845/system: Cannot recv data: ssh_exchange_identification: Connection closed by remote host: Connection reset by peer"
16:32:07 openstackgerrit Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/468494
16:32:31 mriedem http://logs.openstack.org/03/415103/4/gate/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/4e7ec35/logs/libvirt/libvirtd.txt.gz#_2017-05-27_00_12_18_968 is the error in the libvirtd logs
16:34:29 clarkb mriedem: yup, I think either we have general network issues between the nodes or ssh isn't configured properly
16:35:29 clarkb mriedem: I'll get a e-r query for it pushed shortly then we can query it and see if its cloud related
16:51:01 bauzas jaypipes: thanks for commenting https://review.openstack.org/#/c/469037/2, I'll provide a new version but see my comments in https://review.openstack.org/#/c/469037/2/nova/conductor/tasks/live_migrate.py
16:51:17 bauzas jaypipes: tl;dr: cellsv1 old instances can possibly have no RequestSpec records
16:51:44 bauzas melwitt: mriedem: FYI ^ given you also worked on https://review.openstack.org/#/c/391060/
16:53:52 openstackgerrit Rafael Folco proposed openstack/nova master: Delete all inventory has its own method DELETE https://review.openstack.org/460147
16:57:41 jaypipes bauzas: answered.
16:57:58 jaypipes bauzas: I think all that needs is an else: block, no?
16:57:58 bauzas roger.
16:58:55 bauzas jaypipes: uh no, see, I'm not using *self.request_spec*
16:59:16 bauzas jaypipes: I'm rather passing a newly-created request_spec hydrated
16:59:58 bauzas the conditional in L159 outputs a variable named request_spec which is not an attribute
17:00:03 jaypipes bauzas: ahhh
17:00:10 bauzas and I'm using it L175
17:00:16 jaypipes bauzas: sorry, that was confusing. I missed the self. vs. not-self. thing.
17:00:22 bauzas jaypipes: np
17:00:30 bauzas and you're right, it's confusing
17:01:34 jaypipes bauzas: k, +2 from me.
17:01:39 jaypipes bauzas: sorry about the confusion.
17:01:44 bauzas jaypipes: anyway, will respin
17:01:51 bauzas in order to cut it from the topic
17:03:51 jaypipes rfolco: one teeny missing 1.7 reference still in there. push a fix and I'm good to +2.
17:04:36 rfolco jaypipes, oh geez, will fix it quick
17:06:17 openstackgerrit Sylvain Bauza proposed openstack/nova master: _schedule_instances() supporting a RequestSpec object https://review.openstack.org/469037
17:06:34 bauzas jaypipes: https://review.openstack.org/#/c/469037/ rev'd for just amending the bp name and a nit
17:06:55 bauzas jaypipes: will look at the shared RP spec later tonight
17:07:16 openstackgerrit Rafael Folco proposed openstack/nova master: placement: Specific error for inventory in use https://review.openstack.org/460231
17:09:07 openstackgerrit Rafael Folco proposed openstack/nova master: Delete all inventory has its own method DELETE https://review.openstack.org/460147
17:11:11 rfolco jaypipes, like your portuguese. Thanks :)
17:11:56 openstackgerrit Jay Pipes proposed openstack/nova master: Delete all inventory has its own method DELETE https://review.openstack.org/460147
17:11:57 jaypipes rfolco: :)
17:12:05 edleafe bauzas: ok, had a few minutes between meetings. Looking at the difference between my last patch and yours (https://review.openstack.org/#/c/465171/7..9), the only change I see is the cell0 context change
17:12:07 jaypipes rfolco: ^^ just fixed a typo and repushed.
17:12:20 edleafe bauzas: that doesn't appear to be related to this patch at all
17:12:33 edleafe bauzas: shouldn't it be a separate patch?
17:26:52 efried jaypipes Got a minute?
17:28:26 jaypipes efried: can you give me about 30 mins to review your get_inventory() patch? :)
17:29:01 openstackgerrit Merged openstack/nova master: Add recreate functional test for regression bug 1689692 https://review.openstack.org/468549
17:29:01 openstack bug 1689692 in OpenStack Compute (nova) "MarkerNotFound when limit>num(instances) and marker starts in cell0" [High,In progress] https://launchpad.net/bugs/1689692 - Assigned to Matt Riedemann (mriedem)
17:29:07 efried jaypipes Absolutely, thanks. I think I missed you on Friday, but here are the questions/uncertainties I had: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-05-26.log.html#t2017-05-26T19:55:33
17:29:57 jaypipes efried: heh. "claimified" :) nice.
17:30:06 efried (TM)
17:30:45 jaypipes efried: :) so, the answer to your question #1 is yes, exactly. we handle allocations totally separately now.
17:31:10 jaypipes efried: as for the second question, can you give me examples of these resource classes that will not be consumed?
17:31:18 efried k. That's gonna make 'reserved' way more important (and harder to handle for us).
17:31:23 sdake is there any recent regression in the nova client or nova itself in master?
17:31:41 efried jaypipes I'm not sure they were being consumed in the first place. There's a link: https://github.com/openstack/nova/blob/master/nova/virt/powervm/host.py#L55-L64
17:31:59 efried I noticed similar resources from get_available_resource in one of the other drivers - ironic, I think.
17:32:06 jaypipes efried: oh, yeah, those aren't resources. :)
17:32:12 efried Which, as far as I can tell, are also going to be ignored under get_inventory
17:32:42 jaypipes well, the numa_topology may be a resource in the (hopefully near) future. but things like hypervisor_type and supported_instances, etc, are not resource classes.
17:32:59 jaypipes efried: yes, those are ignored by get_inventory()
17:33:00 efried jaypipes Okay, so when I remove get_available_resource, those will just vanish and nobody will care? (Assuming I'm correct in my assessment that nobody's using them today?)
17:33:40 efried It's possible those guys had their origin by us looking at the other drivers and trying to emulate them.
17:33:50 efried ...blindly, without understanding wtf we were doing :)
17:33:57 efried But that's before my time.
17:34:56 jaypipes efried: no, the idea (eventually) is to have a tree of resource providers be passed to the virt driver. the virt driver will be able to set inventory on those providers in the tree as well as decorate the providers with traits.
17:35:35 jaypipes efried: the get_inventory() patches are kind of a stepping stone towards that eventual nirvana...
17:36:22 efried jaypipes And a "resource provider" is e.g. the host, and a "resource class" is e.g. VCPU.
17:37:08 jaypipes efried: my latest thinking on this is that the resource tracker would load up a ProviderTree (from https://review.openstack.org/#/c/415920/), pass that to a virt driver update_inventory() method and then pass the tree to a virt driver set_traits() method. possibly we could do the entire update inventory and set traits in a single method...
17:37:23 jaypipes efried: yes (to answer your question above)

Earlier   Later