[Openstack-operators] Defining the agenda for Kubernetes Ops on OpenStack forum session @ OpenStack Summit Boston

[Steve Gordon]

Hi all,

There will be a forum session at OpenStack Summit Boston next week on the topic 
of Kubernetes Ops on OpenStack on OpenStack. This session will be occurring on 
the Wednesday, May 10, at 1:50pm-2:30pm [1]. If you are an operator, developer, 
or other contributor attending OpenStack Summit who would like to participate 
in this session we would love to have you. We're working on framing the agenda 
for the session in this Etherpad:

https://etherpad.openstack.org/p/BOS-forum-kubernetes-ops-on-openstack

Feel free to add your own thoughts and look forward to seeing you there. If 
this email has caused you to ask yourself what the forum is and why you'd be 
there, I'd suggest starting here:

https://wiki.openstack.org/wiki/Forum

Thanks!

Steve

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18764/kubernetes-ops-on-openstack

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] FW: Can Windows 8, Windows Server 2003 and Windows Server 2008 be deployed on openstack kilo

[Steve Gordon]

- Original Message -
> From: "Adrian Vladu" <avl...@cloudbasesolutions.com>
> To: openstack-operators@lists.openstack.org
> Sent: Monday, April 3, 2017 7:50:01 AM
> Subject: [Openstack-operators] FW:  Can Windows 8, Windows Server 2003 and 
> Windows Server 2008 be deployed on
> openstack kilo
> 
> Hello,
> 
> Windows 8 and Windows Server 2008 Standard can be deployed on OpenStack with
> KVM (QEMU is not supported) as a hypervisor, if you have the required
> Windows CPU flags exposed to the virtual machine. “os-variant” is irrelevant
> in the OpenStack case, as this is a virt-install terminology.

I wouldn't go as far as to say this is irrelevant, in that you do still need to 
use the image properties (as covered in the blog Tim provided) to enable the 
Hyper-V enlightenment features that Libvirt/QEMU is able to support for Windows 
guests - which is in effect doing the same thing as using the equivalent 
os-variant values with virt-install.

-Steve

> OpenStack uses libvirt as a driver, and the cpu_model and cpu_flags are the
> important configuration options in this case. More info here:
> https://ask.cloudbase.it/question/1125/problem-booting-from-the-windows-2012-r2-image/
> 
> On OpenStack, you can use Cloudbase-init as the provisioning agent for the
> Windows instances in the same way you use cloud-init for the Linux ones:
> https://github.com/openstack/cloudbase-init
> 
> Windows Server 2003 is not supported anymore by MSFT:
> https://www.microsoft.com/en-us/cloud-platform/windows-server-2003
> AFAIK, Windows 2003 instances can work on KVM and the Fedora VirtIO drivers
> for this OS are still being offered in the stable releases:
> https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.126-2/
> 
> Thank you,
> Adrian Vladu
> From: Tim Bell [mailto:tim.b...@cern.ch]
> Sent: luni, 3 aprilie 2017 14:13
> To: openstack-operators
> <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>>
> Subject: Re: [Openstack-operators] Can Windows 8, Windows Server 2003 and
> Windows Server 2008 be deployed on openstack kilo
> 
> The metadata settings on the images is important to inform KVM of the guest
> operating system. We’ve put our experiences with a recent issue at
> https://openstack-in-production.blogspot.ch/2017/02/ostype-property-for-windows-images-on.html
> 
> Tim
> 
> From: "Van Leeuwen, Robert"
> <rovanleeu...@ebay.com<mailto:rovanleeu...@ebay.com>>
> Date: Monday, 3 April 2017 at 12:54
> To: Anwar Durrani <durrani.an...@gmail.com<mailto:durrani.an...@gmail.com>>,
> openstack-operators
> <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>>
> Subject: Re: [Openstack-operators] Can Windows 8, Windows Server 2003 and
> Windows Server 2008 be deployed on openstack kilo
> 
> Hello,
> 
> Its not really OpenStack related but it depends on your virtualization stack.
> Assuming its OpenStack with KVM:
> https://www.linux-kvm.org/page/Guest_Support_Status#Windows_Family
> 
> Note that you might have some interesting times with the licensing.
> From what I have understood (I am not a license specialist so take this with
> a pile of salt):
> You must have a Windows (datacenter?) license per hypervisor that can
> potentially run Windows instances.
> 
> Cheers,
> Robert
> 
> 
> From: Anwar Durrani <durrani.an...@gmail.com<mailto:durrani.an...@gmail.com>>
> Date: Monday, April 3, 2017 at 11:35 AM
> To: openstack-operators
> <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>>
> Subject: [Openstack-operators] Can Windows 8, Windows Server 2003 and Windows
> Server 2008 be deployed on openstack kilo
> 
> Hi Team,
> 
> I am curious to know if Windows 8 Pro, Windows Server 2003 Std and Windows
> Server 2008 Std can be deployed to openstack or not ? if Yes then what would
> be os-variant for the same ?
> 
> --
> Thanks & regards,
> Anwar M. Durrani
> +91-9923205011
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Memory usage of guest vms, ballooning and nova

[Steve Gordon]

- Original Message -
> From: "Jean-Philippe Methot" 
> To: "Edmund Rhudy" 
> Cc: openstack-operators@lists.openstack.org
> Sent: Thursday, March 23, 2017 3:49:26 PM
> Subject: Re: [Openstack-operators] Memory usage of guest vms, ballooning and 
> nova
> 
> 
> On 2017-03-23 15:15, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote:
> > What sort of memory overcommit value are you running Nova with? The
> > scheduler looks at an instance's reservation rather than how much
> > memory is actually being used by QEMU when making a decision, as far
> > as I'm aware (but please correct me if I am wrong on this point). If
> > the HV has 128GB of memory, the instance has a reservation of 96GB,
> > you have 16GB reserved via reserved_host_memory_mb,
> > ram_allocation_ratio is set to 1.0, and you try to launch an instance
> > from a flavor with 32GB of memory, it will fail to pass RamFilter in
> > the scheduler and the scheduler will not consider it a valid host for
> > placement. (I am assuming you are using FilterScheduler still, as I
> > know nothing about the new placement API or what parts of it do and
> > don't work in Newton.)
> The overcommit value is set to 1.5 in the scheduler. It's not the
> scheduler that was preventing the instance from being provisionned, it
> was qemu returning that there was not enough ram when libvirt was trying
> to provision the instance (that error was not handled well by openstack,
> btw, but that's something else). So the instance does pass every filter.
> It just ends up in error when getting provisioned in the compute node
> because of a lack of ram, with the actual full error message only
> visible in the QEMU logs.
> > As far as why the memory didn't automatically get reclaimed, maybe KVM
> > will only reclaim empty pages and memory fragmentation in the guest
> > prevented it from doing so? It might also not actively try to reclaim
> > memory unless it comes under pressure to do so, because finding empty
> > pages and returning them to the host may be a somewhat time-consuming
> > operation.
> 
> That's entirely possible, but according to the doc, libvirt is supposed
> to have a memory balloon function that does the operation of reclaiming
> empty pages from guest processes, or so I understand. Now, how this
> function works is not exactly clear to me, or even if nova uses it or
> not. Another user suggested it might not be automatic, which is in
> accordance to what you're conjecturing.

As a general rule Libvirt provides an interface to facilitate various actions 
on the guest, but does not perform them without intervention - that is 
generally it needs to be triggered to do something either by a management layer 
(OpenStack, oVirt, virt-manager, Boxes, etc.) or explicit call from the 
operator (e.g. via virsh).

In this case as Chris noted while the memory stats are exposed by default, and 
while Libvirt exposes an API for interacting with the balloon, there is no 
process in Nova currently - or commonly deployed with it - that will actually 
exercise the ballooning mechanism to expand/contract the memory balloon. In 
oVirt/RHEV the traditional way to do it was using Memory Overcommitt Manager 
(MOM) to define and apply policies for managing it - the guest also needs to 
have a driver for the virtio balloon device IIRC. 

Such things have been proposed in the past [2] in OpenStack but never made it 
to implementation to my knowledge though as you've discovered it still seems 
like something that is generally desirable.

Thanks,

Steve

[1] http://www.ovirt.org/develop/projects/mom/
[2] https://blueprints.launchpad.net/nova/+spec/libvirt-memory-ballooning


> > From: jp.met...@planethoster.info
> > Subject: Re: [Openstack-operators] Memory usage of guest vms,
> > ballooning and nova
> >
> > Hi, This is indeed linux, CentOS 7 to be more precise, using
> > qemu-kvm as hypervisor. The used ram was in the used column. While
> > we have made adjustments by moving and resizing the specific guest
> > that was using 96 GB (verified in top), the ram usage is still
> > fairly high for the amount of allocated ram. Currently the ram
> > usage looks like this : total used free shared buff/cache
> > available Mem: 251G 190G 60G 42M 670M 60G Swap: 952M 707M 245M I
> > have 188.5GB of ram allocated to 22 instances on this node. I
> > believe it's unrealistic to think that all these 22 instances have
> > cached/are using up all their ram at this time. On 2017-03-23
> > 13:07, Kris G. Lindgren wrote: > Sorry for the super stupid
> > question. > > But if this is linux are you sure that the memory is
> > not actually being consumed via buffers/cache? > > free -m > total
> > used free shared buff/cache available > Mem: 128751 27708 2796
> > 4099 98246 96156 > Swap: 8191 0 8191 > > Shows that of 128GB 27GB
> > is used, but buffers/cache consumes 98GB of ram. > >
> > 

Re: [Openstack-operators] [openstack-dev] [nova] Next minimum libvirt version

[Steve Gordon]

- Original Message -
> From: "Matt Riedemann" <mriede...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-...@lists.openstack.org>,
> openstack-operators@lists.openstack.org
> Sent: Thursday, February 9, 2017 6:29:22 PM
> Subject: [openstack-dev] [nova] Next minimum libvirt version
> 
> Since danpb hasn't been around I've sort of forgotten about this, but we
> should talk about bumping the minimum required libvirt version in nova.
> 
> Currently it's 1.2.1 and the next was set to 1.2.9.
> 
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
> had 1.2.2).
> 
> If we move to require 1.2.9 that effectively kills 14.04 support for
> devstack + libvirt on master, which is probably OK.

This would also kill off RHEL/CentOS 7.1 support but that would also seem to be 
OK at this point.

> There is also the distro support wiki [1] which hasn't been updated in
> awhile.

I've added the details I have for Fedora 25 and RHEL/CentOS 7.3, TL;DR:

Fedora 25:
Libvirt 2.2.0
Qemu 2.7.1
Libguestfs 1.34.3

RHEL 7.3:
Libvirt 2.0.0
Qemu 2.6.0
Libguestfs 1.32.7
 

> I'm wondering if 1.2.9 is a safe move for the next required minimum
> version and if so, does anyone have ideas on the next required version
> after that?
> 
> I'm hoping some of the Red Hat people can chime in here.

I just play someone intelligent on TV so adding Sahid and Vladik who might be 
better placed to comment in Dan's absence.

Thanks,

Steve

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] CentOS 7.3 libvirt appears to be broken for virtio-scsi and ceph with cephx auth

