Re: [Openstack-operators] leaving Openstack mailing lists

Good luck with whatever you are doing next Saverio, you've been a great asset to the community and will be missed! On Thu, 6 Sep 2018 at 23:43, Saverio Proto wrote: > Hello, > > I will be leaving this mailing list in a few days. > > I am going to a new job and I will not be involved with

Re: [Openstack-operators] large high-performance ephemeral storage

e to create some type of > matrix? > > On Wed, Jun 13, 2018 at 8:18 AM, Blair Bethwaite < > blair.bethwa...@gmail.com> wrote: > >> Hi Jay, >> >> Ha, I'm sure there's some wisdom hidden behind the trolling here? >> >> Believe me, I have tried to push the

Re: [Openstack-operators] large high-performance ephemeral storage

Lol! Ok, forgive me, I wasn't sure if I had regular or existential Jay on the line :-). On Thu., 14 Jun. 2018, 00:24 Jay Pipes, wrote: > On 06/13/2018 10:18 AM, Blair Bethwaite wrote: > > Hi Jay, > > > > Ha, I'm sure there's some wisdom hidden behind the trolling here?

Re: [Openstack-operators] large high-performance ephemeral storage

, 00:03 Jay Pipes, wrote: > On 06/13/2018 09:58 AM, Blair Bethwaite wrote: > > Hi all, > > > > Wondering if anyone can share experience with architecting Nova KVM > > boxes for large capacity high-performance storage? We have some > > particular use-cases t

[Openstack-operators] large high-performance ephemeral storage

Hi all, Wondering if anyone can share experience with architecting Nova KVM boxes for large capacity high-performance storage? We have some particular use-cases that want both high-IOPs and large capacity local storage. In the past we have used bcache with an SSD based RAID0 write-through

[Openstack-operators] pci passthrough & numa affinity

Hi Jon, Following up to the question you asked during the HPC on OpenStack panel at the summit yesterday... You might have already seen Daniel Berrange's blog on this topic:

Re: [openstack-dev] [cyborg] [nova] Cyborg quotas

05/19/2018 05:58 PM, Blair Bethwaite wrote: > > G'day Jay, > > > > On 20 May 2018 at 08:37, Jay Pipes <jaypi...@gmail.com> wrote: > >> If it's not the VM or baremetal machine that is using the accelerator, > what > >> is? > > > > It will

Re: [openstack-dev] [cyborg] [nova] Cyborg quotas

G'day Jay, On 20 May 2018 at 08:37, Jay Pipes wrote: > If it's not the VM or baremetal machine that is using the accelerator, what > is? It will be a VM or BM, but I don't think accelerators should be tied to the life of a single instance if that isn't technically necessary

Re: [openstack-dev] [cyborg] [nova] Cyborg quotas

Relatively Cyborg-naive question here... I thought Cyborg was going to support a hot-plug model. So I certainly hope it is not the expectation that accelerators will be encoded into Nova flavors? That will severely limit its usefulness. On 19 May 2018 at 23:30, Jay Pipes

[Openstack-operators] [scientific] IRC meeting 2100UTC

Hi all, Reminder there's a Scientific SIG meeting coming up in about 6.5 hours. All comers welcome. (https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_20th_2018) IRC Meeting March 20th 2018 2018-03-20 2100 UTC in channel #openstack-meeting # Forum brainstorming

Re: [Openstack-operators] outstanding issues with GPU passthrough

the source of a firmware write, or if it's just something that NVIDIA's own drivers check by reading the firmware ROM. On Tue., 20 Mar. 2018, 17:47 Blair Bethwaite, <blair.bethwa...@monash.edu> wrote: > Hi all, > > This has turned into a bit of a screed I'm afraid... > >

[Openstack-operators] outstanding issues with GPU passthrough

ay, hopefully all this is useful in some way. Perhaps if we get enough customers pressuring NVIDIA SAs to disclose the PCIe security info, it might get us somewhere on the road to securing passthrough. Cheers, -- Blair Bethwaite Senior HPC Consultant Monash eResearch Centre Monash University

