Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-18
15:55:29 ameeda what about this log ? undercloud.bootpc > gateway.bootps: BOOTP/DHCP, Request from 00:a7:b7:5c:d0:dd (oui Unknown), length 30
15:55:33 lyarwood gibi: the stable/ocata change is open, newton is EOL so I'd rather not open it up
15:55:35 bauzas gibi: sure, doing it
15:55:54 gibi lyarwood: thanks. you are right netwon is EOL
15:56:07 amorin lyarwood: gibi thanks for ocata
15:56:19 amorin problem is that this bug is supposed to be fixed:
15:56:21 amorin https://review.openstack.org/#/q/b706155888d7408
15:56:22 bauzas hah, jinxed by lya
15:56:25 bauzas lyarwood:
15:56:27 amorin but is not
15:56:40 amorin sorry good link : https://bugs.launchpad.net/nova/+bug/1662626
15:56:41 bauzas and yeah, newton is EOL, so no for that one
15:56:41 openstack Launchpad bug 1662626 in nova (Ubuntu Xenial) "live-migrate left in migrating as domain not found" [Medium,Triaged]
15:57:06 amorin thanks
15:57:59 amorin I'll rebase the ocata one
15:59:56 openstackgerrit Arnaud Morin proposed openstack/nova stable/ocata: Stop _undefine_domain erroring if domain not found https://review.openstack.org/508640
16:01:14 ameeda TheJuliaL what about this log ? undercloud.bootpc > gateway.bootps: BOOTP/DHCP, Request from 00:a7:b7:5c:d0:dd (oui Unknown), length 30
16:06:25 openstackgerrit Merged openstack/nova master: trivial: Remove crud from 'conf.py' https://review.openstack.org/534713
16:20:13 Spazmotic Mannnnnnnnnnnnnn laying there trying to sleep with resource providers moving through my brain
16:24:44 Spazmotic I understand what you were asking now about discovery and healing efried and I can agree it's something to consider. We already have local delete issues here in Nova but they intend to push this service externally.
16:25:20 Spazmotic Currently we could code around this in Cells or something to monitor the state of a compute node to clear out the placements..or some other solution.. but if we open this into an ew project to keep track of Cinder Volumes, those can possibly have the same issue.
16:25:46 efried Heh, "an ew project" - how apt.
16:25:48 Spazmotic or Kubernetes as well, etc..
16:25:54 Spazmotic hehe
16:26:51 Spazmotic Seems like it should run almost as a service as how we have compute run to monitor its resource providers. Possibly with a column for them for Last_Checked(datetime) and task_state(varchar()) on the resource.
16:26:59 Spazmotic Allow a task state like "Draining"
16:27:18 Spazmotic To clear the providers in a data-loss event like that where a compute node or such doesn't ever intend to come back up, or will get a new headshot
16:27:19 openstackgerrit Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/535121
16:27:31 Spazmotic err consumers rather.
16:27:46 Spazmotic But that's just from first blush of looking at the code and trying to fall asleep.. i may be a zombie.
16:34:11 Spazmotic But yeah.. currently that is far outside of the scope of the current project unfortunately.
16:55:29 gibi bauzas: Do you agree that this is not a problem? https://review.openstack.org/#/c/533642/4/nova/virt/libvirt/driver.py@555
16:56:34 bauzas gibi: that's an excellent catch!
16:56:44 bauzas gibi: but yeah you're right, not impactful
16:57:16 bauzas gibi: because I'm just doing that for recreating mediated devices that are assigned to instances by the related guest XML
16:57:39 bauzas gibi: so, if after looking at all the instances, we destroy some of them, it will just leave some mediated devices "free"
16:58:19 gibi bauzas: and those mdevs will be used for the next VM boot that requests vgpus
16:59:10 gibi bauzas: as the code only create new mdevs if there is no existing is found
16:59:42 bauzas gibi: correct
17:00:00 bauzas gibi: I also added in a comment that it *could* be a problem when we begin supporting multiple types
17:00:41 bauzas gibi: but then, I plan to just verify all the mediated devices whether they're assigned or not once an instance is spawned to make sure we don't create more mdevs than needed
17:01:14 gibi bauzas: sounds good
17:01:37 gibi bauzas: hm, we actually leak the mdev uuid from the destroyed VM to the new VM and if the destroyed VM is one that was evacuated then we will have two VMs on two separate compute hosts with identical mdev uuids. But I guess it is not a problem
17:02:12 bauzas gibi: migrating a VM with vGPUs isn't tested yet
17:02:36 bauzas gibi: but I'd treat any possible problem with migrations as bugs
17:02:47 gibi bauzas: I agree
17:02:56 gibi bauzas: I'm +2 on this patch
17:03:00 bauzas cool thanks
17:03:04 gibi bauzas: thanks for the explanation
17:03:15 bauzas I still need to add a new patch for the suspend case
17:03:22 bauzas but I'll treat that patch as a bug
17:03:46 bauzas because that's not working because libvirt doesn't support suspending a guest with attached PCI or mediated devices
17:03:52 bauzas just FYI
17:04:17 gibi bauzas: seems like a bleading edge feature :P)
17:04:31 gibi s/bleading/bleeding/
17:04:33 bauzas hah!
17:05:02 bauzas when I see how people plan to use vGPUs, I'd be surprised if they want to suspend
17:05:20 openstackgerrit Ildiko Vancsa proposed openstack/nova master: libvirt: don't attempt to live snapshot paused instances https://review.openstack.org/532214
17:05:29 bauzas most of them just want to boot an instance, compute what they need (bitcoins$$$), and destroy the instance
17:05:46 bauzas because having an instance that runs more than you need costs you money
17:06:06 bauzas anyway, calling it a day
17:06:19 bauzas \o and thanks gibi
17:06:26 gibi bauzas: have a nice afternoon!
17:06:38 bauzas s/evening
17:06:46 bauzas GMT+1 man ;)
17:08:06 gibi bauzas: yeah, sorry, bad English :)
17:08:19 gibi btw I have to leave now as well
17:59:43 ciao list
18:16:18 efried jaypipes Thinking it through some more, since update_from_provider_tree is walking any number of providers, it might make more sense to handle conflicts internal to that method after all: log a warning, invalidate *that* provider from the cache, set an overall "failed" flag, and move on to the next provider needing to be changed. At the end, if the overall "failed" flag is set, raise an exception.
18:17:09 jaypipes efried: ++
18:41:02 octopus J'ai installer Openstack sur trois VMs (Controller, Network et Compute)
18:41:04 octopus Ma premiere question concerne les endpoint keystone. tous les endpoint pointe sur mon serveur Controller sauf les endpoint neutron (network). Est-ce que les endpoint nova doivent pointer sur le serveur compute ou sur le serveur controller ?
18:41:08 octopus Lorsque je lances "openstack server create ...." j'ai ce message d'erreur: Erreur de l'API inattendue. Merci de la reporter sur http://bugs.launchpad.net/nova/ et d'y joindre le rapport de L'API Nova si possible.
18:41:11 octopus <class 'keystoneauth1.exceptions.connection.ConnectFailure'> (HTTP 500) (Request-ID: req-164d48ac-21b2-4318-8a59-1c9748479bd1)
18:41:14 octopus Quand je regarde mes logs j'ai ça: ERROR nova.api.openstack.extensions [req-179695e3-e5c1-4574-89ab-e66e566c5592 - - - - -] Unexpected exception in API method: ConnectFailure: Unable to establish connection to http://127.0.0.1:9696/v2.0/security-groups?fields=id&id=920f739e-8105-400b-baf0-0356d0fe0e61: HTTPConnectionPool(host='127.0.0.1', port=9696): Max retries exceeded with url: /v2.0/security-groups?fields=id&id=920f73
18:41:19 octopus 9e-
18:41:21 octopus 8105-400b-baf0-0356d0fe0e61 (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x9359090>: Failed to establish a new connection: [Errno 111] ECONNREFUSED',))
18:41:24 octopus Pour il recherche sur le Port 9696 local ? j'ai bien déclaré mes API (admin, public, interne) neutron sur le serveur neutron (http://network:9696)
18:41:27 octopus pourquoi :)
18:41:29 octopus Merci pour votre aide :)
19:05:19 jroll out of tree api extensions are totally dead now, right? trying to find solid verification of that but having trouble
19:08:36 jroll ah, found it
19:08:37 efried octopus Je crois que l'endpoint nova doit pointer au serveur où se trouve la service n-api (qui est normalement le controlleur).
19:08:54 efried Quant aux questions keystone, meilleur les poser dans #openstack-keystone
19:08:54 jroll for anyone that cares about my question: https://github.com/openstack/nova/commit/874ba55a4933e917bca1756fab16d45eb5abf4c0
19:10:08 efried octopus (Et les poser en anglais :) Il n'y a pas beaucoup be francophones là-dedans)
19:10:23 efried jroll Is that the last patch in the blueprint?
19:11:13 efried octopus s/be/de/
19:11:32 jroll efried: yes, but had trouble finding this BP, as "api-no-more-extensions" linked to "api-no-more-extensions-ocata", which doesn't exist, and this was in "api-no-more-extensions-pike"
19:30:34 artom efried, the hell, you're French?
19:30:59 efried artom No, American
19:31:13 artom efried, well, your French is pretty good :)
19:31:24 efried Thanks!
19:48:41 openstackgerrit Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
19:48:41 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564
19:48:41 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.data => ProviderData https://review.openstack.org/533244
19:48:42 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
19:48:42 openstackgerrit Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
19:48:43 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808
19:48:43 openstackgerrit Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541

Earlier   Later