[Steve Gordon]

- Original Message -
> From: "Mike Smith" <mism...@overstock.com>
> To: "Mike Lowe" <joml...@iu.edu>
> Cc: "OpenStack Operators" <openstack-operators@lists.openstack.org>
> Sent: Wednesday, December 21, 2016 3:32:46 PM
> Subject: Re: [Openstack-operators] CentOS 7.3 libvirt appears to be broken 
> for virtio-scsi and ceph with cephx auth
> 
> We had a similar surprise updating our lab to CentOS 7.3.  Even Openstack
> aside, libvirt itself on 7.3 couldn’t recognize any of our defined VMs -
> kept giving a message of “ No path to ‘ ‘ “ just trying to do a ‘virsh
> list’.   

Was discussing this one with Neil on openstack-dev here:

http://lists.openstack.org/pipermail/openstack-dev/2016-December/109080.html

Which would seem to have been filed as:

https://bugs.launchpad.net/nova/+bug/1649527

Thanks,

Steve

> We ended up adding an additional yum repo definition pointing to
> the older 7.2 repo and doing a yum history rollback and we’ve stopped
> pointing to the 7.3 repo altogether.  We had other problems with Cent 7.3 as
> well, unrelated to virtualization.
> 
> Are others out there successfully using CentOS 7.3 right now with libvirt or
> is everyone experiencing this similar pain.
> 
> That’s frightening that the virtio-scsi support is broken as well.
> 
> Mike Smith
> Lead Cloud Systems Architect
> Overstock.com<http://overstock.com>
> 
> 
> 
> On Dec 20, 2016, at 9:57 AM, Mike Lowe
> <joml...@iu.edu<mailto:joml...@iu.edu>> wrote:
> 
> I got a rather nasty surprise upgrading from CentOS 7.2 to 7.3.  As far as I
> can tell the libvirt 2.0.0 that ships with 7.3 doesn’t behave the same way
> as the 1.2.17 that ships with 7.2 when using ceph with cephx auth during
> volume attachment using virtio-scsi.  It looks like it fails to add the
> cephx secret.  The telltale signs are "No secret with id
> 'scsi0-0-0-1-secret0’” in the /var/log/libvirt/qemu instance logs.  I’ve
> filed a bug here https://bugzilla.redhat.com/show_bug.cgi?id=1406442 and
> there is a libvirt mailing list  thread about a fix for libvirt 2.5.0 for
> what looks like this same problem
> https://www.redhat.com/archives/libvir-list/2016-October/msg00396.html  I’m
> out of ideas for workarounds having had kind of a disastrous attempt at
> downgrading to libvirt 1.2.17, so if anybody has any suggestions I’m all
> ears.
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Steve Gordon]

- Original Message -
> From: "George Zhao" <geo...@hd.net.nz>
> To: "Steve Gordon" <sgor...@redhat.com>
> Cc: openstack-operators@lists.openstack.org
> Sent: Wednesday, December 14, 2016 3:01:11 PM
> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and 
> qemu-kvm(-ev) 2.6.0
> 
> I'm using kvm, just temporally changed to host-passthrough, waiting on
> qemu-kvm-ev-2.6

Looks like it's up now, I see qemu-kvm-ev-2.6.0-27.1.el7.x86_64.rpm and friends 
in:

http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/

Thanks,

Steve

> On 12/14/2016 05:22 PM, Steve Gordon wrote:
> > - Original Message -
> >> From: "George Zhao" <geo...@hd.net.nz>
> >> To: openstack-operators@lists.openstack.org
> >> Sent: Tuesday, December 13, 2016 7:44:02 PM
> >> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and
> >> qemu-kvm(-ev) 2.6.0
> >>
> >> yup, I have to use cpu_mode=host-passthrough to get vms booting up.
> >
> > Are you using virt_type="qemu" or virt_type="kvm"? If the later you should
> > be OK to switch back to host-model once the qemu-kvm-ev-2.6.0 build is
> > available.
> >
> > Thanks,
> >
> > Steve
> >
> >> On 12/14/2016 12:13 PM, David Moreau Simard wrote:
> >>> Hi,
> >>>
> >>> CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> >>> was shipped as part of this release if you have the CentOS
> >>> Virtualization SIG repositories enabled.
> >>>
> >>> If you're using RDO >= Newton, you will have this repository enabled.
> >>> It was not yet enforced in the Mitaka release so you might or might
> >>> not have it, depending on your deployment.
> >>> Older releases of OpenStack may also be affected but they are not
> >>> proactively tested anymore due to EOL.
> >>>
> >>> There is currently a known issue when using the following
> >>> configuration in nova for compute:
> >>> ==
> >>> virt_type=qemu
> >>> cpu_mode=host-model
> >>> ==
> >>>
> >>> This combination will yield in failed attempts at creating instances
> >>> and you will see errors like these in nova-compute.log [1] or the
> >>> libvirt logs [2].
> >>> The problem boils down to libvirt trying to pass a cpu extension that
> >>> is unknown to qemu:
> >>> ==
> >>> qemu-kvm: CPU feature arat not found
> >>> ==
> >>>
> >>> There is a bugzilla [3] for this issue but in the meantime users are
> >>> encouraged to work around the issue by setting "cpu_mode=none" if they
> >>> are using the qemu (not KVM) hypervisor.
> >>> Please note that Nova defaults the 'cpu_mode' parameter to
> >>> 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> >>> 'virt_type' is 'qemu' so if you're running into this issue, you will
> >>> need to explicitely configure it.
> >>>
> >>> [1]:
> >>> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> >>> [2]:
> >>> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> >>> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> >>> [4]:
> >>> http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> >>>
> >>> David Moreau Simard
> >>> Senior Software Engineer | Openstack RDO
> >>>
> >>> dmsimard = [irc, github, twitter]
> >>>
> >>> ___
> >>> OpenStack-operators mailing list
> >>> OpenStack-operators@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>>
> >>
> >> ___
> >> OpenStack-operators mailing list
> >> OpenStack-operators@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Steve Gordon]

- Original Message -
> From: "Steve Gordon" <sgor...@redhat.com>
> To: "David Moreau Simard" <d...@redhat.com>
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-...@lists.openstack.org>, "OpenStack
> Operators" <openstack-operators@lists.openstack.org>
> Sent: Tuesday, December 13, 2016 11:06:48 PM
> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and  
> qemu-kvm(-ev) 2.6.0
> 
> - Original Message -
> > From: "David Moreau Simard" <d...@redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-...@lists.openstack.org>, "OpenStack
> > Operators" <openstack-operators@lists.openstack.org>
> > Sent: Tuesday, December 13, 2016 6:13:12 PM
> > Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and
> > qemu-kvm(-ev) 2.6.0
> > 
> > Hi,
> > 
> > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> > was shipped as part of this release if you have the CentOS
> > Virtualization SIG repositories enabled.
> 
> Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't*
> shipped yet? E.g. it's not in:
> 
> http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
> 
> Hence the mismatch is created because the CentOS repos contain Libvirt 2.0.0
> but not a matching qemu-kvm-ev build (yet).
> 
> Thanks,
> 
> Steve

Just to elaborate on the above, for there are two potential scenarios where you 
will potentially hit "qemu-kvm: CPU feature arat not found":

1) When using virt_type="qemu", CentOS 7 1611 (Libvirt 2.0.0). In this case the 
corrective action for now appears to be as David noted, this is the scenario 
that is most likely hitting the noted CI jobs.

2) When using virt_type="kvm", CentOS 7 1611 (Libvirt 2.0.0) with qemu-kvm-ev < 
2.6.0. In this case the corrective action based on 
https://bugzilla.redhat.com/show_bug.cgi?id=1371617 is actually to install 
qemu-kvm-ev 2.6.0, this is the scenario most likely to hit users.

I wanted to highlight this because David is (quite rightly) focusing on 
resolving (1) to get the CI jobs impacted moving, but it's quite possible many 
users will actually be hitting (2).

Thanks,

Steve