Re: [Openstack-operators] [openstack-dev] [nova] about rebuild instance booted from volume

Please do not default to deleting it, otherwise someone will eventually be back here asking why an irate user has just lost data. The better scenario is that the rebuild will fail (early - before impact to the running instance) with a quota error. Cheers, On Thu., 15 Mar. 2018, 00:46 Matt

Re: [openstack-dev] [nova] about rebuild instance booted from volume

Please do not default to deleting it, otherwise someone will eventually be back here asking why an irate user has just lost data. The better scenario is that the rebuild will fail (early - before impact to the running instance) with a quota error. Cheers, On Thu., 15 Mar. 2018, 00:46 Matt

[Openstack-operators] big windows guests on skylake server cpus with libvirt+kvm

Hi all, Has anyone else tried this combination? We've set up some new computes with dual Xeon Gold 6150s (18c/36t), so 72 logical cores with hyperthreading. We're trying to launch a Windows Server 2012 R2 guest (hyperv enlightenments enabled via image properties os_type=windows, and virtio 141

Re: [Openstack-operators] [neutron] [os-vif] VF overcommitting and performance in SR-IOV

This is starting to veer into magic territory for my level of understanding so beware... but I believe there are (or could be depending on your exact hardware) PCI config space considerations. IIUC each SRIOV VF will have its own PCI BAR. Depending on the window size required (which may be

Re: [Openstack-operators] [openstack-dev] Mixed service version CI testing

+1! It may also be worth testing a step where Nova & Neutron remain at N-1. On 20 December 2017 at 04:58, Matt Riedemann wrote: > During discussion in the TC channel today [1], we got talking about how > there is a perception that you must upgrade all of the services

Re: [openstack-dev] Mixed service version CI testing

+1! It may also be worth testing a step where Nova & Neutron remain at N-1. On 20 December 2017 at 04:58, Matt Riedemann wrote: > During discussion in the TC channel today [1], we got talking about how > there is a perception that you must upgrade all of the services

Re: [openstack-dev] [all] Switching to longer development cycles

The former - we're running Cells so only have a single region currently (except for Swift where we have multiple proxy endpoints around the country, all backed by a global cluster, but they have to be different regions to put them all in the service catalog). See

Re: [openstack-dev] [all] Switching to longer development cycles

On 14 December 2017 at 17:36, Clint Byrum wrote: > The batch size for "upgrade the whole cloud" is too big. Let's help our > users advance components one at a time, and then we won't have to worry > so much about doing the whole integrated release dance so often. Is there any

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as though there are two issues being discussed under the one banner: 1) maintain old releases for longer 2) do stable releases less

Re: [openstack-dev] Upstream LTS Releases

Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as though there are two issues being discussed under the one banner: 1) maintain old releases for longer 2) do stable releases less

Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases

I missed this session but the discussion strikes a chord as this is something I've been saying on my user survey every 6 months. On 11 November 2017 at 09:51, John Dickinson wrote: > What I heard from ops in the room is that they want (to start) one release a > year who's branch

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

I missed this session but the discussion strikes a chord as this is something I've been saying on my user survey every 6 months. On 11 November 2017 at 09:51, John Dickinson wrote: > What I heard from ops in the room is that they want (to start) one release a > year who's branch

Re: [Openstack-operators] [scientific] Sydney lightning talks session

Hi again all, There's still room for one or two more lightning talks in this session tomorrow. And as has become tradition there will be a prize for the best talk thanks to Arkady Kanevsky from Dell! Please sign up and share your stories - we don't bite. On 18 October 2017 at 08:27, Blair

[Openstack-operators] [scientific] today's meeting at 2100UTC (now!) cancelled

Hi all, Today's meeting is cancelled as the usual chairs are en-route to Sydney! Apologies for the short notice - timezones meant I only just confirmed this. -- Cheers, ~Blairo ___ OpenStack-operators mailing list

Re: [Openstack-operators] Ceph @ OpenStack Sydney Summit

shout out and/or add to https://etherpad.openstack.org/p/SYD-forum-Ceph-OpenStack-BoF. Also, hope to see some of the core team there! Cheers, On 7 July 2017 at 13:47, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > Hi all, > > Are there any "official" plans to h

