Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-05
15:18:13 dansmith ah nm,
15:18:14 dansmith yeah
15:18:17 lyarwood should be in the gate by now
15:18:26 dansmith not quite
15:18:27 mriedem still check queue, but going
15:18:35 lyarwood urgh
15:18:52 mriedem dansmith: btw, i had to fix a test in https://review.openstack.org/#/c/530982/
15:19:34 mriedem lyarwood: since you're around https://review.openstack.org/#/q/I1aa3ca6cc70cef65d24dec1e7db9491c9b73f7ab
15:19:40 mriedem that should be the final thing for newton
15:20:04 mriedem melwitt: this is a simple bp driver feature parity change https://review.openstack.org/#/c/448034/
15:20:08 mriedem needs final +2
15:20:12 lyarwood mriedem: ack
15:20:36 melwitt mriedem: ack, will review
15:20:43 mriedem thanks
15:21:08 mriedem i see the allocation candidates limit change is also approved https://review.openstack.org/#/c/513526/ - nice, might get at least 2 bps merged today
15:21:28 openstackgerrit Lajos Katona proposed openstack/nova master: Deduplicate service status notification samples https://review.openstack.org/531381
15:22:35 mriedem andreykurilin: can you take a look at https://review.openstack.org/#/c/528128/ ? it will close out that bp and it's holding up other microversion changes in novaclient
15:27:18 ildikov mriedem: ok, tnx
15:27:34 openstackgerrit Lajos Katona proposed openstack/nova master: Deduplicate aggregate notification samples https://review.openstack.org/531162
15:30:43 mriedem stephenfin: http://logs.openstack.org/50/530950/1/check/legacy-tempest-dsvm-py35/f814425/logs/screen-n-novnc.txt.gz?level=TRACE#_Jan_04_17_19_48_242679
15:30:57 mriedem stephenfin: maybe try using encodeutils.safe_encode here? https://review.openstack.org/#/c/345399/37/nova/console/securityproxy/rfb.py
15:31:28 stephenfin mriedem: I can't catch a break with that thing :D That's a good idea though
15:31:51 stephenfin silly stephenfin
15:37:04 sean-k-mooney fried_rice: thanks. ya i noticed that there seemed to be multiple nrp patch series interwoven. i think https://review.openstack.org/#/c/384807/ is the patch i need to start using nrp to model hw acclerated vhost-vfio interfaces.
15:41:03 fried_rice sean-k-mooney "hw accelerated vhost-vfio interfaces". Sure.
15:42:25 mriedem i can't wait until sean-k-mooney stabs one of you guys
15:42:30 sean-k-mooney fried_rice: they are hardware offloaded port that use vfio-mdev instead of sriov to offload the dataplane and vhost to offload the control plane
15:43:18 fried_rice sean-k-mooney Okay, cool. So how are you planning to represent that from libvirt without using update_provider_tree?
15:43:32 hrw melwitt: thanks for +2 +W :)
15:45:36 sean-k-mooney fried_rice: step too is the libvirt xml generation but effectivly i am planning on having neutorn create teh resouce providers in placement and using a new vnic type to generate a request to placement for an allocation of the custom resouce class.
15:45:48 mriedem johnthetubaguy: is there some known thing with using the cachingscheduler where the compute services don't check in on time? or you have to adjust the compute service heartbeat?
15:46:08 johnthetubaguy mriedem: yeah, that is a thing
15:46:13 melwitt hrw: thanks for enhancing the commit message and the bug, makes it a lot easier to review
15:46:17 fried_rice sean-k-mooney This in Queens??
15:46:18 mriedem johnthetubaguy: orly
15:46:24 mriedem yeah because i'm seeing this in the scheduler logs
15:46:24 mriedem Jan 04 20:06:18.133057 ubuntu-xenial-rax-ord-0001690099 nova-scheduler[9487]: WARNING nova.scheduler.filters.compute_filter [None req-370806fa-5640-485d-adc2-21808de9ccb4 tempest-MigrationsAdminTest-1101936831 tempest-MigrationsAdminTest-1101936831] (ubuntu-xenial-rax-ord-0001690099, ubuntu-xenial-rax-ord-0001690099) ram: 6446MB disk: 58368MB io_ops: 15 instances: 15 has not been heard from in a while
15:46:28 mriedem but no errors in the n-cpu logs
15:46:31 hrw melwitt: o yes ;D
15:46:46 hrw melwitt: can you take a look at https://review.openstack.org/#/c/530965/ too?
15:46:46 johnthetubaguy mriedem: if your cache interval is larger than than how long you thing it is dead, it starts to ignore some of your nodes randomly
15:46:54 mriedem ah
15:46:54 hrw melwitt: I am open for any questions
15:46:57 mnaser mriedem: i think i found out how i got that weird state. doing a host-evacuate-live sends a live-migration request for all instances, as nova processes them one by one, the states of all vms in the compute host are in "migrating".. but then its possible that a delete request comes in while the live migration is happening.
15:47:03 sean-k-mooney fried_rice: not upstream, libvirt and qemu dont even have support for vhost-vfio yet. way to early to propose upstrem in openstack
15:47:16 melwitt hrw: I'll add it to my list
15:47:21 hrw melwitt: thanks
15:47:42 hrw melwitt: with those two merged getting openstack on aarch64 is much easier ;D
15:48:10 mnaser in the rpc code, there doesn't seem to be any handling if the VM is in migrating state
15:48:12 sean-k-mooney fried_rice: i would like to have a poc working ptg/early rocky timeframe but i doubt the dependcies will align for it to land even in rocky
15:48:16 mnaser for deletes
15:48:31 hrw melwitt: uefi change is most important as with it in nova we cut 90% of users questions ;d
15:48:58 kashyap mriedem: Hey was AFK
15:49:00 fried_rice sean-k-mooney Okay, gotcha. You going to be around for the sched meeting on Monday? This is exactly the kind of rationale cdent and Radoslav were bringing up in https://review.openstack.org/#/c/526539/ (to pose the question, "Why are we artificially restricting in-tree virt drivers from talking directly to placement?"
15:49:03 kashyap Reading the scroll
15:49:15 fried_rice )
15:49:41 mriedem johnthetubaguy: i don't see a specific config option for how long the cachingscheduler caches it's host state information
15:49:50 mriedem is that somewhere outside the actual CachingScheduler class?
15:49:54 sean-k-mooney fried_rice: am what time is it?( checking meeting page)
15:50:05 johnthetubaguy mriedem: ah, I think its in scheduler manager, sadly
15:50:20 johnthetubaguy just digging
15:50:34 mriedem @periodic_task.periodic_task(spacing=CONF.scheduler.periodic_task_interval,
15:50:34 mriedem run_immediately=True)
15:50:34 mriedem def _run_periodic_tasks(self, context):
15:50:34 mriedem self.driver.run_periodic_tasks(context)
15:50:35 mriedem ?
15:50:50 johnthetubaguy mriedem, yeah https://github.com/openstack/nova/blob/d19e1252d5f2f8e8b54a276003f842ee00641026/nova/scheduler/manager.py#L79
15:50:51 mriedem yup that's it
15:51:08 sean-k-mooney fried_rice: 14:00 UTC i should be able to attend.
15:51:13 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce framework for RFB authentication https://review.openstack.org/345397
15:51:14 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398
15:51:14 openstackgerrit Stephen Finucane proposed openstack/nova master: console: Provide an RFB security proxy implementation https://review.openstack.org/345399
15:51:15 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Document TLS security setup for noVNC proxy https://review.openstack.org/500544
15:51:16 fried_rice sean-k-mooney Cool.
15:51:23 leakypipes cdent, fried_rice: see my comment on https://review.openstack.org/#/c/526539/
15:51:43 openstackgerrit Matt Riedemann proposed openstack/nova master: [libvirt] Allow multiple volume attachments https://review.openstack.org/267587
15:51:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass multiattach flag to reserve_block_device_name https://review.openstack.org/531244
15:51:44 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: [api] Allow multi-attach in compute api https://review.openstack.org/271047
15:51:54 johnthetubaguy mriedem: trying to find the docks I wrote about this, failing :(
15:53:10 stephenfin mriedem: Could you hit this again at some point today? Got an open question on it for you https://review.openstack.org/#/c/526329/
15:53:17 mriedem the config option help for that actually points out the service_down_time option too
15:53:19 cdent leakypipes: thanks reading. I think I tend to use "arbitrary" incorrectly or at least with different connotations that most peole do. I tend to mean it as "something we chose" (as opposed to "a thing we must do")
15:53:22 mriedem so i'm pleasantly surprised
15:53:29 johnthetubaguy mriedem: https://github.com/openstack/nova/blob/d19e1252d5f2f8e8b54a276003f842ee00641026/nova/conf/scheduler.py#L78
15:53:39 johnthetubaguy mriedem: yeah, I knew I put that somewhere!
15:53:43 mriedem johnthetubaguy: yup, was just reading that
15:53:44 mriedem nice
15:53:49 stephenfin oh
15:54:19 leakypipes cdent: sure, understood.
15:54:30 sean-k-mooney fried_rice: im hoping i wont actully need to modify the virt driver as part of the poc beyond the xml generation. on of the advantages of mdevs is you create them using arbitray uuids(neutron port uuid in my case) dynamically so i may be able to skip the resouce tracker entrily as i basically just need a count of howmany can be created per host which the placement inventories will already have.
15:55:35 johnthetubaguy mriedem: there is a type there s/scheduler service as down/compute service as down/
15:55:36 fried_rice leakypipes cdent Good deal. I can see both sides. I don't mind the idea of having intra-nova placement work funneled through this spot for the reasons stated (thread safety, code commonality) as long as we're not doing it with the expectation that e.g. OOT drivers have to conform.
15:55:59 fried_rice sean-k-mooney So where are you going to get that request info from? Just directly from the flavor?
15:56:29 mriedem finucannot: replied
15:56:48 mriedem finucannot: we could backport that to stable/pike upstream, but no further given ocata g-r requires glanceclient>=2.5
15:56:57 mriedem johnthetubaguy: yup i noticed that too
15:57:07 mriedem johnthetubaguy: i'm going to remove the deprecated names for that option, so i'll fix the typo at the same time
15:57:11 leakypipes fried_rice: well, it's Python so of course OOT drivers can always do whatever they want with things ;) but that said, yes, I'd prefer to have the virt drivers just update the ProviderTree object and rely on something else (the reportclient called from the resource tracker most likely) do the work of making placement REST API calls.
15:57:21 finucannot mriedem: Ta
15:57:26 johnthetubaguy mriedem: sweet, thank you

Earlier   Later