> > If you're using RDO >= Newton, you will have this repository enabled.
> > It was not yet enforced in the Mitaka release so you might or might
> > not have it, depending on your deployment.
> > Older releases of OpenStack may also be affected but they are not
> > proactively tested anymore due to EOL.
> > 
> > There is currently a known issue when using the following
> > configuration in nova for compute:
> > ==
> > virt_type=qemu
> > cpu_mode=host-model
> > ==
> > 
> > This combination will yield in failed attempts at creating instances
> > and you will see errors like these in nova-compute.log [1] or the
> > libvirt logs [2].
> > The problem boils down to libvirt trying to pass a cpu extension that
> > is unknown to qemu:
> > ==
> > qemu-kvm: CPU feature arat not found
> > ==
> > 
> > There is a bugzilla [3] for this issue but in the meantime users are
> > encouraged to work around the issue by setting "cpu_mode=none" if they
> > are using the qemu (not KVM) hypervisor.
> > Please note that Nova defaults the 'cpu_mode' parameter to
> > 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> > 'virt_type' is 'qemu' so if you're running into this issue, you will
> > need to explicitely configure it.
> > 
> > [1]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> > [2]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> > [4]:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> > 
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> > 
> > dmsimard = [irc, github, twitter]
> > 
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > 
> 
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Steve Gordon]

- Original Message -
> From: "George Zhao" <geo...@hd.net.nz>
> To: openstack-operators@lists.openstack.org
> Sent: Tuesday, December 13, 2016 7:44:02 PM
> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and 
> qemu-kvm(-ev) 2.6.0
> 
> yup, I have to use cpu_mode=host-passthrough to get vms booting up.

Are you using virt_type="qemu" or virt_type="kvm"? If the later you should be 
OK to switch back to host-model once the qemu-kvm-ev-2.6.0 build is available.

Thanks,

Steve

> On 12/14/2016 12:13 PM, David Moreau Simard wrote:
> > Hi,
> >
> > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> > was shipped as part of this release if you have the CentOS
> > Virtualization SIG repositories enabled.
> >
> > If you're using RDO >= Newton, you will have this repository enabled.
> > It was not yet enforced in the Mitaka release so you might or might
> > not have it, depending on your deployment.
> > Older releases of OpenStack may also be affected but they are not
> > proactively tested anymore due to EOL.
> >
> > There is currently a known issue when using the following
> > configuration in nova for compute:
> > ==
> > virt_type=qemu
> > cpu_mode=host-model
> > ==
> >
> > This combination will yield in failed attempts at creating instances
> > and you will see errors like these in nova-compute.log [1] or the
> > libvirt logs [2].
> > The problem boils down to libvirt trying to pass a cpu extension that
> > is unknown to qemu:
> > ==
> > qemu-kvm: CPU feature arat not found
> > ==
> >
> > There is a bugzilla [3] for this issue but in the meantime users are
> > encouraged to work around the issue by setting "cpu_mode=none" if they
> > are using the qemu (not KVM) hypervisor.
> > Please note that Nova defaults the 'cpu_mode' parameter to
> > 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> > 'virt_type' is 'qemu' so if you're running into this issue, you will
> > need to explicitely configure it.
> >
> > [1]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> > [2]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> > [4]:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> >
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Steve Gordon]

- Original Message -
> From: "David Moreau Simard" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" 
> Sent: Tuesday, December 13, 2016 6:13:12 PM
> Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and  
> qemu-kvm(-ev) 2.6.0
> 
> Hi,
> 
> CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> was shipped as part of this release if you have the CentOS
> Virtualization SIG repositories enabled.

Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't* shipped 
yet? E.g. it's not in:

http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/

Hence the mismatch is created because the CentOS repos contain Libvirt 2.0.0 
but not a matching qemu-kvm-ev build (yet).

Thanks,

Steve

> If you're using RDO >= Newton, you will have this repository enabled.
> It was not yet enforced in the Mitaka release so you might or might
> not have it, depending on your deployment.
> Older releases of OpenStack may also be affected but they are not
> proactively tested anymore due to EOL.
> 
> There is currently a known issue when using the following
> configuration in nova for compute:
> ==
> virt_type=qemu
> cpu_mode=host-model
> ==
> 
> This combination will yield in failed attempts at creating instances
> and you will see errors like these in nova-compute.log [1] or the
> libvirt logs [2].
> The problem boils down to libvirt trying to pass a cpu extension that
> is unknown to qemu:
> ==
> qemu-kvm: CPU feature arat not found
> ==
> 
> There is a bugzilla [3] for this issue but in the meantime users are
> encouraged to work around the issue by setting "cpu_mode=none" if they
> are using the qemu (not KVM) hypervisor.
> Please note that Nova defaults the 'cpu_mode' parameter to
> 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> 'virt_type' is 'qemu' so if you're running into this issue, you will
> need to explicitely configure it.
> 
> [1]:
> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> [2]:
> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> [4]:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Pinning Guest vCPUs to Host pCPUs

[Steve Gordon]

- Original Message -
> From: "Benyatou Hamza" 
> To: OpenStack-operators@lists.openstack.org
> 
> Hi,
> 
> I established a mapping between virtual CPU to the physical core following
> this Mirantis guide [1], I went through it successfully but the problem I
> have is that I am only able to launch one instance regardless of the the
> number of vCPUs specified in the Flavor (2,4,16.).
> 
> Have you implemented this option before ?

Hi Hamza,

Do you have debug logging from the scheduling attempt? Output from `virsh 
capabilities` might be of help too.

Thanks,

Steve

> Thank you
> 
> Hamza
> 
> https://www.mirantis.com/blog/mirantis-openstack-7-0-nfvi-deployment-guide-numacpu-pinning/

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Telco Working Group meetings suspended

[Steve Gordon]

Hi all,

As discussed at this week's meeting [1] all user stories have now been moved 
from telcowg-usecases to openstack-userstories and we will be suspending the 
Telco Working Group meetings moving forward. Participants are encouraged to 
attend one of the two weekly Product Working Group meeting times [2] to discuss 
and advocate for the relevant user stories going forward. Please also note that 
there is a product-wg mailing list [3] for discussion of same.

For those attending summit please note these collaboration sessions:

* OPNFV and OpenStack Collaboration BoF [4]
* Ops: NFV/Telco [5]

Thanks,

Steve

[1] 
http://eavesdrop.openstack.org/meetings/telcowg/2016/telcowg.2016-04-13-14.01.html
[2] http://eavesdrop.openstack.org/#OpenStack_Product_WG
[3] http://lists.openstack.org/pipermail/product-wg/
[4] 
https://www.openstack.org/summit/austin-2016/summit-schedule/events/7510?goback=1
[5] 
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9522?goback=1


- Original Message -
> From: "Steve Gordon" <sgor...@redhat.com>
> 
> - Original Message -
> > From: "Calum Loudon" <calum.lou...@metaswitch.com>
> > 
> > Thanks Steve
> > 
> > I agree with moving to the PWG.
> > 
> > On that topic, do you know what's happened to some of the user stories we
> > proposed, specifically https://review.openstack.org/#/c/290060/ and
> > https://review.openstack.org/#/c/290347/?  Neither shows up in
> > https://review.openstack.org/#/q/status:open+project:openstack/openstack-user-stories
> 
> This query includes status:open, and those two reviews were merged already so
> they don't show up.
> 
> > but there is a https://review.openstack.org/#/c/290991/ which seems to be a
> > copy of https://review.openstack.org/#/c/290060/ with the template help
> > text
> > added back in and no mention of the original?
> 
> From Shamail's comment in 290991:
> 
> This change should be used to discuss and refine the concept. Can the
> user story owner please make a minor change to show ownership?
> 
> Basically they opened new reviews with a minor change to trigger further
> discussion. I'm not in love with this approach versus just discussing it on
> the original move request but it is the way it is being done for now. W.r.t.
> 290060 I believe you probably meant to include another link but I imagine
> the situation is the same.
> 
> -Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] Telco Working Group meeting for Wednesday April 6th CANCELLED

[Steve Gordon]

- Original Message -
> From: "Calum Loudon" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> ,
> "openstack-operators" 
> Sent: Wednesday, April 6, 2016 6:09:16 AM
> Subject: Re: [openstack-dev] Telco Working Group meeting for Wednesday April  
> 6th CANCELLED
> 
> Thanks Steve
> 
> I agree with moving to the PWG.
> 
> On that topic, do you know what's happened to some of the user stories we
> proposed, specifically https://review.openstack.org/#/c/290060/ and
> https://review.openstack.org/#/c/290347/?  Neither shows up in
> https://review.openstack.org/#/q/status:open+project:openstack/openstack-user-stories

This query includes status:open, and those two reviews were merged already so 
they don't show up.

> but there is a https://review.openstack.org/#/c/290991/ which seems to be a
> copy of https://review.openstack.org/#/c/290060/ with the template help text
> added back in and no mention of the original?

>From Shamail's comment in 290991:

This change should be used to discuss and refine the concept. Can the user 
story owner please make a minor change to show ownership?

Basically they opened new reviews with a minor change to trigger further 
discussion. I'm not in love with this approach versus just discussing it on the 
original move request but it is the way it is being done for now. W.r.t. 290060 
I believe you probably meant to include another link but I imagine the 
situation is the same.

-Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Telco Working Group meeting for Wednesday April 6th CANCELLED

[Steve Gordon]

Hi all,