[Openstack-operators] [scientific] IRC meeting today at 1100UTC (in 1 hour) in #openstack-meeting

Hi all, We have an IRC meeting today at 1100 UTC in channel #openstack-meeting. A light agenda today, mainly looking for input into the SC17 OpenStack in HPC BOF (http://sc17.supercomputing.org/presentation/?id=bof208=sess389). -- Cheers, ~Blairo

Re: [Openstack-operators] Best practice against DDoS on openstack

Similarly, if you have the capability in your compute gear you could do SR-IOV and push the problem entirely into the instance (but then you miss out on Neutron secgroups and have to rely entirely on in-instance firewalls). Cheers, On 25 October 2017 at 01:41, Jeremy Stanley

Re: [Openstack-operators] Guest crash and KVM unhandled rdmsr

Hi Saverio, On 13 October 2017 at 09:05, Saverio Proto wrote: > I found this link in my browser history: > https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/1583819 Thanks. Yes, have seen that one too. > Is it the same messages that you are seeing in Xenial ? There are a

[Openstack-operators] [scientific] Sydney lightning talks session

Hi all, Once again the Scientific SIG (nee WG) has a dedicated lightning talk session happening at the Sydney Summit. If have any interesting OpenStack + Science and/or HPC stories then please through you hat in the ring at: https://etherpad.openstack.org/p/sydney-scientific-sig-lightning-talks

[Openstack-operators] Guest crash and KVM unhandled rdmsr

Hi all, Has anyone seen guest crashes/freezes associated with KVM unhandled rdmsr messages in dmesg on the hypervisor? We have seen these messages before but never with a strong correlation to guest problems. However over the past couple of weeks this is happening almost daily with consistent

[Openstack-operators] [scientific] IRC meeting today at 1100UTC in #openstack-meeting

Hi all, We have an IRC meeting today at 1100 UTC in channel #openstack-meeting We are short a couple of chairs today but would like to start planning out our picks from the Summit schedule and confirming interest in presentation slots for our Scientific Lightening Talk session. Plus I have a

Re: [openstack-dev] Supporting SSH host certificates

A related bug that hasn't seen any love for some time: https://bugs.launchpad.net/nova/+bug/1613199 On 6 October 2017 at 07:47, James Penick wrote: > Hey Pino, > > mriedem pointed me to the vendordata code [1] which shows some fields are > passed (such as project ID) and that

Re: [openstack-dev] vGPUs support for Nova - Implementation

