| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-18 | |||
| 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 | jroll | for anyone that cares about my question: https://github.com/openstack/nova/commit/874ba55a4933e917bca1756fab16d45eb5abf4c0 | |
| 19:08:54 | efried | Quant aux questions keystone, meilleur les poser dans #openstack-keystone | |
| 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: ProviderTree.data => ProviderData https://review.openstack.org/533244 | |
| 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: Track associated sharing RPs in report client https://review.openstack.org/526539 | |
| 19:48:42 | openstackgerrit | Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540 | |
| 19:48:42 | openstackgerrit | Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756 | |
| 19:48:43 | openstackgerrit | Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541 | |
| 19:48:43 | openstackgerrit | Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808 | |
| 19:48:44 | openstackgerrit | Eric Fried proposed openstack/nova master: report client: get_provider_tree_and_ensure_root https://review.openstack.org/521098 | |
| 19:48:45 | openstackgerrit | Eric Fried proposed openstack/nova master: ComputeDriver.update_provider_tree() https://review.openstack.org/521187 | |
| 19:48:45 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821 | |
| 19:48:46 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 19:48:46 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 19:48:47 | openstackgerrit | Eric Fried proposed openstack/nova master: SchedulerReportClient._delete_provider https://review.openstack.org/535463 | |
| 19:48:58 | efried | jaypipes ^ The bottom chunks of that (the non-WIPs) should be good to go as we discussed. | |
| 19:49:10 | jaypipes | efried: roger | |
| 19:49:20 | efried | jaypipes I injected the _delete_provider helper in the middle there, as discussed in the review of update_from_provider_tree. | |
| 19:49:39 | jaypipes | efried: yup, perfect, thank you sir | |
| 19:49:58 | efried | jaypipes I'm going to sidetrack slightly and do some cleanup I've been meaning to do for a while. Should be a small change: I'm gonna move the _association_refresh_time datum into the _Provider. | |
| 19:50:11 | efried | jaypipes Cause I noticed there's a bunch of places we're forgetting to keep that guy up to date. | |
| 19:50:20 | jaypipes | ++ | |
| 19:50:21 | jaypipes | sounds good to me. | |
| 19:50:32 | jaypipes | I will re-review the series | |
| 19:50:45 | efried | Thanks dood. | |