I will be on a flight during the meeting slot for Wednesday April 6th and have 
been unable to source someone else to run the meeting, as a result it is 
canceled. I would also like to highlight that at this point I believe all of 
the active Telco Working Group use cases have been submitted/moved to the 
Product Working Group repository. The Product Working Group also now has an 
alternative [1][2] timeslot available for those who were unable to make the 
PDT/EDT friendly time used for the Monday session. Product Working Group 
meetings are now at:

  Weekly on Monday at 2100 UTC in #openstack-meeting-alt (IRC webclient)
  Weekly on Tuesday at 0200 UTC in #openstack-meeting-alt (IRC webclient) 

Going forward I would like to suggest suspending the weekly Telco Working Group 
meetings (or having them on a less frequent basis) with a view to concentrating 
on attending the Product Working Group calls to assist with prioritization 
discussions, gap analysis, and next steps.

Thanks,

Steve

[1] http://lists.openstack.org/pipermail/product-wg/2016-April/001056.html
[2] http://eavesdrop.openstack.org/#OpenStack_Product_WG

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nfv][telco] Telco Working Group meeting for Wednesday Marcch 16th CANCELLED

[Steve Gordon]

Hi all,

There will be no Telco Working Group [1] meeting for Wednesday March 16th as we 
will be lacking a chair.

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Setting affinity based on instance type

[Steve Gordon]

- Original Message -
> From: "Adam Lawson" 
> To: "Silence Dogood" 
> 
> Mathieu,
> 
> Blame it on my scattered brain but I'm now curious. How would this be
> approached practically speaking? I.e. how would ram_weight_multiplier
> enable the scenario I mentioned in my earliest post ?
> 
> //adam

It's specific to the scenario in Silence's post, which Mathiew was replying to 
directly.

-Steve

> 
> *Adam Lawson*
> 
> On Thu, Mar 3, 2016 at 10:43 AM, Silence Dogood 
> wrote:
> 
> > cool!
> >
> > On Thu, Mar 3, 2016 at 1:39 PM, Mathieu Gagné  wrote:
> >
> >> On 2016-03-03 12:50 PM, Silence Dogood wrote:
> >> > We did some early affinity work and discovered some interesting problems
> >> > with affinity and scheduling. =/  by default openstack used to ( may
> >> > still ) deploy nodes across hosts evenly.
> >> >
> >> > Personally, I think this is a bad approach.  Most cloud providers stack
> >> > across a couple racks at a time filling them then moving to the next.
> >> > This allows older equipment to age out instances more easily for removal
> >> > / replacement.
> >> >
> >> > The problem then is, if you have super large capacity instances they can
> >> > never be deployed once you've got enough tiny instances deployed across
> >> > the environment.  So now you are fighting with the scheduler to ensure
> >> > you have deployment targets for specific instance types ( not very
> >> > elastic / ephemeral ).  goes back to the wave scheduling model being
> >> > superior.
> >> >
> >> > Anyways we had the braindead idea of locking whole physical nodes out
> >> > from the scheduler for a super ( full node ) instance type.  And I
> >> > suppose you could do this with AZs or regions if you really needed to.
> >> > But, it's not a great approach.
> >> >
> >> > I would say that you almost need a wave style scheduler to do this sort
> >> > of affinity work.
> >> >
> >>
> >> You can already do it with the RAMWeigher using the
> >> ram_weight_multiplier config:
> >>
> >>   Multiplier used for weighing ram.  Negative
> >>   numbers mean to stack vs spread.
> >>
> >> Default is 1.0 which means spread.
> >>
> >> --
> >> Mathieu

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to install magnum?

[Steve Gordon]

- Original Message -
> From: "Mike Smith" <mism...@overstock.com>
> To: "Hongbin Lu" <hongbin...@gmail.com>
> 
> Thanks Hongbin.  I am also willing to get involved to help write the
> operator/production-oriented documentation for Magnum.  I’d like to see the
> Magnum project work with the RDO folks to get Magnum RPMs into the RDO
> distribution so that it is more accessible to operators of package-based
> distros.
> 
> Mike Smith
> Lead Cloud Systems Architect
> Overstock.com<http://Overstock.com>

FWIW the folks from CERN had been working with us on this, the relevant 
tracking bugs are here:

openstack-magnum: https://bugzilla.redhat.com/show_bug.cgi?id=1292794
python-magnumclient: https://bugzilla.redhat.com/show_bug.cgi?id=1286772

I just bumped the first request as I think it is good to go but someone missed 
setting a flag to initiate the next step of the process.

Thanks,

Steve


> On Feb 17, 2016, at 10:10 AM, Hongbin Lu
> <hongbin...@gmail.com<mailto:hongbin...@gmail.com>> wrote:
> 
> Mike,
> 
> I am sorry that it is currently lack of installation guide for Magnum. I have
> created a blueprint [1] for creating one. It will be picked up if someone
> interests to work on that.
> 
> If you need a guide right away, maybe you could reference this one [2]. This
> guide is not targeting for operators, but it might inspire the installation
> steps.
> 
> [1] https://blueprints.launchpad.net/magnum/+spec/magnum-installation-guide
> [2] http://docs.openstack.org/developer/magnum/dev/dev-manual-devstack.html
> 
> Best regards,
> Hongbin
> 
> On Tue, Feb 9, 2016 at 11:30 AM, Mike Perez
> <thin...@gmail.com<mailto:thin...@gmail.com>> wrote:
> On 09:48 Nov 03, Mike Perez wrote:
> > On 18:51 Oct 28, Mike Perez wrote:
> > > On 12:35 Oct 28, JJ Asghar wrote:
> > > > On 10/28/15 10:35 AM, Mike Perez wrote:
> > > > > On 14:09 Oct 16, hittang wrote:
> > > > >> Hello,everynoe. Can anybody help me for installing magnum? I have an
> > > > >> openstack installtion,which has one controller node, one network
> > > > >> node, and
> > > > >> server computes node. Now, I want to install magnum, and  to manage
> > > > >> docker
> > > > >> containers with.
> > > > >
> > > > > I was not able to find this information in the Magnum wiki [1],
> > > > > except for the
> > > > > developer quick start. Doing a quick search, other related threads
> > > > > point
> > > > > to the dev docs for installation, which is developer centric.
> > > > >
> > > > > Adrian, is this something missing in documentation, or did we miss
> > > > > it?
> > > > >
> > > > > [1] - https://wiki.openstack.org/wiki/Magnum
> > > > >
> > > >
> > > > Yep, this would be awesome. It's neat to see the integrations with
> > > > DevStack, but getting it to work in a "prod" environment seems
> > > > confusing
> > > > at best.
> > > >
> > > > I've attempted a couple times now, and failed each one. I'm more then
> > > > willing to help debug/QA the docs that yall decide to put together.
> > >
> > > Since we're doing so much talk about Magnum in Keynotes for the Tokyo
> > > OpenStack
> > > summit, and there are install confusion, we should probably work on that.
> > > I have raised this in the next meeting [1], which I will bring up this
> > > thread
> > > in.
> > >
> > > [1] -
> > > https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-11-03_1600_UTC
> >
> > During the Magnum meeting today [1] it seems like this was previously
> > discussed
> > at the last Magnum midcycle to improve this documentation in the Mitaka
> > release
> > [2].
> >
> > [1] -
> > http://eavesdrop.openstack.org/meetings/containers/2015/containers.2015-11-03-16.01.log.html#l-150
> > [2] - https://etherpad.openstack.org/p/magnum-mitaka-summit-meetup
> 
> Hey Adrian,
> 
> Can we get an update on the install guide for Magnum? I was looking through
> OpenStack manuals repo and didn't find anything up for review. We ran into
> each
> other recently, and you mentioned someone who was working on this effort, so
> please cc them to this thread. Thanks!
> 
> --
> Mike Perez
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openst

[Openstack-operators] [NFV][Telco] Telco Working Group Meeting for February 10th 2016 - CANCELLED

[Steve Gordon]

Hi all,

Unfortunately today's meeting of the Telco Working Group [1] is canceled, my 
apologies for the late notice!

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [telcowg][nvf][midcycle] Manchester ops nfv

[Steve Gordon]

- Original Message -
> From: "Curtis" 
> To: openstack-operators@lists.openstack.org
> 
> Hi,
> 
> Is there any interest in having an NFV related component to the
> Manchester Midcycle operators meetup? I notice that there is nothing
> related in the etherpad (unless I just missed it). I would be very
> interested in being able to talk with other operators who are working
> on NFV or related projects.
> 
> Thanks,
> Curtis.

Hi Curtis,

We hadn't planned/proposed anything under the auspices of the working group, 
lately we have mainly been focused on pushing documented user stories into the 
product working group and/or working directly with OPNFV folks. We were also 
conscious of the fact that we have had a telco/nfv session at the last few 
mid-cycles and that there are other deserving operator-focussed topics that 
were waiting in the wings for a slot. That's not to say folks shouldn't have a 
BOF or the like if there are enough attending though!

In terms of Austin summit planning we are not requesting dedicated telco 
working group space but are instead looking to join in with the OPNFV folks and 
try and foster relationships between the two communities since we share a lot 
of common interests (and members for that matter).

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nfv][telcowg] Telco Working Group meeting cancellations - Dec 23rd, Dec 30, Jan 6

[Steve Gordon]

Hi all,

We discussed in today's meeting and confirmed that we will skip our schedule 
meetings for:

* December 23rd
* December 30th
* January 6th

We will reconvene on January 13th, I will send a reminder close to that date.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Product] [nfv][telco][product] Future of telco working group and weekly meeting reminder

[Steve Gordon]