On 29 September 2017 at 22:26, Bob Ball wrote: > The concepts of PCI and SR-IOV are, of course, generic, but I think out of > principal we should avoid a hypervisor-specific integration for vGPU (indeed > Citrix has been clear from the beginning that the vGPU integration we

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

Hi Prema On 28 September 2017 at 07:10, Premysl Kouril wrote: > Hi, I work with Jakub (the op of this thread) and here is my two > cents: I think what is critical to realize is that KVM virtual > machines can have substantial memory overhead of up to 25% of memory, >

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 27 September 2017 at 23:19, Jakub Jursa wrote: > 'hw:cpu_policy=dedicated' (while NOT setting 'hw:numa_nodes') results in > libvirt pinning CPU in 'strict' memory mode > > (from libvirt xml for given instance) > ... > > > > > ... > > So yeah, the

Re: [openstack-dev] [glance] Queens PTG: Thursday summary

On 27 September 2017 at 22:40, Belmiro Moreira wrote: > In the past we used the tabs but latest Horizon versions use the visibility > column/search instead. > The issue is that we would like the old images to continue to be > discoverable by everyone and

Re: [Openstack-operators] [openstack-dev] [nova] Running large instances with CPU pinning and OOM

Also CC-ing os-ops as someone else may have encountered this before and have further/better advice... On 27 September 2017 at 18:40, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > On 27 September 2017 at 18:14, Stephen Finucane <sfinu...@redhat.com> wrote: >> What yo

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

Also CC-ing os-ops as someone else may have encountered this before and have further/better advice... On 27 September 2017 at 18:40, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > On 27 September 2017 at 18:14, Stephen Finucane <sfinu...@redhat.com> wrote: >> What yo

Re: [openstack-dev] [nova] Running large instances with CPU pinning and OOM

On 27 September 2017 at 18:14, Stephen Finucane wrote: > What you're probably looking for is the 'reserved_host_memory_mb' option. This > defaults to 512 (at least in the latest master) so if you up this to 4192 or > similar you should resolve the issue. I don't see how this

Re: [openstack-dev] [glance] Queens PTG: Thursday summary

Hi Belmiro, On 20 Sep. 2017 7:58 pm, "Belmiro Moreira" < moreira.belmiro.email.li...@gmail.com> wrote: > Discovering the latest image release is hard. So we added an image property "recommended" > that we update when a new image release is available. Also, we patched horizon to show > the

Re: [openstack-dev] [ptg] Simplification in OpenStack

I've been watching this thread and I think we've already seen an excellent and uncontroversial suggestion towards simplifying initial deployment of OS - that was to push towards encoding Constellations into the deployment and/or config management projects. On 26 September 2017 at 15:44, Adam

[Openstack-operators] [scientific] s/WG/SIG/g

Hi all, If you happen to have been following along with recent discussions about introducing OpenStack SIGs then this won't come as a surprise. PS: the openstack-sig mailing list has been minted - get on it! The meta-SIG is now looking for existing WGs who wish to convert to SIGs, see

Re: [Openstack-operators] [User-committee] [scientific] WG IRC meeting: 2100 UTC - opportunistic capacity etc.

Hi Stig, It occurs to me we have not yet had any discussion on the recent WG->SIG proposal, which includes the [scientific] posse, so adding that to the agenda too. Cheers, On 5 September 2017 at 19:29, Stig Telfer wrote: > Hello all - > > We have a Scientific WG

Re: [Openstack-operators] GPU passthrough success and failure records

7 at 07:55, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > Hi all, > > I've been (very slowly) working on some docs detailing how to setup an > OpenStack Nova Libvirt+QEMU-KVM deployment to provide GPU-accelerated > instances. In Boston I hope to chat to some of

Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

Hi Alex, I just managed to take a half hour to look at this and have a few questions/comments towards making a plan for how to proceed with moving the Ops Guide content to the wiki... 1) Need to define wiki location and structure. Curiously at the moment there is already meta content at

Re: [openstack-dev] [nova] Should PUT /os-services be idempotent?

Please don't make these 400s - it should not be a client error to be unaware of the service status ahead of time. On 12 July 2017 at 11:18, Matt Riedemann wrote: > I'm looking for some broader input on something being discussed in this > change: > >

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

On 27 June 2017 at 23:47, Sean Dague wrote: > I still think I've missed, or not grasped, during this thread how a SIG > functions differently than a WG, besides name. Both in theory and practice. I think for the most part SIG is just a more fitting moniker for some of these

Re: [openstack-dev] [User-committee] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

On 27 June 2017 at 23:47, Thierry Carrez wrote: > Setting up a common ML for common discussions (openstack-sigs) will > really help, even if there will be some pain setting them up and getting > the right readership to them :) It's worth a try! I agree it will probably

Re: [Openstack-operators] [User-committee] [scientific] 0900 UTC meeting time change?

; Stig > > > On 21 Jun 2017, at 09:13, Blair Bethwaite <blair.bethwa...@monash.edu> > wrote: > > Thanks Pierre. That's also my preference. > > Just to be clear, today's 0900 UTC meeting (45 mins from now) is going > ahead at the usual time. > > On 21 Jun. 2

[openstack-dev] Fwd: [scientific] IRC Meeting (Tues 2100 UTC): Science app catalogues, network security of research computing on OpenStack

Resend for openstack-dev with proper list perms... -- Forwarded message -- From: Blair Bethwaite <blair.bethwa...@monash.edu> Date: 27 June 2017 at 23:24 Subject: [scientific] IRC Meeting (Tues 2100 UTC): Science app catalogues, network security of research computing on Ope

