[Openstack-operators] [scientific-wg] possible time change for non-US fortnightly meeting

Hi all, Currently the scientific-wg is meeting weekly on irc with alternating times week to week - 2100 UTC Tues this week and 0700 UTC Weds next week. The basic idea being to have both US and non-US friendly times. The former time is pretty well attended but the latter is somewhat hit and miss

Re: [Openstack-operators] How are folks providing GPU instance types?

Finally circled back to this thread... Joe - those are great notes! On 12 May 2016 at 02:51, Joe Topjian wrote: > * I found that I didn't have to use EFI-based images. I wonder why that is? Yeah, we've never run into this as a requirement either. Peter - can you clarify?

[Openstack-operators] [user-committee][scientific-wg] Scientific Working Group IRC meeting, Weds @0700 UTC in #openstack-meeting

Hi all, Quick reminder that the scientific-wg IRC weekly meeting is on in <6 hours in #openstack-meeting! Details below. We're planning to talk about status and use-cases for Blazar, plus continued discussion/brain-storming on use-cases pertaining to our focus areas. On the latter point this

Re: [Openstack-operators] [User-committee] [scientific-wg] terminology

Hi Tim, Firstly, thank-you for reading the logs and following up - it's great to have further discussion generated! On 2 June 2016 at 03:07, Tim Randles wrote: > Sorry I wasn't able to make yesterday's Scientific Working Group IRC > meeting. The discussion looked very

Re: [Openstack-operators] [openstack-dev] [glance] Proposal for a mid-cycle virtual sync on operator issues

Hi Nikhil, 2000UTC might catch a few kiwis, but it's 6am everywhere on the east coast of Australia, and even earlier out west. 0800UTC, on the other hand, would be more sociable. On 26 May 2016 at 15:30, Nikhil Komawar wrote: > Thanks Sam. We purposefully chose that time

[Openstack-operators] [scientific-wg] catch-up tomorrow

Hi all, Apologies if you receive multiple copies. I've BCC'd everyone who left addresses in the etherpads. Firstly, thank-you for attending the inaugural scientific-wg meeting! The turnout and discussion was excellent. If you're interested in being an active member or observer of the

[Openstack-operators] Xenial libvirt/numad

Hi all, numad provides dynamic and advisory NUMA tuning. It monitors NUMA topology and cpu/memory usage within a system and dynamically tunes NUMA and CPU affinity and/or provides process pre-placement advice to management tools like libvirt. If you've never tried it, it works very well and can

Re: [Openstack-operators] KVM memory overcommit with fast swap

, but that it needed testing. I'm happy to help test this out. Sounds like the results could be part of a Tokyo talk :P Warren Warren On Mon, Jun 29, 2015 at 9:36 AM, Blair Bethwaite blair.bethwa...@gmail.com wrote: Hi all, Question up-front: Do the performance characteristics of modern PCIe

[Openstack-operators] KVM memory overcommit with fast swap

Hi all, Question up-front: Do the performance characteristics of modern PCIe attached SSDs invalidate/challenge the old don't overcommit memory with KVM wisdom (recently discussed on this list and at meetups and summits)? Has anyone out there tried tested this? Long-form: I'm currently

[Openstack-operators] Hypervisor tuning - ops summit session

Greetings fellow operators, I'm excited to be moderating the Vancouver ops summit session on hypervisor tuning (etherpad over here: https://etherpad.openstack.org/p/YVR-ops-hypervisor-tuning). I hope we can gather some useful new information for the ops guide and perhaps even share a few

[Openstack-operators] limit num instance-type per host

Hi all, I'm trying to wrap my head around whether it's possible with the existing scheduler filters, to put a limit per host on the number of instances per instance-type/flavor? I don't think this is possible with the existing filters or weights, but it seems like a fairly common requirement.

<    1   2