- Original Message -
> From: "Shamail" <itzsham...@gmail.com>
> To: "Steve Gordon" <sgor...@redhat.com>
> 
> Hi Steve,
> 
> > On Nov 18, 2015, at 6:39 AM, Steve Gordon <sgor...@redhat.com> wrote:
> > 
> > Hi all,
> > 
> > Back in Vancouver [1] we began discussing the growing overlap between OPNFV
> > requirements projects and the current mission of the telco working group.
> > During this period the product working group, also in part focused on
> > recording and prioritizing user stories, has also been hitting its straps.
> > As we have recently lost a couple of core members of the telco working
> > group particularly on the technical side due to role changes etc. I think
> > it is time to roll its activities into these efforts.
> > 
> > With that in mind I would like to propose:
> > 
> > * Submitting the existing telcowg-usecases to the openstack-user-stories
> > repository
> > * Engaging within the product working group (assuming they will have us ;))
> > as owners of these user stories
> This is a very similar model to what the enterprise WG did recently as well.
> Please let me know if I can do anything to help with the transition of the
> user stories.
> > 
> > There is of course still a need to actually *implement* the requirements
> > exposed by these user stories but I am hopeful that together we can work
> > through a common process for this rather than continuing to attack it
> > separately. I would personally still like to see greater direct engagement
> > from service providers, but it seems like OPNFV and/or the OpenStack User
> > Committee [2] itself might be the right place for this going forward.
> > 
> > I'd like to discuss this proposal further in the weekly meeting. This
> > week's Telco Working Group meeting is scheduled for Wednesday the 18th at
> > 1400 UTC. As always the agenda etherpad is here:
> > 
> >   https://etherpad.openstack.org/p/nfv-meeting-agenda
> Would it make sense for someone else (besides yourself :)) from the Product
> WG to join this session for Q as well?

The more the merrier as they say... ;)

-Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nfv][telco][product] Future of telco working group and weekly meeting reminder

[Steve Gordon]

Hi all,

Back in Vancouver [1] we began discussing the growing overlap between OPNFV 
requirements projects and the current mission of the telco working group. 
During this period the product working group, also in part focused on recording 
and prioritizing user stories, has also been hitting its straps. As we have 
recently lost a couple of core members of the telco working group particularly 
on the technical side due to role changes etc. I think it is time to roll its 
activities into these efforts.

With that in mind I would like to propose:

* Submitting the existing telcowg-usecases to the openstack-user-stories 
repository
* Engaging within the product working group (assuming they will have us ;)) as 
owners of these user stories

There is of course still a need to actually *implement* the requirements 
exposed by these user stories but I am hopeful that together we can work 
through a common process for this rather than continuing to attack it 
separately. I would personally still like to see greater direct engagement from 
service providers, but it seems like OPNFV and/or the OpenStack User Committee 
[2] itself might be the right place for this going forward.

I'd like to discuss this proposal further in the weekly meeting. This week's 
Telco Working Group meeting is scheduled for Wednesday the 18th at 1400 UTC. As 
always the agenda etherpad is here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Thanks all!

Steve

[1] https://etherpad.openstack.org/p/YVR-ops-telco
[2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] How to use the supported nova V2.1 and microversions in rdo (Liberty) deploy?

[Steve Gordon]

- Original Message -
> From: "quan hping" 
> To: "openstack-operators" 
> 
> Hi!
> I recently use rdo deploy a Liberty openstack in my lab.
> When I call nova v2.1
> API(http://developer.openstack.org/api-ref-compute-v2.1.html),the system
> retrun 404 not found.
> 
> Below is my package version:
> [root@rdo ~(keystone_admin)]# openstack --version
> openstack 1.7.1
> [root@rdo ~(keystone_admin)]# uname -r
> 3.10.0-229.20.1.el7.x86_64
> [root@rdo ~(keystone_admin)]# grep -i centos /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core)
> [root@rdo ~(keystone_admin)]# rpm -qa|grep openstack-nova
> openstack-nova-scheduler-12.0.0-1.el7.noarch
> openstack-nova-conductor-12.0.0-1.el7.noarch
> openstack-nova-api-12.0.0-1.el7.noarch
> openstack-nova-novncproxy-12.0.0-1.el7.noarch
> openstack-nova-common-12.0.0-1.el7.noarch
> openstack-nova-compute-12.0.0-1.el7.noarch
> openstack-nova-cert-12.0.0-1.el7.noarch
> openstack-nova-console-12.0.0-1.el7.noarch
> [root@rdo ~(keystone_admin)]# rpm -qa|grep rdo
> rubygem-rdoc-4.0.0-25.el7_1.noarch
> rdo-release-liberty-2.noarch
> [root@rdo ~(keystone_admin)]# nova version-list
> +--+---+--+-+-+
> | Id   | Status| Updated  | Min Version | Version |
> +--+---+--+-+-+
> | v2.0 | SUPPORTED | 2011-01-21T11:33:21Z | | |
> | v2.1 | CURRENT   | 2013-07-23T11:33:21Z | 2.1 | 2.12|
> +--+---+--+-+-+
> [root@rdo ~(keystone_admin)]#nova --debug --service-type computev21 list
> EndpointNotFound: publicURL endpoint for computev21 service in RegionOne
> region not found
> ERROR (EndpointNotFound): publicURL endpoint for computev21 service in
> RegionOne region not found
> 
> Now I have a question:How to use nova v2.1 API in Liberty?
> Thanks

The API reference [1] certainly seems to indicate that there should be a /v2.1/ 
endpoint for Nova (e.g. it lists "/v2.1/​{tenant_id}​/servers") but my 
recollection was that we were trying to avoid this so that you would instead 
continue to use a /v2/ endpoint and the nova API server would determine which 
version the client supported based on whether or not it exposed a 
X-OpenStack-Nova-API-Version header, and if it did then by evaluating the 
version specified [2].

Have you tried just calling / on the /v2/ endpoint and seeing what it returns 
[3] - I'd expect it will say that the endpoint currently supports v2.1 without 
any new endpoint being required (basically the contents of nova version-list).

-Steve

[1] http://developer.openstack.org/api-ref-compute-v2.1.html
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[3] http://developer.openstack.org/api-ref-compute-v2.1.html#versions-v2.1

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Etherpad for 2 PM Tuesday working session @ OpenStack Summit

[Steve Gordon]

Hi all,

As you may or may not know we have a 40 minute working session today at 2 PM at 
OpenStack Summit in Sakura N-1 and N-2. I have created an etherpad for the 
session here:

https://etherpad.openstack.org/p/TYO-telcowg

Please add use cases or projects you would like to propose to try and form a 
group on and discuss once we are in the room - I have already added those for 
which we have existing proposals in gerrit. OPNFV members are welcome to come 
and discuss their projects and/or use cases in these breakouts as well, space 
permitting.

Thanks!

-Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Meeting canceled

[Steve Gordon]

Hi all,

No Telco Working Group meeting Wednesday October 20th due to proximity to the 
F2F in Tokyo and the lack of items to discuss. See you all next Tuesday!

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [NFV][Telco] Meeting canceled

[Steve Gordon]

- Original Message -
> From: "Steve Gordon" <sgor...@redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-...@lists.openstack.org>,
> 
> Hi all,
> 
> No Telco Working Group meeting Wednesday October 20th due to proximity to the

Obviously I meant 21st, apologies!

-Steve

> F2F in Tokyo and the lack of items to discuss. See you all next Tuesday!
> 
> Thanks,
> 
> Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nfv][telcowg] Telco Working Group meeting schedule

[Steve Gordon]

Hi all,

As discussed in last week's meeting [1] we have been seeing increasingly 
limited engagement in the 1900 UTC meeting slot. For this reason starting from 
next week's meeting (October 6th) it is proposed that we consolidate on the 
1400 UTC slot which is generally better attended and stop alternating the time 
each week.

Unrelated to the above, I am traveling this Wednesday and will not be able to 
facilitate the meeting on September 30th @ 1900 UTC. Is anyone else able to 
help out by facilitating the meeting at this time? I can help out with agenda 
etc.

Thanks in advance,

Steve


[1] 
http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-09-23-14.00.html

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Migrating an instance to a host with less cores fails

[Steve Gordon]

- Original Message -
> From: "Kris G. Lindgren" <klindg...@godaddy.com>
> To: "Steve Gordon" <sgor...@redhat.com>, "Aubrey Wells" 
> <awe...@digiumcloud.com>, "David Medberry"
> 
> I believe TWC - (medberry on irc) was lamenting to me about cpusets,
> different hypervisors HW configs, and unassigned vcpu's in numa nodes.
> 
> The problem is the migration does not re-define the domain.xml, specifically,
> the vcpu mapping to match what makes sense on the new host.  I believe the
> issue is more pronounced when you go from a compute node with more cores to
> a compute node with less cores. I believe the opposite migration works, just
> the vcpu/numa nodes are all wrong.
> 
> CC'ing him as well.

Nikola's reply got bounced because he isn't subscribed, but:

"""
Thanks Steve!

So the below is likely the same root cause as this bug:

https://launchpad.net/bugs/1461777

Which has been fixed in Liberty and backported to stable/kilo (see
https://review.openstack.org/#/c/191594/)

Updating your lab to the latest stable/kilo release (2015.1.1) will
likely fix the problem for you.

Let me know if this helps!

Thanks,
N.
"""