Re: [Openstack-operators] [User-committee] [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

There is a not insignificant degree of irony in the fact that this conversation has splintered so that anyone only reading openstack-operators and/or user-committee is missing 90% of the picture Maybe I just need a new ML management strategy. I'd like to add a +1 to Sean's suggestion about

Re: [openstack-dev] [User-committee] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

There is a not insignificant degree of irony in the fact that this conversation has splintered so that anyone only reading openstack-operators and/or user-committee is missing 90% of the picture Maybe I just need a new ML management strategy. I'd like to add a +1 to Sean's suggestion about

Re: [Openstack-operators] [dev] [doc] Operations Guide future

Hi Alex, On 2 June 2017 at 23:13, Alexandra Settle wrote: > O I like your thinking – I’m a pandoc fan, so, I’d be interested in > moving this along using any tools to make it easier. I can't realistically offer much time on this but I would be happy to help (ad-hoc)

Re: [openstack-dev] [Openstack-operators] [dev] [doc] Operations Guide future

Hi Alex, On 2 June 2017 at 23:13, Alexandra Settle wrote: > O I like your thinking – I’m a pandoc fan, so, I’d be interested in > moving this along using any tools to make it easier. I can't realistically offer much time on this but I would be happy to help (ad-hoc)

Re: [Openstack-operators] [User-committee] [scientific] 0900 UTC meeting time change?

Thanks Pierre. That's also my preference. Just to be clear, today's 0900 UTC meeting (45 mins from now) is going ahead at the usual time. On 21 Jun. 2017 5:21 pm, "Pierre Riteau" <prit...@uchicago.edu> wrote: Hi Blair, I strongly prefer 1100 UTC. Pierre > On 21 Jun 20

[Openstack-operators] [scientific] 0900 UTC meeting time change?

Hi all, The Scientific-WG's 0900 UTC meeting time (it's the non-US friendly time) is increasingly difficult for me to make. A couple of meetings back we discussed changing it and had general agreement. The purpose here is to get a straw poll of preferences for -2 or +2 to the current time, i.e.,

Re: [Openstack-operators] [dev] [doc] Operations Guide future

Hi Alex, Likewise for option 3. If I recall correctly from the summit session that was also the main preference in the room? On 2 June 2017 at 11:15, George Mihaiescu wrote: > +1 for option 3 > > > > On Jun 1, 2017, at 11:06, Alexandra Settle wrote:

Re: [openstack-dev] [Openstack-operators] [dev] [doc] Operations Guide future

Hi Alex, Likewise for option 3. If I recall correctly from the summit session that was also the main preference in the room? On 2 June 2017 at 11:15, George Mihaiescu wrote: > +1 for option 3 > > > > On Jun 1, 2017, at 11:06, Alexandra Settle wrote:

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: NOT Getting rid of the automated reschedule functionality

Thanks Jay, I wonder whether there is an easy-ish way to collect stats about the sorts of errors deployers see in that catchall, so that when this comes back around in a release or two there might be some less anecdotal data available...? Cheers, On 24 May 2017 at 06:43, Jay Pipes

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 23 May 2017 at 05:33, Dan Smith wrote: > Sure, the diaper exception is rescheduled currently. That should > basically be things like misconfiguration type things. Rescheduling > papers over those issues, which I don't like, but in the room it surely > seemed like operators

[openstack-dev] [scientific] Scientific-WG sessions in Boston

Hey all, Hopefully you've all noticed this by now, the timing of the WG sessions (lightening talks, meeting, BoF) has changed a little since first published. I've just updated the etherpad to reflect that now: https://etherpad.openstack.org/p/Scientific-WG-boston Tues 11:15am - 11:55am -

Re: [openstack-dev] [Openstack-operators] [scientific] Lightning talks on Scientific OpenStack

Morning all - Apologies for the shotgun email. But looks like we still have one or two spots available for lightening talks if anyone has work they want to share and/or discuss: https://etherpad.openstack.org/p/Scientific-WG-Boston-Lightning Best regards, On 28 April 2017 at 06:19, George