> On 9/25/15, 11:53 AM, "Steve Gordon" <sgor...@redhat.com> wrote:
> 
> >Adding Nikola as he has been working on this.
> >
> >- Original Message -
> >> From: "Aubrey Wells" <awe...@digiumcloud.com>
> >> To: openstack-operators@lists.openstack.org
> >> 
> >> Greetings,
> >> Trying to decide if this is a bug or just a config option that I can't
> >> find. The setup I'm currently testing in my lab with is two compute nodes
> >> running Kilo, one has 40 cores (2x 10c with HT) and one has 16 cores (2x
> >> 4c
> >> + HT). I don't have any CPU pinning enabled in my nova config, which seems
> >> to have the effect of setting in libvirt.xml a vcpu cpuset element like
> >> (if
> >> created on the 40c node):
> >> 
> >>  >> cpuset="1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39">1
> >> 
> >> And then if I migrate that instance to the 16c node, it will bomb out with
> >> an exception:
> >> 
> >> Live Migration failure: Invalid value
> >> '0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38' for
> >> 'cpuset.cpus':
> >> Invalid argument
> >> 
> >> Which makes sense, since that node doesn't have any vcpus after 15 (0-15).
> >> 
> >> I can fix the symptom by commenting out a line in
> >> nova/virt/libvirt/config.py (circa line 1831) so it always has an empty
> >> cpuset and thus doesn't write that line to libvirt.xml:
> >> # vcpu.set("cpuset", hardware.format_cpu_spec(self.cpuset))
> >> 
> >> And the instance will happily migrate to the host with less CPUs, but this
> >> loses some of the benefit of openstack trying to evenly spread out the
> >> core
> >> usage on the host, at least that's what I think the purpose of that is.
> >> 
> >> I'd rather fix it the right way if there's a config option I don't see or
> >> file a bug if its a bug.
> >> 
> >> What I think should be happening is that when it creates the libvirt
> >> definition on the destination compute node, it write out the correct
> >> cpuset
> >> per the specs of the hardware its going on to.
> >> 
> >> If it matters, in my nova-compute.conf file, I also have cpu mode and
> >> model
> >> defined to allow me to migrate between the two different architectures to
> >> begin with (the 40c is Sandybridge and the 16c is Westmere so I set it to
> >> the lowest common denominator of Westmere):
> >> 
> >> cpu_mode=custom
> >> cpu_model=Westmere
> >> 
> >> Any help is appreciated.
> >> 
> >> -
> >> Aubrey
> >> 
> >> ___
> >> OpenStack-operators mailing list
> >> OpenStack-operators@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >> 
> >
> >--
> >Steve Gordon, RHCE
> >Sr. Technical Product Manager,
> >Red Hat Enterprise Linux OpenStack Platform
> >
> >___
> >OpenStack-operators mailing list
> >OpenStack-operators@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Passing entire disks to instances

[Steve Gordon]

- Original Message -
 From: David Arroyo dr...@aqwari.net
 To: openstack-operators@lists.openstack.org
 
 Hello,
 
 I would like to pass entire disks to my openstack instances. I have
 some IO-bound workloads and would like to avoid any overhead or
 contention by giving an instance access to N additional disks, such
 that they do not share that disk with other guests on the same compute
 node.
 
 These additional disks do not need to last longer than the instances
 themselves; they are ephemeral in that regard. There is no need for
 backup, no need for instance or data migration, and no need for running
 the instance on a separate compute node from the extra disks.
 Effectively I want to have an extra disks property, as part of a
 flavor or image, that is handled like vcpus without overcommit.
 
 I have been doing some research but have not yet found an obvious way
 to do this in openstack. Does anyone else have a similar use case, and
 how have you handled it? To be more specific, we run some very large
 Cassandra clusters on physical hardware, with excellent performance.
 Cassandra is largely IO-bound, and we want to virtualize it without
 introducing unnecessary IO latency.
 
 Cheers,
 David

Have you looked at the BlockDeviceDriver as described here:


http://cloudgeekz.com/71/how-to-setup-openstack-to-use-local-disks-for-instances.html

-Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nfv][telcowg] Telco Working Group meeting canceled for Wednesday August 19th

[Steve Gordon]

Hi all,

Due to a number of events going on this week (Operators 
Mid-cycle/LinuxCon/KVMForum/etc.) I am canceling the Telco Working Group 
meeting for the 19th.

Thanks!

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Fwd: [openstack-dev] [nova] should we allow overcommit for a single VM?

[Steve Gordon]

Forwarding to openstack-operators as I think some operator feedback on 
expectations here would be useful.

- Forwarded Message -
 From: Chris Friesen chris.frie...@windriver.com
 To: openstack-...@lists.openstack.org
 Sent: Tuesday, August 18, 2015 7:34:11 AM
 Subject: Re: [openstack-dev] [nova] should we allow overcommit for a single 
 VM?
 
 On 08/18/2015 06:56 AM, Nikola Đipanov wrote:
  On 08/17/2015 08:22 PM, Chris Friesen wrote:
 
  The basic question is, if a host has X CPUs in total for VMs, and a
  single instance wants X+1 vCPUs, should we allow it?  (Regardless of
  overcommit ratio.)  There is also an equivalent question for RAM.
 
  Currently we have two different answers depending on whether numa
  topology is involved or not.  Should we change one of them to make it
  consistent with the other?  If so, a) which one should we change, and b)
  how would we do that given that it results in a user-visible behaviour
  change?  (Maybe a microversion, even though the actual API doesn't
  change, just whether the request passes the scheduler filter or not?)
 
 
  I would say that the correct behavior is what NUMA fitting logic does,
  and that is to not allow instance to over-commit against itself, and we
  should fix normal (non-NUMA) over-commit. Allowing the instance to
  over-commit against itself does not make a lot of sense, however it is
  not something that is likely to happen that often in real world usage -
  I would imagine operators are unlikely to create flavors larger than
  compute hosts.
 
 This is a good point, in any real deployment it likely won't be an issue.
 We
 only ran into it because we were testing on a minimal-sized compute node
 running
 in a VM on a designer box.
 
  I am not sure that this has anything to do with the API thought. This is
  mostly a Nova internal implementation detail. Any nova deployment can
  fail to boot an instance for any number of reasons, and this does not
  affect the API response of the actual boot request.
 
 Arguably it would be changing the behaviour of a boot request.  Currently it
 would pass the scheduler and boot up, and we're talking about making it fail
 the
 scheduler filter.  That's an externally-visible change in behaviour.  (But as
 you say it's unlikely that it will be hit in the real world.)
 
 Chris
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nfv][telco] On-going management of telcowg-usecases repository

[Steve Gordon]

Hi all,

There are a couple of lingering issues with the on-going management of the 
telcowg-usecases [1] repository that I would like to give visibility to and 
ultimately resolve one way or another:

1) Presence in the Stackforge namespace

There is currently a proposal to retire stackforge [2] and while it's not clear 
this will be accepted (and even if it is there is likely to be quite a generous 
timeline before retirement) it did remind me that we primarily created the 
repository on stackforge because we fell into the group Thierry characterizes 
in the comments as:

Things that just wanted a place to live and don't have enough energy to 
propose it to TC

As such I'm asking if members of the working group would be for/against a 
proposal to move telcowg-usecases into the OpenStack namespace.

2) Core review group 

The current core review group, as created for the purposes of bootstrapping 
things, is:

- Anthony Veiga
- Marc Koderer
- Steve Gordon (me)

I think we could bare to add 1-2 people from within the working group to the 
core group outright even though the number of patch sets and reviews for that 
matter to handle is relatively minor [4]. I would like to nominate Daniel 
Schabarum and Yuriy Babenko at this point. Again I am asking though if members 
of the working group are for/against this.

Thanks,

Steve

[1] http://git.openstack.org/cgit/stackforge/telcowg-usecases/
[2] https://review.openstack.org/#/c/192016/
[3] https://review.openstack.org/#/c/178347/9/doc/source/workflow.rst
[4] 
http://stackalytics.com/?project_type=stackforgemodule=telcowg-usecasesrelease=all

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Facilitator needed for Wednesday's meeting

[Steve Gordon]

Hi all,

I am unable to make this week's Telco Working Group [1] meeting at 1900 UTC in 
#openstack-meeting-alt (more accurately I can probably make the first few 
minutes but will need to leave part way through). Any lucky volunteers who 
would be willing to pick this up and run the meeting?

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Telco Working Group meeting cancellled - June 24th [Was: Re: [NFV][Telco] Facilitator needed for Wednesday's meeting]

[Steve Gordon]

Hi all,

As I was unable to find someone else to step in I am canceling this week's 
meeting. We can pick up again next week.

Thanks,

Steve

- Original Message -
 From: Steve Gordon sgor...@redhat.com
 To: openstack-operators openstack-operators@lists.openstack.org
 Sent: Wednesday, June 24, 2015 6:53:18 AM
 Subject: [NFV][Telco] Facilitator needed for Wednesday's meeting
 
 Hi all,
 
 I am unable to make this week's Telco Working Group [1] meeting at
 1900 UTC in #openstack-meeting-alt (more accurately I can probably
 make the first few minutes but will need to leave part way through).
 Any lucky volunteers who would be willing to pick this up and run
 the meeting?
 
 Thanks,
 
 Steve
 
 [1] https://wiki.openstack.org/wiki/TelcoWorkingGroup

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Summit summary and weekly meeting schedule

[Steve Gordon]

Hi all,

The Telco Working Group ( https://wiki.openstack.org/wiki/TelcoWorkingGroup ) 
had a 90 minute working session and a brief slot within OPNFV day of 30 minutes 
during the summit. I've provided a (very) brief summary of each below and 
provided links to the relevant etherpads for anyone who is interested. The 
upcoming meeting schedule is at the end of this email.

Summit Summary
==

OPNFV Day
-

We were granted 30 minutes to lead a brief discussion at the end of the Open 
Platform for Network Function Virtualization (OPNFV) community day about what 
the telco working group is and isn't as well as highlight some concerns about 
overlap in scope and mandate with OPNFV and how we can better work together. 
Notes from this session were recorded here:

* https://etherpad.openstack.org/p/opnfv-yvr-telcowg-update

Product Working Group
-

I spent some time in one of the Product Team sessions ( 
https://wiki.openstack.org/wiki/ProductTeam ) where the discussion centered 
around how they as a group can collate the use case and requirement output of 
these existing groups in a more cohesive way. Notes from this session were 
recorded here:

* https://etherpad.openstack.org/p/ProductWG_xProjectSession

Working Session
---

During the working session we spent the first half having a catch up session on 
the current processes we have in place including the new workflow draft, what 
we like and don't like, and how we proceed from the discussion on Monday with 
the OPNFV group. At the middle of the session we broke into smaller groups to 
focus on individual use cases and/or requirements and get more people involved 
in direct conversation with each other while I individually walked anyone 
interested through bits of the process they were struggling with including git. 

We had breakouts on:

* Bring-up/instantiation (orchestration), including who provides virtual 
network function manager.
* Fault management - service monitoring requirements (hardware, cloud, 
application - hooks needed in the platform)
* Service availability via multisite / multicloud. Media / signalling 
transfer. Networking implications?
* Multiple VLAN support on the interfaces of a VM
* Multiprotocol Label Switching support

Notes from the working session were recorded here:

* https://etherpad.openstack.org/p/nfv-meeting-agenda


Meeting Schedule


Upcoming meetings are scheduled as follows:

Wednesday 3rd June 2015 1400 UTC #openstack-meeting-alt
Wednesday 10th June 2015 1900 UTC #openstack-meeting-alt
Wednesday 17th June 2015 1400 UTC #openstack-meeting-alt
Wednesday 24th June 2015 1900 UTC #openstack-meeting-alt 

As listed all meetings are in #openstack-meeting-alt on irc.freenode.net, you 
can also find us lurking in #openstack-nfv.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [nova][vmware] Minimum VC version

[Steve Gordon]

- Original Message -
 From: Dan Smith d...@danplanet.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-...@lists.openstack.org,
 
  But 4.x was EOL over a year ago:
  
  http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=2039567
 
 ...and was released in 2010.
 
 We're supporting a minimum version of libvirt from 2014, so I think that
 dropping support for five-year-old EOL'd VMware is good. We don't test
 it, which means it's probably broken. I also feel like this is a thing
 we can do without a deprecation cycle, assuming there aren't a ton of
 users still using unsupported commercial software out there.
 
 --Dan

The proposed patch also drops support for 5.0, which as I understand it is not 
EOL'd? The documentation appears to indicate that some functionality will not 
work with  5.1, but it's not explicitly clear what that it is.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] OpenStack Telco Working Group Vancouver session

[Steve Gordon]

Hi all,

I am very pleased to be facilitating the OpenStack Telco Working Group session 
at the Vancouver summit. The session is scheduled as a working session on 
Wednesday, May 20th @ 9:00 AM in East Building, Room 2/3 More details can be 
found on the Liberty Design Summit schedule[0]. Please note that we have *also* 
been allocated 30 minutes on Monday [1] to discuss with OPNFV Day participants 
the purpose and activities of the working group at a high level. While this is 
not intended as a working session working group members are encouraged to 
attend this and other OPNFV Day activities [2] that may be relevant to them.

During the IRC meetings we have put together a rough session agenda. I would be 
grateful if those interested would go ahead and continue to submit ideas for 
the agenda to the etherpad [3]. I look forward to seeing you all there!

Regards,

Steve

[0] - 
http://libertydesignsummit.sched.org/event/c6f3464285755aa4e52c64783288efcd
[1] - 
http://libertydesignsummit.sched.org/event/91f840a20957fe6dcc6d6281db6de7f7#.VVUCAeTofCE
[2] - 
https://openstacksummitmay2015vancouver.sched.org/overview/type/opnfv+day#.VVUCmOTofCE
[3] - https://etherpad.openstack.org/p/YVR-ops-telco

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Update to weekly meeting time commencing this week.

[Steve Gordon]

Hi all,

Since the Paris summit the Telco Working Group has been meeting on an 
alternating basis at 1400 UTC and 2200 UTC. As discussed in the last two 
meetings due to low attendance in the 2200 UTC slot, particularly as DST has 
now kicked in for many participants, we are going to trial a slightly earlier 
slot - 1900 UTC - starting this week. Hopefully this will help out those who 
try to attend both while also still catering to those who can't make the 
earlier meeting.

As a result the upcoming schedule is:

* Wednesday 1st April 2015  1900 UTC#openstack-meeting-alt
* Wednesday 8th April 2015  1400 UTC#openstack-meeting-alt
* Wednesday 15th April 2015 1900 UTC#openstack-meeting-alt

I have updated https://wiki.openstack.org/wiki/Meetings and 
https://wiki.openstack.org/wiki/TelcoWorkingGroup#Upcoming_Meetings with these 
details. Feel free to reach out either here or in #openstack-nfv if there are 
any concerns/questions.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Operators Mid-cycle: Telco Working Group [NFV][Telco]

[Steve Gordon]

Operators Team Members,

I am also reaching out to you because next week with the assistance of a few 
others I will be moderating a session named Telco. Those of you who have been 
attending the weekly IRC meetings will know that we have been drafting an 
agenda here:

https://etherpad.openstack.org/p/PHL-ops-telco

As we intend to, as part of the session, walk through the new process for 
documenting, submitting, reviewing, and updating use cases in gerrit it would 
streamline things significantly for those who want to try it out as we go if 
you first ensure that you:

* Have a Launchpad account: https://launchpad.net/+login
* Have joined the foundation: https://www.openstack.org/join/
* Have confirmed you can sign-on to Gerrit (uses the Launchpad login system): 
https://review.openstack.org
* Those of you who wish to submit new use cases will also need to sign the CLA, 
this is not required to simply review other use cases though: 
https://review.openstack.org/#/settings/agreements

For more detail on any of these steps please head to 
http://docs.openstack.org/infra/manual/developers.html#account-setup or jump 
into #openstack-nfv and we can try and help you out.

Thanks in advance,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Telco][NFV][infra] Review process of TelcoWG use cases

[Steve Gordon]

- Original Message -
 From: George Shuklin george.shuk...@gmail.com
 To: openstack-operators@lists.openstack.org
 
 Sorry guys. I think most of the ops here have no idea what you talking
 about. Telcos is telcos, ops is ops. Different worlds, different
 problems, different terminology.

Hi George,

The telco working group is intended to bridge the gap between telcommunications 
operators and the openstack community, something we've been working on in some 
form since Atlanta. Once you boil away the TLAs many of their core requirements 
are not significantly different for what you might consider normal operators, 
or at least operators in other verticals like high performance computing.

We primarily communicated on the -dev list prior to Paris but the feedback we 
got in the session there (on the operators track no less!) was that most people 
involved were more comfortable communicating in the context of the operators 
M/L than mixed in with the development traffic. If certain types of operators 
are not welcome in the openstack operators community then I think that would be 
a shame.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Telco][NFV][infra] Review process of TelcoWG use cases

[Steve Gordon]

- Original Message -
 From: Paul Belanger paul.belan...@polybeacon.com
 To: openstack-operators@lists.openstack.org
 
 On Fri, Feb 6, 2015 at 10:25 AM, George Shuklin
 george.shuk...@gmail.com wrote:
  On 02/06/2015 04:12 PM, Steve Gordon wrote:
 
  - Original Message -
 
  From: George Shuklin george.shuk...@gmail.com
  To: openstack-operators@lists.openstack.org
 
  Sorry guys. I think most of the ops here have no idea what you talking
  about. Telcos is telcos, ops is ops. Different worlds, different
  problems, different terminology.
 
  Hi George,
 
  The telco working group is intended to bridge the gap between
  telcommunications operators and the openstack community, something we've
  been working on in some form since Atlanta. Once you boil away the TLAs
  many
  of their core requirements are not significantly different for what you
  might consider normal operators, or at least operators in other
  verticals
  like high performance computing.
 
  We primarily communicated on the -dev list prior to Paris but the feedback
  we got in the session there (on the operators track no less!) was that
  most
  people involved were more comfortable communicating in the context of the
  operators M/L than mixed in with the development traffic. If certain types
  of operators are not welcome in the openstack operators community then I
  think that would be a shame.
 
 
  I think it not really possible. If you talking about 'openstack' as
  'Openstack developers', may be. But for operators all telco stuff is just
  completely foreign. I do not understand what they doing and I don't need
  them for my job. Sorry.
 
 Interesting, I was actually talking for some friends about the
 business of 'telco' and OpenStack recently.  Like some operators have
 indicated, the world of 'telco' is foreign to them but since my
 background come from the VoIP / telco environment I can see where you
 are coming from.
 
 I'm going to look at your proposal, and see if I can make some
 comments.  But, I am personally interested in this topic, more as a
 FYI.

Right, and on face value many of the use cases are still too far removed in 
terms of domain specific language, acronyms, etc. from where we want them to be 
to be broadly understandable and actionable - but we're trying to start 
somewhere and work on that :).

I think the more broadly applicable/interesting conversation from Marc's 
original question is how/where are operators coming at OpenStack from other 
directions documenting their use cases that they ultimately want to drive 
changes or new features in OpenStack with for community consumption? 

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Telco][NFV] Meeting facilitator for January 28th

[Steve Gordon]

- Original Message -
 From: Marc Koderer m...@koderer.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-...@lists.openstack.org
 
 Hi Steve,
 
 I can host it.
 
 Regards
 Marc

Thanks Marc!

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Meeting reminder - Wednesday 28th @ 1400 UTC in #openstack-meeting-alt