[openstack-dev] [cyborg] Fwd: GPU passthrough success and failure records

-- Forwarded message -- From: Blair Bethwaite <blair.bethwa...@gmail.com> Date: 6 May 2017 at 17:55 Subject: GPU passthrough success and failure records To: "openstack-oper." <openstack-operat...@lists.openstack.org> Hi all, I've been (very slowly) working

[Openstack-operators] Fwd: [AOSUG] OpenStack Australia Day Melbourne - 1 month to go!

please click here <https://www.meetup.com/members/42165752/> To unsubscribe from special announcements from your Organizer(s), click here <https://www.meetup.com/Australian-OpenStack-User-Group/optout/?submit=true&_ms_unsub=true=orgBdcst> Meetup, POB 4668 #37895 NY NY USA 10163

Re: [Openstack-operators] [nova][blazar][scientific] advanced instance scheduling: reservations and preeemption - Forum session

On 2 May 2017 at 05:50, Jay Pipes wrote: > Masahito Muroi is currently marked as the moderator, but I will indeed be > there and happy to assist Masahito in moderating, no problem. The more the merrier :-). There is a rather unfortunate clash here with the Scientific-WG BoF

Re: [openstack-dev] [nova][blazar][scientific] advanced instance scheduling: reservations and preeemption - Forum session

On 2 May 2017 at 05:50, Jay Pipes wrote: > Masahito Muroi is currently marked as the moderator, but I will indeed be > there and happy to assist Masahito in moderating, no problem. The more the merrier :-). There is a rather unfortunate clash here with the Scientific-WG BoF

[Openstack-operators] [nova][blazar][scientific] advanced instance scheduling: reservations and preeemption - Forum session

h a temporal aspect to them (i.e. > allocations in the future). > > A separate system (hopefully Blazar) is needed to manage the time-based > associations to inventories of resources over a period in the future. > > Best, > -jay > >>> I'm not sure how the above i

[openstack-dev] [nova][blazar][scientific] advanced instance scheduling: reservations and preeemption - Forum session

h a temporal aspect to them (i.e. > allocations in the future). > > A separate system (hopefully Blazar) is needed to manage the time-based > associations to inventories of resources over a period in the future. > > Best, > -jay > >>> I'm not sure how the above i

Re: [Openstack-operators] [openstack-dev] [scientific][nova][cyborg] Special Hardware Forum session

Thanks Rochelle. I encourage everyone to dump thoughts into the etherpad (https://etherpad.openstack.org/p/BOS-forum-special-hardware - feel free to garden it as you go!) so we can have some chance of organising a coherent session. In particular it would be useful to know what is going to be most

Re: [openstack-dev] [scientific][nova][cyborg] Special Hardware Forum session

Thanks Rochelle. I encourage everyone to dump thoughts into the etherpad (https://etherpad.openstack.org/p/BOS-forum-special-hardware - feel free to garden it as you go!) so we can have some chance of organising a coherent session. In particular it would be useful to know what is going to be most

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

On 29 April 2017 at 01:46, Mike Dorman wrote: > I don’t disagree with you that the client side choose-a-server-at-random is > not a great load balancer. (But isn’t this roughly the same thing that > oslo-messaging does when we give it a list of RMQ servers?) For us it’s

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

On 29 April 2017 at 01:46, Mike Dorman wrote: > I don’t disagree with you that the client side choose-a-server-at-random is > not a great load balancer. (But isn’t this roughly the same thing that > oslo-messaging does when we give it a list of RMQ servers?) For us it’s

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

On 28 April 2017 at 21:17, Sean Dague <s...@dague.net> wrote: > On 04/28/2017 12:50 AM, Blair Bethwaite wrote: >> We at Nectar are in the same boat as Mike. Our use-case is a little >> bit more about geo-distributed operations though - our Cells are in >> different St

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

We at Nectar are in the same boat as Mike. Our use-case is a little bit more about geo-distributed operations though - our Cells are in different States around the country, so the local glance-apis are particularly important for caching popular images close to the nova-computes. We consider these

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

We at Nectar are in the same boat as Mike. Our use-case is a little bit more about geo-distributed operations though - our Cells are in different States around the country, so the local glance-apis are particularly important for caching popular images close to the nova-computes. We consider these

[Openstack-operators] [scientific][nova][cyborg] Special Hardware Forum session

Hi all, A quick FYI that this Forum session exists: https://www.openstack.org/summit/boston-2017/summit-schedule/events/18803/special-hardware (https://etherpad.openstack.org/p/BOS-forum-special-hardware) is a thing this Forum. It would be great to see a good representation from both the Nova

[openstack-dev] [scientific][nova][cyborg] Special Hardware Forum session

Hi all, A quick FYI that this Forum session exists: https://www.openstack.org/summit/boston-2017/summit-schedule/events/18803/special-hardware (https://etherpad.openstack.org/p/BOS-forum-special-hardware) is a thing this Forum. It would be great to see a good representation from both the Nova

Re: [Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

requests for the same > aggregate). > > Is this feasible? > > Tim > > On 04.04.17, 19:21, "Jay Pipes" <jaypi...@gmail.com> wrote: > > On 04/03/2017 06:07 PM, Blair Bethwaite wrote: > > Hi Jay, > > > > On 4 April 2017 at 00:20, Jay

Re: [Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

Hi Jay, On 5 April 2017 at 03:21, Jay Pipes <jaypi...@gmail.com> wrote: > On 04/03/2017 06:07 PM, Blair Bethwaite wrote: >> That's something of an oversimplification. A reservation system >> outside of Nova could manipulate Nova host-aggregates to "cordon off" &

Re: [Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

Hi Jay, On 4 April 2017 at 00:20, Jay Pipes wrote: > However, implementing the above in any useful fashion requires that Blazar > be placed *above* Nova and essentially that the cloud operator turns off > access to Nova's POST /servers API call for regular users. Because if

[Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

of resources (volumes, floating IPs, etc.). Software licenses can be another type. == (https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg) Cheers, -- Blair Bethwaite Senior HPC Consultant Monash eResearch Centre Monash University Room G26, 15 Innovation Walk, Clayton Campus Clayton

Re: [Openstack] [User-committee] Boston Forum - Formal Submission Now Open!

On 29 March 2017 at 18:10, Tom Fifield <t...@openstack.org> wrote: > On 29/03/17 14:10, Blair Bethwaite wrote: >> Just to confirm - the Forum will run Monday through Thursday, and >> presumably the session scheduling will be flexible to meet the needs of >> the leads/

Re: [Openstack-operators] backup to object store - tool recommendations

bug: > http://tracker.ceph.com/issues/19056 > > is anyone else hitting this ? > > Saverio > > 2017-03-27 22:11 GMT+02:00 John Dickinson <m...@not.mn>: > > > > > > On 27 Mar 2017, at 4:39, Blair Bethwaite wrote: > > > >> Hi all, > >>

Re: [Openstack] [User-committee] Boston Forum - Formal Submission Now Open!

Hi Melvin, Just to confirm - the Forum will run Monday through Thursday, and presumably the session scheduling will be flexible to meet the needs of the leads/facilitators? Cheers, b1airo On 21 Mar. 2017 6:56 am, "Melvin Hillsman" wrote: > Hey everyone! > > We have made

Re: [Openstack-operators] [User-committee] Boston Forum - Formal Submission Now Open!

Hi Melvin, Just to confirm - the Forum will run Monday through Thursday, and presumably the session scheduling will be flexible to meet the needs of the leads/facilitators? Cheers, b1airo On 21 Mar. 2017 6:56 am, "Melvin Hillsman" wrote: > Hey everyone! > > We have made

[Openstack-operators] [scientific] Reminder: IRC meeting Wednesday 0900

Hi all - We have a Scientific WG IRC meeting coming up in a few hours (Wednesday at 0900 UTC) in channel #openstack-meeting. All welcome. The agenda has one simple goal: Follow-up on and finalise Boston Forum proposals and assign leaders to submit. Cheers, -- Blair Bethwaite Senior HPC

[Openstack-operators] backup to object store - tool recommendations

Hi all, Does anyone have any recommendations for good tools to perform file-system/tree backups and restores to/from a (Ceph RGW-based) object store (Swift or S3 APIs)? Happy to hear about both FOSS and commercial options please. I'm interested in: 1) tools known to work or not work at all for a

Re: [Openstack-operators] Dealing with ITAR in OpenStack private clouds

Could just avoid Glance snapshots and indeed Nova ephemeral storage altogether by exclusively booting from volume with your ITAR volume type or AZ. I don't know what other ITAR regulations there might be, but if it's just what JM mentioned earlier then doing so would let you have ITAR and non-ITAR

Re: [Openstack-operators] Dealing with ITAR in OpenStack private clouds

On 22 March 2017 at 13:33, Jonathan Mills wrote: > > To what extent is it possible to “lock” a tenant to an availability zone, > to guarantee that nova scheduler doesn’t land an ITAR VM (and possibly the > wrong glance/cinder) into a non-ITAR space (and vice versa)… > Yes,

Re: [Openstack-operators] Dealing with ITAR in OpenStack private clouds

Dims, it might be overkill to introduce multi-Keystone + federation (I just quickly skimmed the PDF so apologies if I have the wrong end of it)? Jon, you could just have multiple cinder-volume services and backends. We do this in the Nectar cloud - each site has cinder AZs matching nova AZs. By

Re: [Openstack-operators] Flavors

Hi Chris, On 17 Mar. 2017 15:24, "Chris Friesen" <chris.frie...@windriver.com> wrote: On 03/16/2017 07:06 PM, Blair Bethwaite wrote: Statement: breaks bin packing / have to match flavor dimensions to hardware > dimensions. > Comment: neither of these ring true to me giv

Re: [Openstack-operators] Flavors

There have been previous proposals (and if memory serves, even some blueprints) for API extensions to allow this but they have apparently stagnated. On the face of it I think OpenStack should support this (more choice = win!) - doesn't mean that every cloud needs to use the feature. Is it worth

Re: [Openstack-operators] [User-committee] [scientific][scientific-wg] Reminder: IRC meeting Wednesday 0900

1st_2017 > [2] http://eavesdrop.openstack.org/#Scientific_Working_Group > > ___ > User-committee mailing list > user-commit...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > -- Blair Bethwaite Sen

[Openstack-operators] [User-committee] [scientific][scientific-wg] Scientific-WG IRC meeting Weds 0900 UTC

Hi all - We have a meeting coming up in about 12 hours: 2017-02-15 0900 UTC in channel #openstack-meeting This is substantively a repeat of last week's agenda for alternate timezones - Boston Declaration update from Martial - Hypervisor tuning update from Blair - Blair's experiences with RoCE

Re: [Openstack-operators] What would you like in Pike?

Hi Tim, We did wonder in last week's meeting whether quota management and nested project support (particularly which flows are most important) would be a good session for the Boston Forum...? Would you be willing to lead such a discussion? Cheers, On 19 January 2017 at 19:59, Tim Bell

Re: [Openstack-operators] [Glance] [Nova] Multiple backends / Qcow Derived Images

On 5 January 2017 at 19:47, Rui Chen wrote: > Ah, Adam, got your point, I found two related Nova blueprints that were > similar with your idea, > but there are not any activities about them from 2014, I hadn't dive deep > into these comments, > you might get some

Re: [Openstack-operators] [Glance] [Nova] Multiple backends / Qcow Derived Images

Hi Adam, On 5 January 2017 at 08:48, Adam Lawson wrote: > Just a friendly bump. To clarify, the ideas being tossed around are to host > QCOW images on each Compute node so the provisioning is faster (i.e. less > dependency on network connectivity to a shared back-end). I need

Re: [Openstack-operators] Analogs of EC2 dedicated instances & dedicated hosts?

Hi Conrad, On 20 December 2016 at 09:24, Kimball, Conrad wrote: > · Dedicated instances: an OpenStack tenant can deploy VM instances > that are guaranteed to not share a compute host with any other tenant (for > example, as the tenant I want physical

  1   2   >