[Steve Gordon]

Hi all,

Just a friendly reminder that this week's OpenStack Telco Working Group meeting 
is tomorrow, Wednesday the 28th, at 1400 UTC in #openstack-meeting-alt. Please 
add any items you wish to discuss to the agenda at:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Marc Koderer has kindly stepped up to run the meeting in my absence.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Import Windows 2008 Vmware VMDK Image to KVM Openstack.

[Steve Gordon]

- Original Message -
 From: Pedro Sousa pgso...@gmail.com
 To: OpenStack-operators@lists.openstack.org 
 openstack-operators@lists.openstack.org
 
 Hi all,
 
 does anybody have a working procedure/howto to convert Windows based VMDK
 images to KVM?
 
 I tried to convert using qemu-img convert command but I always get a blue
 screen when I launch the instance.
 
 Thanks,
 Pedro Sousa

You might want to look into virt-v2v ( http://libguestfs.org/virt-v2v/ ). It 
performs some additional actions to converting the disk image such as injecting 
virtio drivers.

-Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Use case documentation and review

[Steve Gordon]

Hi all,

Based on the discussion last week during our first use case deep dive I have 
created etherpads for each use case and linked them from the wiki in the hope 
that this might provide a better mechanism for recording feedback in lieu of 
moving to a e.g. gerrit for these:

https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases

I also added links to the orchestration and service chaining etherpads under a 
work in progress heading. We can discuss how to proceed from here in the 
meeting tomorrow.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Selection of Use Case to do a deep dive on for next week's meeting

[Steve Gordon]

Hi all,

At the meeting this week we discussed selecting one of the submitted use cases 
to perform a deep dive on next week. I've put together a quick survey based on 
the items currently listed on the wiki [1]:

https://www.surveymonkey.com/s/N9JWN76

There are two other use cases I am aware of being drafted which we can consider 
once they are added. Based on the responses I will select the use case to add 
to the agenda for next week, assuming the person who proposed it is available, 
if not we will move to the next one in the rankings and so on.

Thanks!

Steve

[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday December 17th @ 1400 UTC in #openstack-meeting-alt

[Steve Gordon]

Hi all,

Just a reminder that the Telco Working Group will be meeting @ 1400 UTC in 
#openstack-meeting on Wednesday December 17th. Draft agenda is available here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Please feel free to add items. Note that I would also like to propose that we 
skip the meetings which would have fallen on December 24th and December 31st 
due to it being a holiday period for many participants. This would make the 
next meeting following this one January 7th.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Meeting Minutes and Logs from Dec. 10

[Steve Gordon]

Hi all,

Minutes and logs from todays OpenStack Telco Working Group meeting are 
available at the locations below:

* Meeting ended Wed Dec 10 22:59:12 2014 UTC.  Information about MeetBot at 
http://wiki.debian.org/MeetBot . (v 0.1.4)
* Minutes:
http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-12-10-22.00.html
* Minutes (text): 
http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-12-10-22.00.txt
* Log:
http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-12-10-22.00.log.html

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] GPG signatures failed for OpenStack Icehouse EPEL repo

[Steve Gordon]

- Original Message -
 From: Kris G. Lindgren klindg...@godaddy.com
 To: Edgar Magana edgar.mag...@workday.com, openst...@lists.openstack.org, 
 openstack-operators@lists.openstack.org
 
 I don’t use the RDO packages – however my guess is you need to verify using
 the rdo-icehouse gpg key:
 
 https://github.com/redhat-openstack/rdo-release/blob/icehouse/RPM-GPG-KEY-RDO-Icehouse
 
 But I am not sure where they keep that key publicly downloadable outside of
 their github repo.

It's in the release RPM you install to add the repository:


https://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-4.noarch.rpm

 From: Edgar Magana
 edgar.mag...@workday.commailto:edgar.mag...@workday.com
 Date: Monday, December 8, 2014 at 4:41 PM
 To: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
 openst...@lists.openstack.orgmailto:openst...@lists.openstack.org,
 openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org
 openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org
 Subject: [Openstack-operators] GPG signatures failed for OpenStack Icehouse
 EPEL repo
 
 Hello,
 
 I am not sure if this is the right audience for this question but I would
 like to give it a try and maybe get re-directed to the right one.
 
 I tried verifying GPG signatures on RPMs in the OpenStack Icehouse EPEL
 repo
 (http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-6 ).
 All of them failed (see below).
 
 
 This page here says the packages should be verifiable with the EPEL GPG keys:
 http://docs.openstack.org/icehouse/install-guide/install/yum/content/basics-packages.html

The EPEL packages that statement is referring to (the repository for which is 
installed by the command that follows) are signed using the EPEL key, the RDO 
packages are signed using the RDO key.

-Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday Dec 9 @ 2200 UTC in #openstack-meeting

[Steve Gordon]

Hi all,

Just a reminder that the Telco Working Group will be meeting @ 2200 UTC in 
#openstack-meeting on Wednesday December 9th. Draft agenda is available here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Please feel free to add anything you think I missed.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday Dec 10 @ 2200 UTC in #openstack-meeting

[Steve Gordon]

...and of course I meant December *10th* - sorry!

-Steve

- Original Message -
 From: Steve Gordon sgor...@redhat.com
 
 Hi all,
 
 Just a reminder that the Telco Working Group will be meeting @ 2200 UTC in
 #openstack-meeting on Wednesday December 9th. Draft agenda is available
 here:
 
 https://etherpad.openstack.org/p/nfv-meeting-agenda
 
 Please feel free to add anything you think I missed.
 
 Thanks,
 
 Steve

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Meeting Reminder - Wednesday @ 2200 UTC

[Steve Gordon]

Hi all,

Just a reminder - there is a Telco working group meeting at 2200 UTC on 
Wednesday in #openstack-meeting. If you have items you wish to add to the 
agenda please add them to the etherpad:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Note that I fully expect attendance will take a hit as it's the day before the 
US Thanksgiving holiday but think it's worth trying to continue moving forward 
with those who are still available.

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Meeting time and agenda (incl. proposal for future alternate time)

[Steve Gordon]

Hi all,

The OpenStack Telco Working Group (formerly NFV subteam) will be meeting for 
the first time post-summit this Wednesday @ 1400 UTC [1] in 
#openstack-meeting-alt on Freenode [2]. I have started to draft the agenda here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Please add additional items that you would like to discuss during the meeting.  
If you received this email directly via BCC then you put your name down on the 
sign up sheet passed around at the recent telco working group ops summit 
session [3]. Please sign up to the openstack-operators list [4] and filter 
emails for the [Telco] tag in the subject to receive further updates from this 
group.

Please also note that the group Wiki page has been moved to to reflect the 
naming and scope discussed at the summit with further edits still to be done:

https://wiki.openstack.org/wiki/TelcoWorkingGroup

Finally, I would like to propose that we replace the Thursday 1600 UTC 
alternate time with Wednesday 2200 UTC [5] in future to provide a more 
divergent option for those attending from other time zones. Please let me know 
of any objections, we will also discuss this in the meeting.

Thanks,

Steve

[1] 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Telco+Working+Groupiso=20141119T14ah=1
[2] https://wiki.openstack.org/wiki/IRC
[3] https://etherpad.openstack.org/p/kilo-summit-ops-telco
[4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[5] 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Telco+Working+Group+%28alternate%29iso=20141117T22ah=1

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Minutes from Telco Working Group Session are now available.

[Steve Gordon]

Hi all,

This week there was Telco Working Group session on the operators track at 
OpenStack Summit in Paris. We had some issues with etherpad connectivity during 
the session but Carol has since uploaded minutes of the session and they are 
available here:

https://etherpad.openstack.org/p/kilo-summit-ops-telco

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Full list of Etherpads for Ops Summit

[Steve Gordon]

Nevermind, found it:

https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Ops

Will update the other page.

- Original Message -
 From: Steve Gordon sgor...@redhat.com
 To: openstack-operators@lists.openstack.org
 Sent: Wednesday, November 5, 2014 4:55:51 PM
 Subject: Full list of Etherpads for Ops Summit
 
 Hi all,
 
 Is there a full list of etherpads for the ops summit sessions somewhere? I
 noticed there isn't one linked here:
 
 https://wiki.openstack.org/wiki/Summit/Planning
 
 Thanks,
 
 Steve

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Full list of Etherpads for Ops Summit

[Steve Gordon]

Hi all,

Is there a full list of etherpads for the ops summit sessions somewhere? I 
noticed there isn't one linked here:

https://wiki.openstack.org/wiki/Summit/Planning

Thanks,

Steve

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [NFV][Telco] Working Group Session

[Steve Gordon]

Hi all,

I wanted to highlight that as mentioned in the OpenStack NFV subteam meeting 
yesterday [1] there is a Ops Summit session aiming to bring together those 
interested in the use of OpenStack to provide the infrastructure for 
communication services. This includes, but is not limited to:

- Communication service providers
- Network equipment providers
- Developers

Anyone else interested in this space is also of course welcome to join. Among 
other things we will discuss use cases and requirements, both for new 
functionality and improving existing functionality to meet the needs of this 
sector. We will also discuss ways to work more productively with the OpenStack 
community.

The session is currently scheduled to occur @ 9 AM on Thursday in the 
Batignolles room at the Hyatt Hotel near the summit venue (this hotel also 
hosts a number of other sessions). For more details see the session entry in 
the sched.org schedule [2].

Thanks,

Steve

[1] http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-10-30-16.03.html
[2] http://kilodesignsummit.sched.org/event/b3ccf1464e335b703fc126f068142792

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators