From ignaziocassano at gmail.com  Tue Sep  1 06:23:39 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 1 Sep 2015 08:23:39 +0200
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical host
Message-ID: <CAB7j8cVdQj2PkhJNqJZVC_Q8y=pK8g5kCotnsEA65iLiXGg8Wg@mail.gmail.com>

Hi all,
In my kilo neutron configuration I have a flat network with a dhcp agent.
Dhcp release addresses to openstack virtual machines but not to physical
hosts
in the same network.
If I assign an address to the physical host I can ping the neutron dhcp
server.
Could anyone help me ?
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/2def1b2f/attachment.html>

From pczarkowski+openstackops at bluebox.net  Tue Sep  1 12:59:41 2015
From: pczarkowski+openstackops at bluebox.net (Paul Czarkowski)
Date: Tue, 1 Sep 2015 07:59:41 -0500
Subject: [Openstack-operators] Using VMs as hypervisors for nova-docker
In-Reply-To: <A44D779C-0622-48C3-BF71-3C142514FDCB@overstock.com>
References: <A44D779C-0622-48C3-BF71-3C142514FDCB@overstock.com>
Message-ID: <CAMKCwXkwmDY6KVyO6hETKEnk3G-XWCCeya5Qio3oYEOBoiXw1w@mail.gmail.com>

I have done similar in the past except I had some phys for novadocker, some
for regular kvm nova.   There should be no problem doing the novadocker
within VMs instead.  You can actually also run novadocker and nova on the
same phys host,  there's a blog post[1] that somebody wrote that details
the setup for it ...  from memory you have to run two nova-computes and two
neutron-agents with different settings to make it work.

[1]
http://blog.oddbit.com/2015/01/17/running-novalibvirt-and-novadocker-on-the-same-host/

On Mon, Aug 31, 2015 at 4:20 PM, Mike Smith <mismith at overstock.com> wrote:

> I?m still experimenting with containers with our Openstack Kilo
> installation.  Since I don?t necessarily need the feature set provided by
> Magnum, I was trying the (supposedly) simple nova-docker approach.
> However, I don?t want to dedicate an entire server for containers and I
> want the ability to migrate containers between physical servers for
> management purposes.
>
> It occurs to me that I should be able to configure a VM as a nova-docker
> hypervisor.  I should then get the advantages of being able to move that VM
> between physical nodes.  That way I also don?t have to dedicate an entire
> piece of hardware to nova-docker.
>
> Have others out there tried this approach?  I?d love to hear if this is
> something people are doing.
>
> Currently, I have software dependency issues trying to install and run RDO
> Kilo nova-compute on a CentOS 7 VM with Docker installed on it.  I plan to
> work through those issues, but if there is some reason that this just won?t
> work I?d love to spare myself some time.
>
> Thanks
>
> Mike Smith
> Principal Engineer / Cloud Team Lead
> Overstock.com
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/824e80e6/attachment.html>

From kevin.stevens at rackspace.com  Tue Sep  1 16:17:28 2015
From: kevin.stevens at rackspace.com (Kevin Stevens)
Date: Tue, 1 Sep 2015 16:17:28 +0000
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical
 host
In-Reply-To: <CAB7j8cVdQj2PkhJNqJZVC_Q8y=pK8g5kCotnsEA65iLiXGg8Wg@mail.gmail.com>
References: <CAB7j8cVdQj2PkhJNqJZVC_Q8y=pK8g5kCotnsEA65iLiXGg8Wg@mail.gmail.com>
Message-ID: <D20B2CEC.DD56%kevin.stevens@rackspace.com>

Ignazio,

The Neutron DHCP agent only hands out leases to devices/instances managed by Openstack. Unlike nova-network, hypervisors do not get an IP out of Neutron networks. Is there a particular reason you'd want to do this?

Kevin

From: Ignazio Cassano <ignaziocassano at gmail.com<mailto:ignaziocassano at gmail.com>>
Date: Monday, August 31, 2015 at 11:23 PM
To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical host

Hi all,
In my kilo neutron configuration I have a flat network with a dhcp agent.
Dhcp release addresses to openstack virtual machines but not to physical hosts
in the same network.
If I assign an address to the physical host I can ping the neutron dhcp server.
Could anyone help me ?
Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/12696971/attachment.html>

From salman.toor at it.uu.se  Tue Sep  1 17:09:05 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Tue, 1 Sep 2015 17:09:05 +0000
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical
 host
Message-ID: <3a189517-4793-41f8-bf66-46cb3446554b@email.android.com>

Hi,

What is are you using on compute? I had similar problem few days ago with CentOS and I manage to solve it. If you are using CentOS you can give a try with my solution.

/Salman.

Sent from Nesux 6.

On Sep 1, 2015 8:29 AM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
Hi all,
In my kilo neutron configuration I have a flat network with a dhcp agent.
Dhcp release addresses to openstack virtual machines but not to physical hosts
in the same network.
If I assign an address to the physical host I can ping the neutron dhcp server.
Could anyone help me ?
Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/a22c2ac2/attachment.html>

From akalambu at cisco.com  Tue Sep  1 18:49:54 2015
From: akalambu at cisco.com (Ajay Kalambur (akalambu))
Date: Tue, 1 Sep 2015 18:49:54 +0000
Subject: [Openstack-operators] Control exchange configuration
Message-ID: <D20B4162.24EDF%akalambu@cisco.com>

Hi
When we configure the control_exchange parameter in each of the openstack components it defaults to openstack
Is there a recommendation to have separate exchanges per component or just use the openstack exchange for rabbit

Is there any impact of using one vs the other


Ajay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/9950f5da/attachment.html>

From akalambu at cisco.com  Tue Sep  1 19:07:29 2015
From: akalambu at cisco.com (Ajay Kalambur (akalambu))
Date: Tue, 1 Sep 2015 19:07:29 +0000
Subject: [Openstack-operators] Rabbit HA queues
Message-ID: <D20B4580.24EE5%akalambu@cisco.com>

Hi
How is the rabbit_ha_queues parameter used in configuration files like nova.conf, neutron.conf, cinder.conf etc

What happens if on the rabbit node the ha queue is set to mirrored but the ha queues is set to False on client side
[root at j10-controller-1 /]# rabbitmqctl list_policies
Listing policies ...
/ ha-all all {"ha-mode":"all","ha-sync-mode":"automatic"} 0
...done.
[root at j10-controller-1 /]


I have rabbit_ha_queues=False set on nova and neutron.conf and from what I can see the queues seem to be mirrored. So why is this needed in nova.conf, neutron.conf etc

This is Juno release

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/faf3af2c/attachment.html>

From kevinbri at cisco.com  Tue Sep  1 19:14:46 2015
From: kevinbri at cisco.com (Kevin Bringard (kevinbri))
Date: Tue, 1 Sep 2015 19:14:46 +0000
Subject: [Openstack-operators] Rabbit HA queues
Message-ID: <D20B54CF.DD87%kevinbri@cisco.com>

My understanding is, in Rabbit versions prior to 3.x, the HA policy was
set client side when the queues were created. Hence the setting in the
config files. Since version 3.x, the paradigm changed and the ha policy is
now set server side, which is what you're seeing there.

Generally this is done by your automation when you setup rabbit and create
the policies.

On 9/1/15, 1:07 PM, "Ajay Kalambur (akalambu)" <akalambu at cisco.com> wrote:

>Hi
>How is the rabbit_ha_queues parameter used in configuration files like
>nova.conf, neutron.conf, cinder.conf etc
>
>
>What happens if on the rabbit node the ha queue is set to mirrored but
>the ha queues is set to False on client side
>[root at j10-controller-1 /]# rabbitmqctl list_policies
>Listing policies ...
>/ha-all all{"ha-mode":"all","ha-sync-mode":"automatic"}0
>...done.
>[root at j10-controller-1 /]
>
>
>
>
>
>I have rabbit_ha_queues=False
> set on nova and neutron.conf and from what I can see the queues seem to
>be mirrored. So why is this needed in nova.conf, neutron.conf etc
>
>
>This is Juno release
>
>
>



From ignaziocassano at gmail.com  Tue Sep  1 20:05:10 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 1 Sep 2015 22:05:10 +0200
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical
	host
In-Reply-To: <D20B2CEC.DD56%kevin.stevens@rackspace.com>
References: <CAB7j8cVdQj2PkhJNqJZVC_Q8y=pK8g5kCotnsEA65iLiXGg8Wg@mail.gmail.com>
 <D20B2CEC.DD56%kevin.stevens@rackspace.com>
Message-ID: <CAB7j8cVT4QAo=kCZ8cehmY2a585cmGFC1yF+L6D=+V4hRL3qLA@mail.gmail.com>

Kevin, I am only testing some configurations to fit my future needs.
The workaround suggested by Kevin Benton in previous email works fine.
In a future project I need to install linux desktops on a intranet flat
network with a dhcp server.
If I understood fine it is not a good idea using an external dhcp  server
because some rules are applied by openstack on addresses .
Infact if I use an external dhcp server my desktop get an address but it is
not the same displayed on dashboard
Sorry for my bad english
Ignazio
Il giorno 01/set/2015 18:17, "Kevin Stevens" <kevin.stevens at rackspace.com>
ha scritto:

> Ignazio,
>
> The Neutron DHCP agent only hands out leases to devices/instances managed
> by Openstack. Unlike nova-network, hypervisors do not get an IP out of
> Neutron networks. Is there a particular reason you?d want to do this?
>
> Kevin
>
> From: Ignazio Cassano <ignaziocassano at gmail.com>
> Date: Monday, August 31, 2015 at 11:23 PM
> To: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: [Openstack-operators] Kilo neutron dhcp not release to physical
> host
>
> Hi all,
> In my kilo neutron configuration I have a flat network with a dhcp agent.
> Dhcp release addresses to openstack virtual machines but not to physical
> hosts
> in the same network.
> If I assign an address to the physical host I can ping the neutron dhcp
> server.
> Could anyone help me ?
> Regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/c6c2f077/attachment.html>

From ignaziocassano at gmail.com  Tue Sep  1 20:08:08 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 1 Sep 2015 22:08:08 +0200
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical
	host
In-Reply-To: <3a189517-4793-41f8-bf66-46cb3446554b@email.android.com>
References: <3a189517-4793-41f8-bf66-46cb3446554b@email.android.com>
Message-ID: <CAB7j8cW0FZ7UpzK_cLBkzVbAT5a_Z4_+Rsue91AHSdWDsS8Vww@mail.gmail.com>

Salman, I'm using centos 7 either on computing nodes or neutron network
node.
The workaround suggested by Kevin Benton in previous email works fine.
Further suggestions ?
Regards
Ignazio
Il giorno 01/set/2015 19:09, "Salman Toor" <salman.toor at it.uu.se> ha
scritto:

> Hi,
>
> What is are you using on compute? I had similar problem few days ago with
> CentOS and I manage to solve it. If you are using CentOS you can give a try
> with my solution.
>
> /Salman.
>
> Sent from Nesux 6.
> On Sep 1, 2015 8:29 AM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
>
> Hi all,
> In my kilo neutron configuration I have a flat network with a dhcp agent.
> Dhcp release addresses to openstack virtual machines but not to physical
> hosts
> in the same network.
> If I assign an address to the physical host I can ping the neutron dhcp
> server.
> Could anyone help me ?
> Regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/77e8802a/attachment.html>

From klindgren at godaddy.com  Tue Sep  1 20:32:47 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Tue, 1 Sep 2015 20:32:47 +0000
Subject: [Openstack-operators] kilo - neutron - ipset problems?
In-Reply-To: <55D5CA1A.1020405@redhat.com>
References: <D1FABCA5.1F2D6%klindgren@godaddy.com>
 <55D5CA1A.1020405@redhat.com>
Message-ID: <174FF66E-F66A-452F-BAC8-F7697DA33E2C@godaddy.com>

Hello,

We ran into this again today.

I created bug: https://bugs.launchpad.net/neutron/+bug/1491131 for this.  With the log files for ~10 seconds before the issue happened to the first couple ipset delete failures.




On 8/20/15, 6:37 AM, "Miguel Angel Ajo" <mangelajo at redhat.com> wrote:

>Hi Kris,
>
>    I'm adding Shi Han Zhang to the thread,
>
>    I'm was involved in some refactors during kilo and Han Zhang in some 
>extra fixes during Liberty [1] [2] [3],
>
>    Could you get us some logs of such failures to see what was 
>happening around the failure time?, as a minimum we should
>post the log error traces to a bug in https://bugs.launchpad.net/neutron
>
>     We will be glad to use such information to make the ipset more 
>fault tolerant, and try to identify the cause of the
>possible race conditions.
>
>
>[1] https://review.openstack.org/#/c/187483/
>[2] https://review.openstack.org/190991
>[3] https://review.openstack.org/#/c/187433/
>
>
>
>Kris G. Lindgren wrote:
>>
>> We have been using ipsets since juno.  Twice now since our kilo 
>> upgrade we have had issues with ipsets blowing up on a compute node.
>>
>> The first time, was iptables was referencing an ipset that was either 
>> no longer there or was not added, and was trying to apply the iptables 
>> config every second and dumping the full iptables-resotore output into 
>> the log when it failed at TRACE level.
>> Second time, was that ipsets was failing to remove an element that was 
>> no longer there.
>>
>> For #1 I solved by restarting the neutron-openvswitch-agent.  For #2 
>> we just added the entry that ipsets was trying to remove.  It seems 
>> like we are having some race conditions under kilo that were not 
>> present under juno (or we managed to run it for 6+ months without it 
>> biting us).
>>
>> Is anyone else seeing the same problems?  I am noticing some commits 
>> reverting/re-adding around ipsets in kilo and liberty so trying to 
>> confirm if I need to open a new bug on this.
>> ____________________________________________
>>
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy, LLC.
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>Kris G. Lindgren wrote:
>> We have been using ipsets since juno.  Twice now since our kilo upgrade we have had issues with ipsets blowing up on a compute node.
>>
>> The first time, was iptables was referencing an ipset that was either no longer there or was not added, and was trying to apply the iptables config every second and dumping the full iptables-resotore output into the log when it failed at TRACE level.
>> Second time, was that ipsets was failing to remove an element that was no longer there.
>>
>> For #1 I solved by restarting the neutron-openvswitch-agent.  For #2 we just added the entry that ipsets was trying to remove.  It seems like we are having some race conditions under kilo that were not present under juno (or we managed to run it for 6+ months without it biting us).
>>
>> Is anyone else seeing the same problems?  I am noticing some commits reverting/re-adding around ipsets in kilo and liberty so trying to confirm if I need to open a new bug on this.
>> ____________________________________________
>>
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy, LLC.
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

From salman.toor at it.uu.se  Tue Sep  1 21:14:03 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Tue, 1 Sep 2015 21:14:03 +0000
Subject: [Openstack-operators] Kilo neutron dhcp not release to physical
 host
In-Reply-To: <CAB7j8cW0FZ7UpzK_cLBkzVbAT5a_Z4_+Rsue91AHSdWDsS8Vww@mail.gmail.com>
References: <3a189517-4793-41f8-bf66-46cb3446554b@email.android.com>,
 <CAB7j8cW0FZ7UpzK_cLBkzVbAT5a_Z4_+Rsue91AHSdWDsS8Vww@mail.gmail.com>
Message-ID: <99B4809311BF4340B95D0F3720EAC0BB29A953EF@COLUMBA00.user.uu.se>

Hi,
Sorry I think I miss understood you original mail. The problem we had was related to the VMs not the Physical host in the same network.

I don't think I can help in this regards.

/Salman.



From: Ignazio Cassano [ignaziocassano at gmail.com]
Sent: Tuesday, September 01, 2015 10:08 PM
To: Salman Toor
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Kilo neutron dhcp not release to physical host


Salman, I'm using centos 7 either on computing nodes or neutron network node.
The workaround suggested by Kevin Benton in previous email works fine.
Further suggestions ?
Regards
Ignazio

Il giorno 01/set/2015 19:09, "Salman Toor" <salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>> ha scritto:

Hi,

What is are you using on compute? I had similar problem few days ago with CentOS and I manage to solve it. If you are using CentOS you can give a try with my solution.

/Salman.

Sent from Nesux 6.

On Sep 1, 2015 8:29 AM, Ignazio Cassano <ignaziocassano at gmail.com<mailto:ignaziocassano at gmail.com>> wrote:
Hi all,
In my kilo neutron configuration I have a flat network with a dhcp agent.
Dhcp release addresses to openstack virtual machines but not to physical hosts
in the same network.
If I assign an address to the physical host I can ping the neutron dhcp server.
Could anyone help me ?
Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/d586028c/attachment.html>

From salman.toor at it.uu.se  Tue Sep  1 21:29:27 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Tue, 1 Sep 2015 21:29:27 +0000
Subject: [Openstack-operators] Need some help to understand neutron
Message-ID: <99B4809311BF4340B95D0F3720EAC0BB29A95471@COLUMBA00.user.uu.se>

Hi,

Can some one please explain it a bit or redirect me to the document.

So on neutron node we need external interface br-ex (public IP) and than each tenant's router also occupies a real IP when we attach it to external net.

I am wondering what is the path instances traffic take to go out? I mean will it go via the public IP attached to the router or its via br-ex?

Regards..
Salman.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/24bdc59c/attachment.html>

From james.denton at rackspace.com  Tue Sep  1 22:28:55 2015
From: james.denton at rackspace.com (James Denton)
Date: Tue, 1 Sep 2015 22:28:55 +0000
Subject: [Openstack-operators] Need some help to understand neutron
In-Reply-To: <99B4809311BF4340B95D0F3720EAC0BB29A95471@COLUMBA00.user.uu.se>
References: <99B4809311BF4340B95D0F3720EAC0BB29A95471@COLUMBA00.user.uu.se>
Message-ID: <6C92BF06-0FE5-4403-8D8F-49049F27F285@rackspace.com>

Hi Salman,

The external bridge, br-ex, does not require an IP address. When routers are connected to the bridge, it is true they procure an address from the external provider network. The address is applied to the qg interface within the router namespace.

When instances send traffic out, the router NATs the traffic using its respective IP (known as SNAT, or many to one.) When an instance has a floating IP, the router will NAT the traffic using the floating IP instead (known as one to one). The SNAT behavior can be disabled on a particular router if necessary, but it introduces routing issues that need to be solved upstream.

James

Sent from my iPhone

On Sep 1, 2015, at 4:33 PM, Salman Toor <salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>> wrote:

Hi,

Can some one please explain it a bit or redirect me to the document.

So on neutron node we need external interface br-ex (public IP) and than each tenant's router also occupies a real IP when we attach it to external net.

I am wondering what is the path instances traffic take to go out? I mean will it go via the public IP attached to the router or its via br-ex?

Regards..
Salman.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/ef892f21/attachment.html>

From raju.roks at gmail.com  Wed Sep  2 00:17:27 2015
From: raju.roks at gmail.com (raju)
Date: Tue, 1 Sep 2015 20:17:27 -0400
Subject: [Openstack-operators] Neutron Lbaas Issues Icehouse
Message-ID: <CAMhjf2gPnfoA==J54-v9YfwsLfVKJ+ZCGAzP3Pn1_+t3ERn8-Q@mail.gmail.com>

Hi All,

I have configured lbaas in my Icehouse environment and able to start the
lbaas agent without any issues. When I create a pool it creates sussfully
without any errors but in log file it shows

 WARNING neutron.services.loadbalancer.drivers.haproxy.namespace_driver [-]
Stats socket not found for pool 3b9eb090-1d57-466e-b83e-552ead86a677

it is not creating namespace while adding pool but when adding VIP it
creates a ns and vtep interfaces with error state and I need to delete
those vtep interfaes manualy using ip netns delete


Neutron.conf

service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

service_plugins =neutron.services.loadbalancer.plugin.LoadBalancerPlugin

lbaas_agent.ini

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
device_driver =
neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver
user_group = haproxy

Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150901/046fa53a/attachment.html>

From zhangjian2011 at cn.fujitsu.com  Wed Sep  2 10:16:38 2015
From: zhangjian2011 at cn.fujitsu.com (zhangjian2011)
Date: Wed, 2 Sep 2015 18:16:38 +0800
Subject: [Openstack-operators]  Is Flat mode supportting Floating IP
Message-ID: <55E6CC86.9030506@cn.fujitsu.com>

Hi, All

In a Flat mode openstack environment, instance and nodes are in the same 
sub-net,
in such an environment, can we allocate a floating IP to instances?


Regards
Jian


From salman.toor at it.uu.se  Wed Sep  2 12:40:29 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Wed, 2 Sep 2015 12:40:29 +0000
Subject: [Openstack-operators] Need some help to understand neutron
In-Reply-To: <6C92BF06-0FE5-4403-8D8F-49049F27F285@rackspace.com>
References: <99B4809311BF4340B95D0F3720EAC0BB29A95471@COLUMBA00.user.uu.se>
 <6C92BF06-0FE5-4403-8D8F-49049F27F285@rackspace.com>
Message-ID: <6D5AC624-7593-475E-94E1-A4A9951C3075@it.uu.se>

Thanks for the response and also for the link :-)


Actually we are struggling with the floating IP so each one of them matters.

I am thinking to go for a model where I can use minimum floating IPs, can?t afford to give a new floating IP to each new tenant's routers.

 Since its not a production environment we can compromise on performance and different tenants traffic can share same interface.

Regards..
Salman.

PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 02 Sep 2015, at 00:28, James Denton <james.denton at rackspace.com<mailto:james.denton at rackspace.com>> wrote:

Hi Salman,

The external bridge, br-ex, does not require an IP address. When routers are connected to the bridge, it is true they procure an address from the external provider network. The address is applied to the qg interface within the router namespace.

When instances send traffic out, the router NATs the traffic using its respective IP (known as SNAT, or many to one.) When an instance has a floating IP, the router will NAT the traffic using the floating IP instead (known as one to one). The SNAT behavior can be disabled on a particular router if necessary, but it introduces routing issues that need to be solved upstream.

James

Sent from my iPhone

On Sep 1, 2015, at 4:33 PM, Salman Toor <salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>> wrote:

Hi,

Can some one please explain it a bit or redirect me to the document.

So on neutron node we need external interface br-ex (public IP) and than each tenant's router also occupies a real IP when we attach it to external net.

I am wondering what is the path instances traffic take to go out? I mean will it go via the public IP attached to the router or its via br-ex?

Regards..
Salman.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150902/053fa83e/attachment.html>

From raju.roks at gmail.com  Wed Sep  2 13:51:01 2015
From: raju.roks at gmail.com (raju)
Date: Wed, 2 Sep 2015 09:51:01 -0400
Subject: [Openstack-operators] Neutron Lbaas Issues Icehouse
In-Reply-To: <CAMhjf2gPnfoA==J54-v9YfwsLfVKJ+ZCGAzP3Pn1_+t3ERn8-Q@mail.gmail.com>
References: <CAMhjf2gPnfoA==J54-v9YfwsLfVKJ+ZCGAzP3Pn1_+t3ERn8-Q@mail.gmail.com>
Message-ID: <CAMhjf2jCZfgNmPb7TJtWRGUYPRuUScWM69z3fuhGqktvFBxL9A@mail.gmail.com>

Anyone came across this issue?

On Tue, Sep 1, 2015 at 8:17 PM, raju <raju.roks at gmail.com> wrote:

> Hi All,
>
> I have configured lbaas in my Icehouse environment and able to start the
> lbaas agent without any issues. When I create a pool it creates sussfully
> without any errors but in log file it shows
>
>  WARNING neutron.services.loadbalancer.drivers.haproxy.namespace_driver
> [-] Stats socket not found for pool 3b9eb090-1d57-466e-b83e-552ead86a677
>
> it is not creating namespace while adding pool but when adding VIP it
> creates a ns and vtep interfaces with error state and I need to delete
> those vtep interfaes manualy using ip netns delete
>
>
> Neutron.conf
>
>
> service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
>
> service_plugins =neutron.services.loadbalancer.plugin.LoadBalancerPlugin
>
> lbaas_agent.ini
>
> interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
> device_driver =
> neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver
> user_group = haproxy
>
> Thanks in advance
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150902/f4c30480/attachment.html>

From jj at chef.io  Wed Sep  2 16:07:59 2015
From: jj at chef.io (JJ Asghar)
Date: Wed, 2 Sep 2015 11:07:59 -0500
Subject: [Openstack-operators] [openstack-operators] Announcement! We are
 starting the Stackforge process!
Message-ID: <55E71EDF.5060203@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

All,

Per our conversations in Palo Alto, we are moving OSOps[1] to
Stackforge. I have created a review to start this here[1].

Please if you have time +1 this and show support of making Operators
eventually part of the Big Tent!

[1]: https://github.com/osops
[2]: https://review.openstack.org/219760

- -JJ

- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV5x7fAAoJEDZbxzMH0+jT1yQP/AuyqvZCWaAJXaYg/tuCIVcf
khNEWbaDJ7IdXzkEDH69bNfgm5vJu+SvHva+AC2roCkKzckihL3QEWxPSZMVGC+r
lCs2q6igMsf7C3wCKRpu0hje6CZnkMgJPyLM1I14EyWauiD6AJodG3T3lCo1w5b0
etetYK95hHZ24vBL1HTCML+1X8ZF/4ZTiBBViRACIdGrHYQCBx5lN9LxUmjS7Le1
6+I8PHHecPlE2cS6qTR/atvLERuZhnVSbsjVvofvYwCFVp0nqcwJ492SQAw4bdkD
Fc8/Kzloi9WJ2Uspx5S6ouz+5Am5cwh4fagSJ/fZxgtK6XoKteAxkLxHwwVlsddG
B90/HgkOs5BEFOVJDKbkGQ3OrlbY3pvysyNT2uvoZIsBlLf8dJ14Uk6iZqwkYcLR
F+5j03vlYUh21cwvsiaTlGt94cKqs6WwHbV2tL/mOoW4sPxv+eXecG50bBWdl5rR
LVPvPscknOxIAEIJa7a52vOiUZvmb/UhrVgmj7/VD1v/iUx139F0cPl090Dt/5pa
tr0zJq3QlltKG7exr3gqLDPur7KcIrs5qX5h6XBI4FyMgDC3rRPT3ZskbNwqcMK+
IYdCU+YUjUMvyOjEhWmAmHFrzL8NDVyi6a/ArUf1eLabx28UOLB2TlNoSOjwOqLO
EBWGLLbB8buPyqW79Bdv
=+55h
-----END PGP SIGNATURE-----



From jj at chef.io  Wed Sep  2 16:14:37 2015
From: jj at chef.io (JJ Asghar)
Date: Wed, 2 Sep 2015 11:14:37 -0500
Subject: [Openstack-operators] [openstack-operators] Announcement! We
 are starting the Stackforge process!
In-Reply-To: <55E71EDF.5060203@chef.io>
References: <55E71EDF.5060203@chef.io>
Message-ID: <55E7206D.9050609@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I should mention I have created the Launchpad[1] also.

I did put the maintainer as OpenStack Admins which i read incorrectly in
the docs, so I'm in the process of fixing this.

[1]: https://launchpad.net/osops

Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2

On 9/2/15 11:07 AM, JJ Asghar wrote:
>
> All,
>
> Per our conversations in Palo Alto, we are moving OSOps[1] to
> Stackforge. I have created a review to start this here[1].
>
> Please if you have time +1 this and show support of making Operators
> eventually part of the Big Tent!
>
> [1]: https://github.com/osops
> [2]: https://review.openstack.org/219760
>
> -JJ
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV5yBtAAoJEDZbxzMH0+jTiXAP/jeptflK+OX/aWdmLk5eUPnR
7XAnArFDvuO/f8m8HkOfEn/8xsB8LnnIK3wEJ+A0JphE7S57SgqoOcBsu0qhRKlu
5XIyoS1L48sWrKGNWfGlxy6ksUYh0n0iUK3CG8G03bSFETOMNjyrPLeMg0I6BwzU
c2Aad1A6S1wiJXskClw5oismIz0IpRMytMZ3cH3XuSwf9UsO15U/MnBhLmDhxbnF
QEoCDwRtjv9sf8CE813okXHjRPLjgqOrNNAzYfxlxaVtHqxrBZRXoMOUeRWDWbQO
GNzTwsgcyqi0iLE4Vohxvy3OcY3otNl/IEfXoPcX6H7Ahx7LLL0uFqcsbfUboipY
ANVKDcYhOUi1TDrkjOd7g7BMMqH1RuP8Uj9HZYieep+UuBR2dcPRG0qbCFyQP4lp
G+cFibvEW6HOxhreSnuT9xS4oUHEAU33mW5So6NUQ7ee9VqcjX/0lmGER4hQohPY
uhf74/QaYXV+Kd2XCugFjGNAHAzY2hcT1z8N2riDn/GTuYAvI4E3fiviT73uuObF
9SjQYYQcKxe++TkLR9SmviGU9E/CcABCSFLEGf7s8DpUG1PBWKwIb+fOvhrSW2HM
AZzd+uaV6rcGljqM/qVQB+bEYgZ9bB+PXFdkiDhP956Rts7Ey2IIZITdsuffKfdk
CfEG7Q6e6y0ZHhDFVwb4
=Cg0t
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150902/0e0104af/attachment.html>

From stdake at cisco.com  Wed Sep  2 18:41:28 2015
From: stdake at cisco.com (Steven Dake (stdake))
Date: Wed, 2 Sep 2015 18:41:28 +0000
Subject: [Openstack-operators] [kolla][announce] Announcing release of
	Liberty-3 Milestone!
Message-ID: <D20C90CB.11C05%stdake@cisco.com>

The Kolla community is pleased to announce the release of the Kolla Liberty 3 milestone.  This release fixes 90 bugs and implements 16 blueprints!


During Liberty 3, Kolla joined the big tent governance!  Our project can be found here:


http://governance.openstack.org/reference/projects/index.html


As part of the project renames happening in OpenStack Infrastructure, the project will be moving to the openstack git namespace September 11th [1].


Our community developed the following notable features in Liberty-3:


  *   Mult-inode deployment using Ansible with complete high availability.
  *   Ubuntu source building implemented.
  *   Compose support has been removed in favor of a new Ansible framework which supports multinode deployment of all core services.
  *   Implementation of a new compact build tool written in Python which allows for building images which is fully featured.
  *   All docker files were converted to Jinja-2 templates allowing tidy multi-distro support.
  *   Building behind proxy implemented.
  *   Vastly improved the documentation (The documentation still needs a lot of work!).
  *   Improved coverage of stable image builds in gates.
  *   Packaging Kolla with PBR python toolset.


The following services are stable and may be deployed multi-node via Ansible:

  *   glance
  *   hapoxy
  *   heat
  *   horizon
  *   keytone
  *   mariadb
  *   memcached
  *   neutron
  *   nova
  *   rabbitmq
  *   swift


Kolla's implementation is stable and Kolla is ready for evaluation by operators and third party projects. The Kolla community encourages individuals to evaluate the project and provide feedback via the mailing list or irc!


Finally, Kola has a solid crew of reviewers that are not on the core team.  We hope that folks interested in joining the core reviewer team will continue reviewing - we definitely appreciate the reviews!  Our project is highly diverse.  To get an idea for those contributing, check out [2].


Regards,

- The Kolla Development Team


 [1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073049.html

 [2] http://stackalytics.com/?module=kolla-group&metric=person-day

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150902/b80e4bd9/attachment.html>

From jj at chef.io  Wed Sep  2 19:21:47 2015
From: jj at chef.io (JJ Asghar)
Date: Wed, 2 Sep 2015 14:21:47 -0500
Subject: [Openstack-operators] [openstack-operators] Announcement! We have
 everything ready to get to Stackforge!
In-Reply-To: <55E7206D.9050609@chef.io>
References: <55E71EDF.5060203@chef.io> <55E7206D.9050609@chef.io>
Message-ID: <55E74C4B.2020901@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


To follow up with the previous emails; it seems my formatting got
screwed up.

I've put the review[1] and it looks like it's pretty good.

I've created a launchpad[2] with both answers[3] and bugs[4] to help
organize this code base.

I've also created an initial wiki[5] page too to start help
bootstrapping this.

I've mentioned this in our IRC channel also.

If you have any questions or comments please don't hesitate to reach out.

[1]: https://review.openstack.org/#/c/219760/
[2]: http://launchpad.net/osops
[3]: https://answers.launchpad.net/osops
[4]: https://bugs.launchpad.net/osops
[5]: https://wiki.openstack.org/wiki/Osops

Oh! If yall can +1 the review to say you're in favor for this that would
be amazing. The more support we get the more momentum we can get!

Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV50xLAAoJEDZbxzMH0+jTPSoP/3OqI3vznKzGHKIfeQRnnos4
o2hTdHPArs6/gaQrRTBZzPZ7WdMWypoznDluwzkdrLNlEGMOgF+aL1S1zxCEcjI0
6W5Co4Haba0nLwlAxwkw9KjoYDPJoL44hZckP75rhOsUx4Sn4eQLdgeyYyO3GtIJ
32HPc5cwsdgwcE2K9OrKBSPV1jBVk/HVNO0UWYLekx+7/3Jqk9Dk2KKv6d34Phgu
BYNUrTnVFjQMW0PfKOcTndhiA1hlNGTMN9t05K/es1kS2i0vhlduN44AYODqoo/H
1p/DD51zC2mgSVJSCYcG450ISPOiMO/KHO9q4NRZLy+1Ef4E1eHCVghCvy0oi+6L
J8hsLOrWw+U3xbOLFYCqPWxPDMtjm1IrHAwmio7Fp8h0rCk3WnagBHhJhx9SJH0j
KAMY+wZ09ct/zaSUPmLdV0+0USsQYQgPBS4RO1x/q/z1rfOc4xcTUvc0eN/HiiML
2aT53Xqo5k/jA/sCZ911sywsxdiY8JKEbImHTlYvrYuxTfMgGg6LqiODNajxLjCc
ACjrLyPgatKJBfdPR65xvWJoFfIEI0h4Usnhc6f7XNRDTUc+uwhHHp3oRxfvYxsN
EYAI5mmDg9gsCM1f6M9Z2smsS1c58mgotHJw5TO5RMb/opK9f04ofdxUrzj3xkOa
pr6KZ0IO4126Wv0BEswb
=NL4C
-----END PGP SIGNATURE-----



From doc at aedo.net  Wed Sep  2 19:22:29 2015
From: doc at aedo.net (Christopher Aedo)
Date: Wed, 2 Sep 2015 12:22:29 -0700
Subject: [Openstack-operators] [app-catalog] IRC Meeting Thursday September
	3rd at 17:00UTC
Message-ID: <CA+odVQEdupZEYBVKQ3DFzNQg6Mr7pDuDjpiWVGhQFHy_D6TNPQ@mail.gmail.com>

Greetings! Our next OpenStack App Catalog meeting will take place this
Thursday September 3rd at 17:00 UTC in #openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Please add agenda items if there's anything specific you would like to
discuss (or of course if the meeting time is not convenient for you
join us on IRC #openstack-app-catalog).

Please join us if you can!

-Christopher


From tom at openstack.org  Wed Sep  2 19:27:11 2015
From: tom at openstack.org (Tom Fifield)
Date: Thu, 3 Sep 2015 03:27:11 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
	Agenda Brainstorming
Message-ID: <55E74D8F.9020203@openstack.org>

Hi all,

Thanks for those who made it to the recent meetup in Palo Alto. It was a 
fantastic couple of days, and many are excited to get started on talking 
about our ops track in the Tokyo design summit.


Recall that this is in addition to the operations and other conference 
track's presentations. It's aimed at giving us a design-summit-style 
place to congregate, swap best practices, ideas and give feedback.


As usual, we're working to act on the feedback from all past events to
make this one better than ever. One that we continue to work on is the
need to see action happen as a result of this event, so please - when
you are suggesting sessions in the below etherpad please try and phrase
them in a way that will probably result in things happening afterward.


**********************************************************************

Please propose session ideas on:

https://etherpad.openstack.org/p/TYO-ops-meetup

ensuring each session suggestion will have a result.

**********************************************************************


The room allocations are still being worked out, but the current 
thinking is that we will interleave general sessions and working groups 
across Tuesday and Wednesday, to allow for attendance from ops in the 
cross-project sessions.


More as it comes, and as always, further information about ops meetups
and notes from the past can be found on the wiki @:

https://wiki.openstack.org/wiki/Operations/Meetups

Finally, don't forget to register ASAP!
http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598

Regards,


Tom


From christophe.sauthier at objectif-libre.com  Wed Sep  2 20:06:42 2015
From: christophe.sauthier at objectif-libre.com (Christophe Sauthier)
Date: Wed, 02 Sep 2015 22:06:42 +0200
Subject: [Openstack-operators] [ CloudKitty ] New release and next steps
Message-ID: <824102c38fb9fa26f177553ecee51536@objectif-libre.com>

We are really pleased to announce that a few days ago the latest 
CloudKitty's version (0.4.1) has been released.
For those of you who don't know CloudKitty, it is an additionnal 
component for OpenStack that tackles the pricing and chargeback aspects. 
It is fully OpenSource (Apache 2.0), developped in Python and using the 
same process and librairies as the rest of the OpenStack components.
CloudKitty is designed like any other OpenStack component, providing an 
API, a client and an Horizon integration.

Using CloudKitty you are able to:
? define the price of the different services you are providing
? charge your users for the usage
? get you users the possibiliy to know in advance the price for the 
ressource they are about to launch
? get your user a report of their past usage
? and many more


If you are interested please grab the latest release directly on 
stackforge:
? https://github.com/stackforge/cloudkitty/releases
? https://github.com/stackforge/cloudkitty-dashboard/releases
? https://github.com/stackforge/python-cloudkittyclient/releases

This release is targeted at Kilo, if you want to try it out in an older 
environment you can use virtualenv or your favorite contrainers 
solution.
A docker container will be soon avaible to help people wanting to try 
CloudKitty even on older release of OpenStack.
We are currently working on getting CloudKitty integrated with the 
major Linux Distributions, meanwhile we have repositories available with 
up to date packages at http://archive.objectif-libre.com/cloudkitty/
You can find some installation instructions here :  
http://cloudkitty.readthedocs.org/en/latest/installation.html



We hope you'll like that release but here is an overview of some of the 
major enhancements that we are planning for the Liberty release:
? Keystone AuthPlugins (less duplicated configuration code)
? Keystone sessions
? Rating module rules management (validity periods, per tenant, etc)
? Rating modules enabling you to write and manage python custom code to 
do your own pricing rules
? Scalability enhancement with the introduction of asynchronous workers 
and clustering
? Addition of the CSV as a native report output file format
? Documentaiton improvement
? More code coverage and unittests
? and many more...


Feel free to join us on #cloudkitty if you have any questions or want 
to take part into that project !

                 The CloudKitty team



----
Christophe Sauthier                       Mail : 
christophe.sauthier at objectif-libre.com
CEO                                       Mob : +33 (0) 6 16 98 63 96
Objectif Libre                            URL : www.objectif-libre.com
Infrastructure et Formations Linux        Twitter : @objectiflibre


From joe at topjian.net  Thu Sep  3 02:45:18 2015
From: joe at topjian.net (Joe Topjian)
Date: Wed, 2 Sep 2015 20:45:18 -0600
Subject: [Openstack-operators] [openstack-operators] Announcement! We
 have everything ready to get to Stackforge!
In-Reply-To: <55E74C4B.2020901@chef.io>
References: <55E71EDF.5060203@chef.io> <55E7206D.9050609@chef.io>
 <55E74C4B.2020901@chef.io>
Message-ID: <CA+y7hviR1_vZi2iSnyBXJoT6hEaMGqRJVSKaqJ66KSdSywfYfg@mail.gmail.com>

Hi JJ,

Thank you for putting all of this together!

All, one decision that was made during the PAO Ops Meetup was to make the OSOps
github repos <https://github.com/osops> "official" repos / projects. If
you've contributed to the existing repos, you may have an interest in this.

As well, if you preferred not to contribute to those repos in the past
because they weren't under the OpenStack/StackForge namespace, this may be
of interest to you, too. :)

Thanks,
Joe

On Wed, Sep 2, 2015 at 1:21 PM, JJ Asghar <jj at chef.io> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> To follow up with the previous emails; it seems my formatting got
> screwed up.
>
> I've put the review[1] and it looks like it's pretty good.
>
> I've created a launchpad[2] with both answers[3] and bugs[4] to help
> organize this code base.
>
> I've also created an initial wiki[5] page too to start help
> bootstrapping this.
>
> I've mentioned this in our IRC channel also.
>
> If you have any questions or comments please don't hesitate to reach out.
>
> [1]: https://review.openstack.org/#/c/219760/
> [2]: http://launchpad.net/osops
> [3]: https://answers.launchpad.net/osops
> [4]: https://bugs.launchpad.net/osops
> [5]: https://wiki.openstack.org/wiki/Osops
>
> Oh! If yall can +1 the review to say you're in favor for this that would
> be amazing. The more support we get the more momentum we can get!
>
> Best Regards,
> JJ Asghar
> c: 512.619.0722 t: @jjasghar irc: j^2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJV50xLAAoJEDZbxzMH0+jTPSoP/3OqI3vznKzGHKIfeQRnnos4
> o2hTdHPArs6/gaQrRTBZzPZ7WdMWypoznDluwzkdrLNlEGMOgF+aL1S1zxCEcjI0
> 6W5Co4Haba0nLwlAxwkw9KjoYDPJoL44hZckP75rhOsUx4Sn4eQLdgeyYyO3GtIJ
> 32HPc5cwsdgwcE2K9OrKBSPV1jBVk/HVNO0UWYLekx+7/3Jqk9Dk2KKv6d34Phgu
> BYNUrTnVFjQMW0PfKOcTndhiA1hlNGTMN9t05K/es1kS2i0vhlduN44AYODqoo/H
> 1p/DD51zC2mgSVJSCYcG450ISPOiMO/KHO9q4NRZLy+1Ef4E1eHCVghCvy0oi+6L
> J8hsLOrWw+U3xbOLFYCqPWxPDMtjm1IrHAwmio7Fp8h0rCk3WnagBHhJhx9SJH0j
> KAMY+wZ09ct/zaSUPmLdV0+0USsQYQgPBS4RO1x/q/z1rfOc4xcTUvc0eN/HiiML
> 2aT53Xqo5k/jA/sCZ911sywsxdiY8JKEbImHTlYvrYuxTfMgGg6LqiODNajxLjCc
> ACjrLyPgatKJBfdPR65xvWJoFfIEI0h4Usnhc6f7XNRDTUc+uwhHHp3oRxfvYxsN
> EYAI5mmDg9gsCM1f6M9Z2smsS1c58mgotHJw5TO5RMb/opK9f04ofdxUrzj3xkOa
> pr6KZ0IO4126Wv0BEswb
> =NL4C
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150902/f4484e66/attachment.html>

From andrew at andrewspiers.net  Thu Sep  3 06:34:00 2015
From: andrew at andrewspiers.net (Andrew Spiers)
Date: Thu, 3 Sep 2015 16:34:00 +1000
Subject: [Openstack-operators] nova api versions under kilo
Message-ID: <CAFWUrX21OEGW=okyVL2SAc-zGRAhcdM1LPTZPSBWXHbvBW7ekQ@mail.gmail.com>

This call

curl -s -H "X-Auth-Token:${token}" http://hostname:8774/

Against this version of nova-api: Version: 1:2015.1.1+a40~g2864505+trusty-1

returns only a version with id of v2.0,

Making that call against devstack returns versions with ids v2.0 and v2.1.

Is there anything you need to do on kilo to make id v2.1 available?


From mikal at stillhq.com  Thu Sep  3 07:34:40 2015
From: mikal at stillhq.com (Michael Still)
Date: Thu, 3 Sep 2015 17:34:40 +1000
Subject: [Openstack-operators] nova api versions under kilo
In-Reply-To: <CAFWUrX21OEGW=okyVL2SAc-zGRAhcdM1LPTZPSBWXHbvBW7ekQ@mail.gmail.com>
References: <CAFWUrX21OEGW=okyVL2SAc-zGRAhcdM1LPTZPSBWXHbvBW7ekQ@mail.gmail.com>
Message-ID: <CAEd1pt5TNBZ1tTf8uhkVZecAL+fwKsAuUhydcjkNoXSeg2Dv_g@mail.gmail.com>

+oomichi

On Thu, Sep 3, 2015 at 4:34 PM, Andrew Spiers <andrew at andrewspiers.net>
wrote:

> This call
>
> curl -s -H "X-Auth-Token:${token}" http://hostname:8774/
>
> Against this version of nova-api: Version: 1:2015.1.1+a40~g2864505+trusty-1
>
> returns only a version with id of v2.0,
>
> Making that call against devstack returns versions with ids v2.0 and v2.1.
>
> Is there anything you need to do on kilo to make id v2.1 available?
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150903/c786ad11/attachment.html>

From ken1ohmichi at gmail.com  Thu Sep  3 07:49:28 2015
From: ken1ohmichi at gmail.com (Ken'ichi Ohmichi)
Date: Thu, 3 Sep 2015 16:49:28 +0900
Subject: [Openstack-operators] nova api versions under kilo
Message-ID: <CAA393vgPUKwoF=1=XyS6Mue4hPZyp9bVmwGgeGr8pGz8McPcjg@mail.gmail.com>

Hi Andrew,

In Kilo, nova v2.1 API is disabled as the default value in Nova code.
And devstack changes the config to enabled.

We(nova dev team) have fixed it in Liberty by changing the default
value to enabled with https://review.openstack.org/#/c/202724

So if you need to enable v2.1 in Kilo, please change osapi_v3.enabled
to True on nova.config.

Thanks
Ken Ohmichi

---

On Thu, Sep 3, 2015 at 4:34 PM, Andrew Spiers <andrew at andrewspiers.net> wrote:





        This call



        curl -s -H "X-Auth-Token:${token}" http://hostname:8774/



        Against this version of nova-api: Version:
1:2015.1.1+a40~g2864505+trusty-1



        returns only a version with id of v2.0,



        Making that call against devstack returns versions with ids
v2.0 and v2.1.



        Is there anything you need to do on kilo to make id v2.1 available?


From maishsk at maishsk.com  Thu Sep  3 08:04:22 2015
From: maishsk at maishsk.com (Maish Saidel-Keesing)
Date: Thu, 3 Sep 2015 11:04:22 +0300
Subject: [Openstack-operators] [Neutron] Allowing DNS suffix to be set per
 subnet (at least per tenant)
Message-ID: <55E7FF06.2010207@maishsk.com>

Hello all (cross-posting to openstack-operators as well)

Today the setting of the dns suffix that is provided to the instance is 
passed through dhcp_agent.

There is the option of setting different DNS servers per subnet (and and 
therefore tenant) but the domain suffix is something that stays the same 
throughout the whole system is the domain suffix.

I see that this is not a current neutron feature.

Is this on the roadmap? Are there ways to achieve this today? If so I 
would be very interested in hearing how.

Thanks
-- 
Best Regards,
Maish Saidel-Keesing


From andrew at andrewspiers.net  Thu Sep  3 09:37:00 2015
From: andrew at andrewspiers.net (Andrew Spiers)
Date: Thu, 3 Sep 2015 19:37:00 +1000
Subject: [Openstack-operators] nova api versions under kilo
In-Reply-To: <CAA393vgPUKwoF=1=XyS6Mue4hPZyp9bVmwGgeGr8pGz8McPcjg@mail.gmail.com>
References: <CAA393vgPUKwoF=1=XyS6Mue4hPZyp9bVmwGgeGr8pGz8McPcjg@mail.gmail.com>
Message-ID: <CAFWUrX1DSnWMnr==7Kz_7phDfqHva=Bv0XzyX0U1vXegu-x87Q@mail.gmail.com>

Thanks Ken!

On 3 September 2015 at 17:49, Ken'ichi Ohmichi <ken1ohmichi at gmail.com> wrote:
> Hi Andrew,
>
> In Kilo, nova v2.1 API is disabled as the default value in Nova code.
> And devstack changes the config to enabled.
>
> We(nova dev team) have fixed it in Liberty by changing the default
> value to enabled with https://review.openstack.org/#/c/202724
>
> So if you need to enable v2.1 in Kilo, please change osapi_v3.enabled
> to True on nova.config.
>
> Thanks
> Ken Ohmichi
>
> ---
>
> On Thu, Sep 3, 2015 at 4:34 PM, Andrew Spiers <andrew at andrewspiers.net> wrote:
>
>
>
>
>
>         This call
>
>
>
>         curl -s -H "X-Auth-Token:${token}" http://hostname:8774/
>
>
>
>         Against this version of nova-api: Version:
> 1:2015.1.1+a40~g2864505+trusty-1
>
>
>
>         returns only a version with id of v2.0,
>
>
>
>         Making that call against devstack returns versions with ids
> v2.0 and v2.1.
>
>
>
>         Is there anything you need to do on kilo to make id v2.1 available?
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


From maishsk at maishsk.com  Thu Sep  3 19:56:39 2015
From: maishsk at maishsk.com (Maish Saidel-Keesing)
Date: Thu, 3 Sep 2015 22:56:39 +0300
Subject: [Openstack-operators] [openstack-dev] [Neutron] Allowing DNS
 suffix to be set per subnet (at least per tenant)
In-Reply-To: <CAF47bhHfR9qAPAkUFQ=81=mYUpu_wMZ-OyKAEtTP9kJ22KpP9A@mail.gmail.com>
References: <55E7FF06.2010207@maishsk.com>
 <CAF47bhHfR9qAPAkUFQ=81=mYUpu_wMZ-OyKAEtTP9kJ22KpP9A@mail.gmail.com>
Message-ID: <55E8A5F7.9040608@maishsk.com>

On 09/03/15 20:37, Steve Wormley wrote:
> As far as I am aware it is not presently built-in to Openstack. You'll 
> need to add a dnsmasq_config_file option to your dhcp agent 
> configurations and then populate the file with:
> domain=DOMAIN_NAME,CIDR for each network
> i.e.
> domain=example.com <http://example.com>,10.11.22.0/24 
> <http://10.11.22.0/24>
> ...
>
> -Steve
>
Thanks Steve,

I am aware of that 'hack' which has a substantial number of downsides.

The biggest one being that it per subnet - and I afraid to find out what 
would happen if more than one tenant configures the same subnet - this 
could cause all sorts of problems.

And all of this has to be done with appropriate shell permissions to the 
neutron node.

In other words, it could work, but only for a very certain use case.

>
> On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing 
> <maishsk at maishsk.com <mailto:maishsk at maishsk.com>> wrote:
>
>     Hello all (cross-posting to openstack-operators as well)
>
>     Today the setting of the dns suffix that is provided to the
>     instance is passed through dhcp_agent.
>
>     There is the option of setting different DNS servers per subnet
>     (and and therefore tenant) but the domain suffix is something that
>     stays the same throughout the whole system is the domain suffix.
>
>     I see that this is not a current neutron feature.
>
>     Is this on the roadmap? Are there ways to achieve this today? If
>     so I would be very interested in hearing how.
>
>     Thanks
>     -- 
>     Best Regards,
>     Maish Saidel-Keesing
>

-- 
Best Regards,
Maish Saidel-Keesing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150903/ee032cac/attachment.html>

From maishsk at maishsk.com  Thu Sep  3 20:07:37 2015
From: maishsk at maishsk.com (Maish Saidel-Keesing)
Date: Thu, 3 Sep 2015 23:07:37 +0300
Subject: [Openstack-operators] [openstack-dev] [Neutron] Allowing DNS
 suffix to be set per subnet (at least per tenant)
In-Reply-To: <CAG9LJa6TnqPDefNGbsCY8A7U8sd+gdNuHTFiQL+nYrfgHQZ0BQ@mail.gmail.com>
References: <55E7FF06.2010207@maishsk.com>
 <CAF47bhHfR9qAPAkUFQ=81=mYUpu_wMZ-OyKAEtTP9kJ22KpP9A@mail.gmail.com>
 <CAG9LJa6TnqPDefNGbsCY8A7U8sd+gdNuHTFiQL+nYrfgHQZ0BQ@mail.gmail.com>
Message-ID: <55E8A889.3030502@maishsk.com>

On 09/03/15 20:51, Gal Sagie wrote:
> I am not sure if this address what you need specifically, but it would 
> be worth checking these
> two approved liberty specs:
>
> 1) 
> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst
> 2) 
> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst
>
Thanks Gal,

So I see that from the bp [1] the fqdn will be configurable for each and 
every port ?

I think that this does open up a number of interesting possibilities, 
but I would also think that it would be sufficient to do this on a 
subnet level?

We do already have the option of setting nameservers per subnet - I 
assume the data model is already implemented - which is interesting - 
because I don't see that as part of the information that is sent by 
dnsmasq so it must be coming from neutron somewhere.

The domain suffix - definitely is handled by dnsmasq.


> On Thu, Sep 3, 2015 at 8:37 PM, Steve Wormley <openstack at wormley.com 
> <mailto:openstack at wormley.com>> wrote:
>
>     As far as I am aware it is not presently built-in to Openstack.
>     You'll need to add a dnsmasq_config_file option to your dhcp agent
>     configurations and then populate the file with:
>     domain=DOMAIN_NAME,CIDR for each network
>     i.e.
>     domain=example.com <http://example.com>,10.11.22.0/24
>     <http://10.11.22.0/24>
>     ...
>
>     -Steve
>
>
>     On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing
>     <maishsk at maishsk.com <mailto:maishsk at maishsk.com>> wrote:
>
>         Hello all (cross-posting to openstack-operators as well)
>
>         Today the setting of the dns suffix that is provided to the
>         instance is passed through dhcp_agent.
>
>         There is the option of setting different DNS servers per
>         subnet (and and therefore tenant) but the domain suffix is
>         something that stays the same throughout the whole system is
>         the domain suffix.
>
>         I see that this is not a current neutron feature.
>
>         Is this on the roadmap? Are there ways to achieve this today?
>         If so I would be very interested in hearing how.
>
>         Thanks
>         -- 
>         Best Regards,
>         Maish Saidel-Keesing
>
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Best Regards ,
>
> The G.

-- 
Best Regards,
Maish Saidel-Keesing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150903/4fb6dbc0/attachment.html>

From blak111 at gmail.com  Thu Sep  3 21:21:43 2015
From: blak111 at gmail.com (Kevin Benton)
Date: Thu, 3 Sep 2015 14:21:43 -0700
Subject: [Openstack-operators] [openstack-dev] [Neutron] Allowing DNS
 suffix to be set per subnet (at least per tenant)
In-Reply-To: <55E8A889.3030502@maishsk.com>
References: <55E7FF06.2010207@maishsk.com>
 <CAF47bhHfR9qAPAkUFQ=81=mYUpu_wMZ-OyKAEtTP9kJ22KpP9A@mail.gmail.com>
 <CAG9LJa6TnqPDefNGbsCY8A7U8sd+gdNuHTFiQL+nYrfgHQZ0BQ@mail.gmail.com>
 <55E8A889.3030502@maishsk.com>
Message-ID: <CAO_F6JMG5P6EhnrZm3WdzohAdxRh+vzhrXZZ_k+4quAJqEf+bA@mail.gmail.com>

Support for that blueprint already merged[1] so it's a little late to
change it to per-subnet. If that is too fine-grained for your use-case, I
would file an RFE bug[2] to allow it to be set at the subnet level.


1. https://review.openstack.org/#/c/200952/
2.
http://docs.openstack.org/developer/neutron/policies/blueprints.html#rfe-submission-guidelines

On Thu, Sep 3, 2015 at 1:07 PM, Maish Saidel-Keesing <maishsk at maishsk.com>
wrote:

> On 09/03/15 20:51, Gal Sagie wrote:
>
> I am not sure if this address what you need specifically, but it would be
> worth checking these
> two approved liberty specs:
>
> 1)
> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst
> 2)
> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst
>
> Thanks Gal,
>
> So I see that from the bp [1] the fqdn will be configurable for each and
> every port ?
>
> I think that this does open up a number of interesting possibilities, but
> I would also think that it would be sufficient to do this on a subnet level?
>
> We do already have the option of setting nameservers per subnet - I assume
> the data model is already implemented - which is interesting  - because I
> don't see that as part of the information that is sent by dnsmasq so it
> must be coming from neutron somewhere.
>
> The domain suffix - definitely is handled by dnsmasq.
>
>
>
> On Thu, Sep 3, 2015 at 8:37 PM, Steve Wormley <openstack at wormley.com>
> wrote:
>
>> As far as I am aware it is not presently built-in to Openstack. You'll
>> need to add a dnsmasq_config_file option to your dhcp agent configurations
>> and then populate the file with:
>> domain=DOMAIN_NAME,CIDR for each network
>> i.e.
>> domain=example.com,10.11.22.0/24
>> ...
>>
>> -Steve
>>
>>
>> On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing <
>> <maishsk at maishsk.com>maishsk at maishsk.com> wrote:
>>
>>> Hello all (cross-posting to openstack-operators as well)
>>>
>>> Today the setting of the dns suffix that is provided to the instance is
>>> passed through dhcp_agent.
>>>
>>> There is the option of setting different DNS servers per subnet (and and
>>> therefore tenant) but the domain suffix is something that stays the same
>>> throughout the whole system is the domain suffix.
>>>
>>> I see that this is not a current neutron feature.
>>>
>>> Is this on the roadmap? Are there ways to achieve this today? If so I
>>> would be very interested in hearing how.
>>>
>>> Thanks
>>> --
>>> Best Regards,
>>> Maish Saidel-Keesing
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
>
> --
> Best Regards,
> Maish Saidel-Keesing
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150903/a0964550/attachment.html>

From sorrison at gmail.com  Fri Sep  4 03:43:57 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Fri, 4 Sep 2015 13:43:57 +1000
Subject: [Openstack-operators] kilo - neutron - ipset problems?
In-Reply-To: <174FF66E-F66A-452F-BAC8-F7697DA33E2C@godaddy.com>
References: <D1FABCA5.1F2D6%klindgren@godaddy.com>
 <55D5CA1A.1020405@redhat.com>
 <174FF66E-F66A-452F-BAC8-F7697DA33E2C@godaddy.com>
Message-ID: <6655A4EC-58A1-482C-A0FC-039390D7113D@gmail.com>

Hi Kris,

We are moving to neutron in a month and are hitting this in our pre prod environment too.

Sam


> On 2 Sep 2015, at 6:32 am, Kris G. Lindgren <klindgren at godaddy.com> wrote:
> 
> Hello,
> 
> We ran into this again today.
> 
> I created bug: https://bugs.launchpad.net/neutron/+bug/1491131 for this.  With the log files for ~10 seconds before the issue happened to the first couple ipset delete failures.
> 
> 
> 
> 
> On 8/20/15, 6:37 AM, "Miguel Angel Ajo" <mangelajo at redhat.com> wrote:
> 
>> Hi Kris,
>> 
>>   I'm adding Shi Han Zhang to the thread,
>> 
>>   I'm was involved in some refactors during kilo and Han Zhang in some 
>> extra fixes during Liberty [1] [2] [3],
>> 
>>   Could you get us some logs of such failures to see what was 
>> happening around the failure time?, as a minimum we should
>> post the log error traces to a bug in https://bugs.launchpad.net/neutron
>> 
>>    We will be glad to use such information to make the ipset more 
>> fault tolerant, and try to identify the cause of the
>> possible race conditions.
>> 
>> 
>> [1] https://review.openstack.org/#/c/187483/
>> [2] https://review.openstack.org/190991
>> [3] https://review.openstack.org/#/c/187433/
>> 
>> 
>> 
>> Kris G. Lindgren wrote:
>>> 
>>> We have been using ipsets since juno.  Twice now since our kilo 
>>> upgrade we have had issues with ipsets blowing up on a compute node.
>>> 
>>> The first time, was iptables was referencing an ipset that was either 
>>> no longer there or was not added, and was trying to apply the iptables 
>>> config every second and dumping the full iptables-resotore output into 
>>> the log when it failed at TRACE level.
>>> Second time, was that ipsets was failing to remove an element that was 
>>> no longer there.
>>> 
>>> For #1 I solved by restarting the neutron-openvswitch-agent.  For #2 
>>> we just added the entry that ipsets was trying to remove.  It seems 
>>> like we are having some race conditions under kilo that were not 
>>> present under juno (or we managed to run it for 6+ months without it 
>>> biting us).
>>> 
>>> Is anyone else seeing the same problems?  I am noticing some commits 
>>> reverting/re-adding around ipsets in kilo and liberty so trying to 
>>> confirm if I need to open a new bug on this.
>>> ____________________________________________
>>> 
>>> Kris Lindgren
>>> Senior Linux Systems Engineer
>>> GoDaddy, LLC.
>>> 
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> Kris G. Lindgren wrote:
>>> We have been using ipsets since juno.  Twice now since our kilo upgrade we have had issues with ipsets blowing up on a compute node.
>>> 
>>> The first time, was iptables was referencing an ipset that was either no longer there or was not added, and was trying to apply the iptables config every second and dumping the full iptables-resotore output into the log when it failed at TRACE level.
>>> Second time, was that ipsets was failing to remove an element that was no longer there.
>>> 
>>> For #1 I solved by restarting the neutron-openvswitch-agent.  For #2 we just added the entry that ipsets was trying to remove.  It seems like we are having some race conditions under kilo that were not present under juno (or we managed to run it for 6+ months without it biting us).
>>> 
>>> Is anyone else seeing the same problems?  I am noticing some commits reverting/re-adding around ipsets in kilo and liberty so trying to confirm if I need to open a new bug on this.
>>> ____________________________________________
>>> 
>>> Kris Lindgren
>>> Senior Linux Systems Engineer
>>> GoDaddy, LLC.
>>> 
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From comnea.dani at gmail.com  Fri Sep  4 06:14:31 2015
From: comnea.dani at gmail.com (Daniel Comnea)
Date: Fri, 4 Sep 2015 09:14:31 +0300
Subject: [Openstack-operators] [openstack-dev] [Neutron] Allowing DNS
 suffix to be set per subnet (at least per tenant)
In-Reply-To: <CAO_F6JMG5P6EhnrZm3WdzohAdxRh+vzhrXZZ_k+4quAJqEf+bA@mail.gmail.com>
References: <55E7FF06.2010207@maishsk.com>
 <CAF47bhHfR9qAPAkUFQ=81=mYUpu_wMZ-OyKAEtTP9kJ22KpP9A@mail.gmail.com>
 <CAG9LJa6TnqPDefNGbsCY8A7U8sd+gdNuHTFiQL+nYrfgHQZ0BQ@mail.gmail.com>
 <55E8A889.3030502@maishsk.com>
 <CAO_F6JMG5P6EhnrZm3WdzohAdxRh+vzhrXZZ_k+4quAJqEf+bA@mail.gmail.com>
Message-ID: <CAOBAnZNj52t1-iKXqMPs6EBrw4SkL+OWrogMVb7ML_zyoRNiLA@mail.gmail.com>

Kevin,

am i right in saying that the merge above was packaged into Liberty ?

Any chance to be ported to Juno?


Cheers,
Dani



On Fri, Sep 4, 2015 at 12:21 AM, Kevin Benton <blak111 at gmail.com> wrote:

> Support for that blueprint already merged[1] so it's a little late to
> change it to per-subnet. If that is too fine-grained for your use-case, I
> would file an RFE bug[2] to allow it to be set at the subnet level.
>
>
> 1. https://review.openstack.org/#/c/200952/
> 2.
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#rfe-submission-guidelines
>
> On Thu, Sep 3, 2015 at 1:07 PM, Maish Saidel-Keesing <maishsk at maishsk.com>
> wrote:
>
>> On 09/03/15 20:51, Gal Sagie wrote:
>>
>> I am not sure if this address what you need specifically, but it would be
>> worth checking these
>> two approved liberty specs:
>>
>> 1)
>> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst
>> 2)
>> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst
>>
>> Thanks Gal,
>>
>> So I see that from the bp [1] the fqdn will be configurable for each and
>> every port ?
>>
>> I think that this does open up a number of interesting possibilities, but
>> I would also think that it would be sufficient to do this on a subnet level?
>>
>> We do already have the option of setting nameservers per subnet - I
>> assume the data model is already implemented - which is interesting  -
>> because I don't see that as part of the information that is sent by dnsmasq
>> so it must be coming from neutron somewhere.
>>
>> The domain suffix - definitely is handled by dnsmasq.
>>
>>
>>
>> On Thu, Sep 3, 2015 at 8:37 PM, Steve Wormley <openstack at wormley.com>
>> wrote:
>>
>>> As far as I am aware it is not presently built-in to Openstack. You'll
>>> need to add a dnsmasq_config_file option to your dhcp agent configurations
>>> and then populate the file with:
>>> domain=DOMAIN_NAME,CIDR for each network
>>> i.e.
>>> domain=example.com,10.11.22.0/24
>>> ...
>>>
>>> -Steve
>>>
>>>
>>> On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing <
>>> <maishsk at maishsk.com>maishsk at maishsk.com> wrote:
>>>
>>>> Hello all (cross-posting to openstack-operators as well)
>>>>
>>>> Today the setting of the dns suffix that is provided to the instance is
>>>> passed through dhcp_agent.
>>>>
>>>> There is the option of setting different DNS servers per subnet (and
>>>> and therefore tenant) but the domain suffix is something that stays the
>>>> same throughout the whole system is the domain suffix.
>>>>
>>>> I see that this is not a current neutron feature.
>>>>
>>>> Is this on the roadmap? Are there ways to achieve this today? If so I
>>>> would be very interested in hearing how.
>>>>
>>>> Thanks
>>>> --
>>>> Best Regards,
>>>> Maish Saidel-Keesing
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>>
>> --
>> Best Regards,
>> Maish Saidel-Keesing
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> Kevin Benton
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150904/21eab95b/attachment.html>

From ihrachys at redhat.com  Fri Sep  4 07:26:23 2015
From: ihrachys at redhat.com (Ihar Hrachyshka)
Date: Fri, 4 Sep 2015 09:26:23 +0200
Subject: [Openstack-operators] [openstack-dev] [Neutron] Allowing DNS
	suffix to be set per subnet (at least per tenant)
In-Reply-To: <CAOBAnZNj52t1-iKXqMPs6EBrw4SkL+OWrogMVb7ML_zyoRNiLA@mail.gmail.com>
References: <55E7FF06.2010207@maishsk.com>
 <CAF47bhHfR9qAPAkUFQ=81=mYUpu_wMZ-OyKAEtTP9kJ22KpP9A@mail.gmail.com>
 <CAG9LJa6TnqPDefNGbsCY8A7U8sd+gdNuHTFiQL+nYrfgHQZ0BQ@mail.gmail.com>
 <55E8A889.3030502@maishsk.com>
 <CAO_F6JMG5P6EhnrZm3WdzohAdxRh+vzhrXZZ_k+4quAJqEf+bA@mail.gmail.com>
 <CAOBAnZNj52t1-iKXqMPs6EBrw4SkL+OWrogMVb7ML_zyoRNiLA@mail.gmail.com>
Message-ID: <32F63AEB-460C-46FB-8F30-517C2AEA1563@redhat.com>

> On 04 Sep 2015, at 08:14, Daniel Comnea <comnea.dani at gmail.com> wrote:
> 
> Kevin,
> 
> am i right in saying that the merge above was packaged into Liberty ?
> 
> Any chance to be ported to Juno?
> 

There is no chance a new feature will be backported to any stable branch, even Kilo. At least in upstream.

Ihar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150904/5267415e/attachment.pgp>

From jay at openstack.org  Fri Sep  4 17:09:26 2015
From: jay at openstack.org (Jay Fankhauser)
Date: Fri, 4 Sep 2015 12:09:26 -0500
Subject: [Openstack-operators] =?utf-8?q?OpenStack_Community_Weekly_Newsle?=
 =?utf-8?b?dHRlciAoQXVnLiwgMjkg4oCTIFNlcHQuLCA0KQ==?=
Message-ID: <12AADD3D-2DB4-48F7-A000-34F68FD1ECE2@openstack.org>

The Road to Tokyo 

Register now: full access registration prices increase on?9/30 <https://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598>
Discounted registration for?nonprofit/government/students? <https://openstack.formstack.com/forms/openstack_summit_tokyo_discounted_registration>
Get your OpenStack Summit Tokyo visa in five steps: Deadline for Visa invitation requests is?10/1 <http://superuser.openstack.org/articles/get-your-openstack-summit-tokyo-visa-in-five-steps>
The schedule for the OpenStack Summit in Tokyo is now available <https://www.openstack.org/summit/tokyo-2015/schedule/>

Reports from Previous Events 

OpenStack Day Seattle tackles enterprise adoption and diversity <http://superuser.openstack.org/articles/openstack-day-seattle-tackles-enterprise-adoption-and-diversity>

Deadlines and Contributors Notifications 

QA End of Cycle Code Sprint: September 14-16 @HP Fort Collins, CO, US <https://wiki.openstack.org/wiki/QA/CodeSprintLibertyFortCollins> 
[openstack-announce] [release] Liberty-3 development milestone <http://lists.openstack.org/pipermail/openstack-announce/2015-September/000588.html>
[openstack-announce] [Swift] Swift 2.4.0 release <http://lists.openstack.org/pipermail/openstack-announce/2015-September/000575.html>

Security Advisories and Notices 

OSSA-2015-017: Nova may fail to delete images in resize state <https://security.openstack.org/ossa/OSSA-2015-017.html>

Tips ?n Tricks 

By Stefano Maffulli <http://maffulli.net/>: How I evaluate submissions for talks at OpenStack Summits <http://maffulli.net/2015/08/31/how-i-evaluate-submissions-for-talks-at-openstack-summits/>
By Gal Sagie <http://galsagie.github.io/>: Project Kuryr brings container networking to OpenStack Neutron <http://superuser.openstack.org/articles/project-kuryr-brings-container-networking-to-openstack-neutron>
By Kevin Jackson, Cody Bunch and Egle Sigler: The latest edition of the "OpenStack Cloud Computing Cookbook" offers updated recipes <http://superuser.openstack.org/articles/the-latest-edition-of-the-openstack-cloud-computing-cookbook-offers-updated-recipes>

Upcoming Events <https://www.openstack.org/community/events> 

Sep 04, 2015?Neutron Advanced Services talk <http://www.meetup.com/openstack/events/215648162/>
Sep 04, 2015?SFBay OpenStack Hackathon #OSSFO <http://www.meetup.com/openstack/events/215648062/>
Sep 04, 2015?SFBay OpenStack Advanced Track #OSSFO Topic: Monasca and Heat <http://www.meetup.com/openstack/events/224777019/>
Sep 08, 2015?Manchester OpenStack Meetup?Manchester, Greater Manchester, GB <http://www.meetup.com/Manchester-OpenStack-Meetup/events/223737111/>
Sep 08, 2015?11th Swiss OpenStack User Group Meetup with Docker?Z?rich, CH <http://www.meetup.com/openstack-ch/events/224118314/> 
Sep 08, 2015?First OpenStack Meetup?Manchester, GB <http://www.meetup.com/Manchester-OpenStack-Meetup/events/223737111/>
Sep 12, 2015?OpenStack Bangalore Meetup?Bangalore, Karnataka, IN <http://www.meetup.com/Indian-OpenStack-User-Group/events/224709593/>
Sep 14 - 15, 2015?Extensibility in OpenStack Swift and what you can do with it! (#25)?Washington D.C., DC, US <http://www.meetup.com/OpenStackDC/events/223978615/>
Sep 15, 2015?OpenStack Project Leader - visiting Belgium?Diegem, BE <http://www.meetup.com/OpenStack-Belgium-Meetup/events/224736832/>
Sep 16 - 17, 2015?OpenStack Austin - Sept. Meetup?Austin, TX, US <http://www.meetup.com/OpenStack-Austin/events/224238339/>
Sep 17, 2015?OpenStack Benelux Conference 2015?Bussum, NL <http://www.meetup.com/Openstack-Amsterdam/events/223038288/>
Sep 18, 2015?OpenStack PDX Meetup <http://www.meetup.com/openstack-pdx/events/224572482/>
 <http://www.meetup.com/openstack/events/223231183/>Sep 18, 2015?SFBay OpenStack Hackathon #OSSFO <http://www.meetup.com/openstack/events/223231183/> San Francisco, CA, US <http://www.meetup.com/openstack/events/223231183/>
Sep 21 - 24, 2015?Storage Developer Conference?Santa Clara, CA, US <http://www.snia.org/events/storage-developer>
Sep 29?? 30, 2015 Cloud Storage in OpenStack <https://groups.openstack.org/groups/frederick-md/cloud-storage-openstack>
Oct 01, 2015?OpenStack Meetup Cluj?Cluj-Napoc, Cluj, RO <http://www.meetup.com/OpenStackRomania/events/222910344/>
Oct 01, 2015?South Bay OpenStack Meetup, Beginner track San Francisco, CA, US <http://www.meetup.com/openstack/events/221806052/>
Oct 01 - 02, 2015?October OpenStack Meetup - SDN and Containers?Chicago, IL, US <http://www.meetup.com/meetup-group-NjZdcegA/events/225081881/>
Oct 04 - 08, 2015?Gartner SymposiumITxpo?Orlando, FL, US <http://www.gartner.com/events/na/orlando-symposium>

Other News 

Technical Committee Highlights September 2, 2015 <https://www.openstack.org/blog/2015/09/technical-committee-highlights-september-2-2015/>
What's behind the second wave of cloud adoption <http://superuser.openstack.org/articles/what-s-behind-the-second-wave-of-cloud-adoption>
[openstack-dev] [all] Base feature deprecation policy <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html>
[openstack-dev] [nova] [docs] Are cells still 'experimental'? <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073550.html>
[openstack-dev] [all] Criteria for applying vulnerability:managed tag <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073435.html>

The weekly newsletter is a way for the community to learn about all the various activities in the OpenStack world._______________________________________________
Community mailing list
Community at lists.openstack.org <mailto:Community at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/community <http://lists.openstack.org/cgi-bin/mailman/listinfo/community>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150904/6fe5fc74/attachment.html>

From doc at aedo.net  Fri Sep  4 18:05:03 2015
From: doc at aedo.net (Christopher Aedo)
Date: Fri, 4 Sep 2015 11:05:03 -0700
Subject: [Openstack-operators] [app-catalog] App Catalog IRC meeting minutes
	- 9/3/2015
Message-ID: <CA+odVQG1=Z7CTQ8Hv_ho-xw6DGUNBsbK2btTW2tx+dcTTdH_aA@mail.gmail.com>

We had a good meeting yesterday which included a little cheer for the
Community App Catalog project being accepted into the big tent (thanks
to everyone who has been supporting our efforts all along!)  The bulk
of the meeting was then devoted to discussing our plans for the next
generation of the site.  We've started the effort by outlining on
etherpad [1] all the features we need the site to support.  Next up we
are going to start evaluating potential frameworks we can use to build
a new site quickly while still making it easy to deploy and support
(and extend down the road.)  If you have useful opinions/experience
and are interested in helping plan this, please check out the etherpad
and join us on IRC to discuss.

As always, please join us on IRC (#openstack-app-catalog), or speak up
here on the mailing list if you want to help us make this the top
destination for people using OpenStack clouds!

[1] https://etherpad.openstack.org/p/app-catalog-v2-backend

-Christopher

=================================
#openstack-meeting-3: app-catalog
=================================
Meeting started by docaedo at 17:00:15 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-09-03-17.00.log.html
.

Meeting summary
---------------
* rollcall  (docaedo, 17:00:30)

* Status updates (docaedo)  (docaedo, 17:01:21)
  * LINK: https://review.openstack.org/#/c/217957/  (docaedo, 17:01:43)
  * LINK: https://review.openstack.org/#/c/219809/  (docaedo, 17:02:57)
  * LINK: http://bit.ly/1N37aMS  (docaedo, 17:03:09)
  * LINK: https://review.openstack.org/#/c/218898/  (docaedo, 17:06:31)

* Review/discuss "new site plans" etherpad (docaedo)  (docaedo,
  17:10:47)
  * LINK: https://etherpad.openstack.org/p/app-catalog-v2-backend
    (docaedo, 17:10:52)

* Open discussion  (docaedo, 17:38:11)

Meeting ended at 17:43:30 UTC.

People present (lines said)
---------------------------
* docaedo (55)
* kfox1111 (47)
* ativelkov (17)
* kzaitsev_mb (9)
* j^2 (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4


From erent at skyatlas.com  Mon Sep  7 07:29:52 2015
From: erent at skyatlas.com (=?UTF-8?Q?Eren_T=c3=bcrkay?=)
Date: Mon, 7 Sep 2015 10:29:52 +0300
Subject: [Openstack-operators] [neutron] Kilo neutron-ns-metadata-proxy
	Problem
In-Reply-To: <55E440F8.6030206@skyatlas.com>
References: <55E440F8.6030206@skyatlas.com>
Message-ID: <55ED3CF0.9030207@skyatlas.com>

On 31-08-2015 14:56, Eren T?rkay wrote:
> Hello,

Hello agiain,

> I installed Kilo neutron. I can create networks, namespaces are created and
> neutron-ns-metadata-proxy is running. However, VM's cannot get SSH keys. I've
> isolated the problem down the network namespace and a particular iptables rule.
> Here is the iptables rule, it accepts the packets marked with 0x1 and rejects it:
> 
> -A neutron-vpn-agen-INPUT -m mark --mark 0x1 -j ACCEPT
> -A neutron-vpn-agen-INPUT -p tcp -m tcp --dport 8775 -j DROP
> 
> When I remove the DROP rule, everything works. My question is how are these
> packages to 169.245.169.254 is marked with 0x1? The iptables rules inside the
> namespace can be found here: http://paste.ubuntu.com/12237691/

I am still stuck at this problem. Has anyone experienced it? I would be really
happy if someone can give a tip regarding to the issue.

Regards,

-- 
Eren T?rkay, System Administrator
https://skyatlas.com/ | +90 850 885 0357

Yildiz Teknik Universitesi Davutpasa Kampusu
Teknopark Bolgesi, D2 Blok No:107
Esenler, Istanbul Pk.34220

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150907/735ef726/attachment.pgp>

From ihrachys at redhat.com  Mon Sep  7 08:52:42 2015
From: ihrachys at redhat.com (Ihar Hrachyshka)
Date: Mon, 7 Sep 2015 10:52:42 +0200
Subject: [Openstack-operators] [neutron] Kilo neutron-ns-metadata-proxy
	Problem
In-Reply-To: <55ED3CF0.9030207@skyatlas.com>
References: <55E440F8.6030206@skyatlas.com> <55ED3CF0.9030207@skyatlas.com>
Message-ID: <3CFEFBA9-E8AE-4E7E-A482-F3B414910F0C@redhat.com>

> On 07 Sep 2015, at 09:29, Eren T?rkay <erent at skyatlas.com> wrote:
> 
> On 31-08-2015 14:56, Eren T?rkay wrote:
>> Hello,
> 
> Hello agiain,
> 
>> I installed Kilo neutron. I can create networks, namespaces are created and
>> neutron-ns-metadata-proxy is running. However, VM's cannot get SSH keys. I've
>> isolated the problem down the network namespace and a particular iptables rule.
>> Here is the iptables rule, it accepts the packets marked with 0x1 and rejects it:
>> 
>> -A neutron-vpn-agen-INPUT -m mark --mark 0x1 -j ACCEPT
>> -A neutron-vpn-agen-INPUT -p tcp -m tcp --dport 8775 -j DROP
>> 
>> When I remove the DROP rule, everything works. My question is how are these
>> packages to 169.245.169.254 is marked with 0x1? The iptables rules inside the
>> namespace can be found here: http://paste.ubuntu.com/12237691/
> 
> I am still stuck at this problem. Has anyone experienced it? I would be really
> happy if someone can give a tip regarding to the issue.
> 
> Regards,


See metadata_access_mark option in etc/l3_agent.ini

Ihar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150907/c84b17f8/attachment.pgp>

From erent at skyatlas.com  Mon Sep  7 08:59:11 2015
From: erent at skyatlas.com (=?UTF-8?Q?Eren_T=c3=bcrkay?=)
Date: Mon, 7 Sep 2015 11:59:11 +0300
Subject: [Openstack-operators] [neutron] Kilo neutron-ns-metadata-proxy
 Problem
In-Reply-To: <3CFEFBA9-E8AE-4E7E-A482-F3B414910F0C@redhat.com>
References: <55E440F8.6030206@skyatlas.com> <55ED3CF0.9030207@skyatlas.com>
 <3CFEFBA9-E8AE-4E7E-A482-F3B414910F0C@redhat.com>
Message-ID: <55ED51DF.30804@skyatlas.com>

On 07-09-2015 11:52, Ihar Hrachyshka wrote:
> See metadata_access_mark option in etc/l3_agent.ini

Hello,

This option is set 0x1 by default. The debug log prints:

metadata_access_mark           = 0x1

Should I change this value to another one?

-- 
Eren T?rkay, System Administrator
https://skyatlas.com/ | +90 850 885 0357

Yildiz Teknik Universitesi Davutpasa Kampusu
Teknopark Bolgesi, D2 Blok No:107
Esenler, Istanbul Pk.34220

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150907/d98e82b4/attachment.pgp>

From erent at skyatlas.com  Mon Sep  7 11:35:53 2015
From: erent at skyatlas.com (=?UTF-8?Q?Eren_T=c3=bcrkay?=)
Date: Mon, 7 Sep 2015 14:35:53 +0300
Subject: [Openstack-operators] [neutron] Kilo neutron-ns-metadata-proxy
	Problem
In-Reply-To: <55ED3CF0.9030207@skyatlas.com>
References: <55E440F8.6030206@skyatlas.com> <55ED3CF0.9030207@skyatlas.com>
Message-ID: <55ED7699.7070708@skyatlas.com>

On 07-09-2015 10:29, Eren T?rkay wrote:
> I am still stuck at this problem. Has anyone experienced it? I would be really
> happy if someone can give a tip regarding to the issue.

Hello all,

Sorry for the inconvenience. I misinterpreted the actual error. Instances could
reach to the namespace and netns proxy service but the proxy was sending HTTP
404 errors. That left me to the configuration issue. I fixed the
metadata_agent.ini (the nova URL was mistyped) and it was fixed.

Regards,


-- 
Eren T?rkay, System Administrator
https://skyatlas.com/ | +90 850 885 0357

Yildiz Teknik Universitesi Davutpasa Kampusu
Teknopark Bolgesi, D2 Blok No:107
Esenler, Istanbul Pk.34220

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150907/2d55215f/attachment.pgp>

From jean-daniel.bonnetot at ovh.net  Mon Sep  7 14:48:22 2015
From: jean-daniel.bonnetot at ovh.net (Jean-Daniel Bonnetot)
Date: Mon, 7 Sep 2015 16:48:22 +0200
Subject: [Openstack-operators] Rate limit an max_count
Message-ID: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>

Hi,

I try to limit the max instances a user can create per minute.

With rate limit, we can limit the number of call/min on POST */servers for example.
But the user can still use the max_count paramteter in his API call to boot dozen of thousand of instances and make the scheduler crazy.

I?m pretty sure that there is a possiblity to limit the max_count and so define a max instances/min.
Do you know something to do it?

--
Jean-Daniel
@pilgrimstack






From abhishek.talwar at tcs.com  Tue Sep  8 05:59:48 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Tue, 8 Sep 2015 11:29:48 +0530
Subject: [Openstack-operators] [kilo] [ceilometer] : How to get meters like
 memory.usage and others in my setup
Message-ID: <OF5CB5D71F.AD59BEAB-ON65257EBA.0020F0F8-65257EBA.0020F101@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150908/5886c4f6/attachment.html>

From tom at openstack.org  Tue Sep  8 09:10:40 2015
From: tom at openstack.org (Tom Fifield)
Date: Tue, 8 Sep 2015 17:10:40 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Agenda Brainstorming
In-Reply-To: <55E74D8F.9020203@openstack.org>
References: <55E74D8F.9020203@openstack.org>
Message-ID: <55EEA610.30802@openstack.org>

Ping!

This is your chance to provide input on our design summit track for 
Tokyo. Add your ideas on the etherpad below!


https://etherpad.openstack.org/p/TYO-ops-meetup


On 03/09/15 03:27, Tom Fifield wrote:
> Hi all,
>
> Thanks for those who made it to the recent meetup in Palo Alto. It was a
> fantastic couple of days, and many are excited to get started on talking
> about our ops track in the Tokyo design summit.
>
>
> Recall that this is in addition to the operations and other conference
> track's presentations. It's aimed at giving us a design-summit-style
> place to congregate, swap best practices, ideas and give feedback.
>
>
> As usual, we're working to act on the feedback from all past events to
> make this one better than ever. One that we continue to work on is the
> need to see action happen as a result of this event, so please - when
> you are suggesting sessions in the below etherpad please try and phrase
> them in a way that will probably result in things happening afterward.
>
>
> **********************************************************************
>
> Please propose session ideas on:
>
> https://etherpad.openstack.org/p/TYO-ops-meetup
>
> ensuring each session suggestion will have a result.
>
> **********************************************************************
>
>
> The room allocations are still being worked out, but the current
> thinking is that we will interleave general sessions and working groups
> across Tuesday and Wednesday, to allow for attendance from ops in the
> cross-project sessions.
>
>
> More as it comes, and as always, further information about ops meetups
> and notes from the past can be found on the wiki @:
>
> https://wiki.openstack.org/wiki/Operations/Meetups
>
> Finally, don't forget to register ASAP!
> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>
>
> Regards,
>
>
> Tom
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From josephbajin at gmail.com  Tue Sep  8 11:42:24 2015
From: josephbajin at gmail.com (Joseph Bajin)
Date: Tue, 8 Sep 2015 07:42:24 -0400
Subject: [Openstack-operators] [Tools/Monitoring] Finding a new Tools and
	Monitoring Working group Time
Message-ID: <CAGm6i3mfx27NShPvFA2ftoCdcN86TyjbMnUYN+VkFw_coxURfw@mail.gmail.com>

Hi Everyone,

One of the items taken from the Operators Meet-up was that the time (10am
EST) was too early for the west coast people.   I've been looking at the
meeting calendar and have a few suggested times that I'd like to see if
they would work for others to get more participation.

Odd every other Wednesday's - ( 9/9, 9/23, etc)

Suggested times - (All these are in EST)

- 1pm
- 2pm
- 3pm

If Wednesday's do not work, please let me know as well, and I can find
additional times.  It seemed that Wednesdays worked for most when we first
stood up the group, but it could be moved.

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150908/564b030c/attachment.html>

From behzad.dastur at gmail.com  Tue Sep  8 14:47:53 2015
From: behzad.dastur at gmail.com (Behzad Dastur)
Date: Tue, 8 Sep 2015 07:47:53 -0700
Subject: [Openstack-operators] [Tools/Monitoring] Finding a new Tools
 and Monitoring Working group Time
In-Reply-To: <CAGm6i3mfx27NShPvFA2ftoCdcN86TyjbMnUYN+VkFw_coxURfw@mail.gmail.com>
References: <CAGm6i3mfx27NShPvFA2ftoCdcN86TyjbMnUYN+VkFw_coxURfw@mail.gmail.com>
Message-ID: <CAM2dmf17DmTMtu1eMVPOPG2RbsziDktsB80-K3PqY2_M_ChXpA@mail.gmail.com>

I have been meaning to join this meeting. Thanks for moving the meeting by
couple of hours.

Behzad

On Tue, Sep 8, 2015 at 4:42 AM, Joseph Bajin <josephbajin at gmail.com> wrote:

> Hi Everyone,
>
> One of the items taken from the Operators Meet-up was that the time (10am
> EST) was too early for the west coast people.   I've been looking at the
> meeting calendar and have a few suggested times that I'd like to see if
> they would work for others to get more participation.
>
> Odd every other Wednesday's - ( 9/9, 9/23, etc)
>
> Suggested times - (All these are in EST)
>
> - 1pm
> - 2pm
> - 3pm
>
> If Wednesday's do not work, please let me know as well, and I can find
> additional times.  It seemed that Wednesdays worked for most when we first
> stood up the group, but it could be moved.
>
> --Joe
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150908/b3d899db/attachment.html>

From gord at live.ca  Tue Sep  8 19:45:10 2015
From: gord at live.ca (gord chung)
Date: Tue, 8 Sep 2015 15:45:10 -0400
Subject: [Openstack-operators] [aodh][ceilometer] (re)introducing Aodh -
	OpenStack Alarming
Message-ID: <BLU436-SMTP32A3A7E84295D52C56310CDE530@phx.gbl>

hi all,

as you may have heard, in an effort to simplify OpenStack Telemetry 
(Ceilometer) and streamline it's code, the alarming functionality 
provided by OpenStack Telemetry has been moved to it's own 
repository[1]. The new project is called Aodh[2]. the idea is that Aodh 
will grow as it's own entity, with it's own distinct core team, under 
the Telemetry umbrella. this way, we will have a focused team 
specifically for the alarming aspects of Telemetry. as always, feedback 
and contributions are welcomed[3].

in the coming days, we will release a migration/changes document to 
explain the differences between the original alarming code and Aodh. all 
effort was made to maintain compatibility in configurations such that it 
should be possible to take the existing configuration and reuse it for 
Aodh deployment.

some quick notes:
- the existing alarming code will remain consumable for Liberty release 
(but in deprecated state)
- all new functionality (ie. inline/streaming alarm evaluations) will be 
added only to Aodh
- client and api support has been added to common Ceilometer interfaces 
such that if Aodh is enabled, the client can still be used and redirect 
to Aodh.
- mailing list items can be tagged with [aodh]
- irc discussions will remain under #openstack-ceilometer

many thanks for all those who worked on the code split and integration 
testing.

[1] https://github.com/openstack/aodh
[2] http://www.behindthename.com/name/aodh
[3] https://launchpad.net/aodh

cheers,

-- 
gord



From jon at jonproulx.com  Tue Sep  8 20:44:27 2015
From: jon at jonproulx.com (Jonathan Proulx)
Date: Tue, 8 Sep 2015 16:44:27 -0400
Subject: [Openstack-operators] Milti-site Keystone & Galera
Message-ID: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>

Hi All,

I'm pretty close to opening a second region in my cloud at a second
physical location.

The plan so far had been to only share keystone between the regions
(nova, glance, cinder etc would be distinct) and implement this by
using MariaDB with galera replication between sites with each site
having it's own gmcast_segment to minimize the long distance catter
plus a 3rd site with a galera arbitrator for the obvious reason.

Today I was warned against using this in a multi writer setup. I'd planned
 on one writer per physical location.

I had been under the impression this was the 'done thing' for
geographically sepperate regions, was I wrong? Should I replicate just
for DR and always pick a single possible remote write site?

site to site link is 2x10G (different physical paths), short link is
2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
link shouldn't be much longer but isn't yet complete to test.

-Jon


From jaypipes at gmail.com  Tue Sep  8 21:00:00 2015
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 8 Sep 2015 17:00:00 -0400
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
Message-ID: <55EF4C50.7020109@gmail.com>

On 09/08/2015 04:44 PM, Jonathan Proulx wrote:
> Hi All,
>
> I'm pretty close to opening a second region in my cloud at a second
> physical location.
>
> The plan so far had been to only share keystone between the regions
> (nova, glance, cinder etc would be distinct) and implement this by
> using MariaDB with galera replication between sites with each site
> having it's own gmcast_segment to minimize the long distance catter
> plus a 3rd site with a galera arbitrator for the obvious reason.

I would also strongly consider adding the Glance registry database to 
the same cross-WAN Galera cluster. At AT&T, we had such a setup for 
Keystone and Glance registry databases at 10+ deployment zones across 6+ 
datacenters across the nation. Besides adjusting the latency timeout for 
the Galera settings, we made no other modifications to our 
internal-to-an-availability-zone Nova database Galera cluster settings.

The Keystone and Glance registry databases have a virtually identical 
read and write data access pattern: small record/row size, small number 
of INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT 
operations on a small data set. This data access pattern is an ideal fit 
for a WAN-replicated Galera cluster.

> Today I was warned against using this in a multi writer setup. I'd planned
>   on one writer per physical location.

I don't know who warned you about this, but it's not an issue in the 
real world. We ran in full multi-writer mode, with each deployment zone 
writing to and reading from its nearest Galera cluster nodes. No issues.

Best,
-jay

> I had been under the impression this was the 'done thing' for
> geographically sepperate regions, was I wrong? Should I replicate just
> for DR and always pick a single possible remote write site?
>
> site to site link is 2x10G (different physical paths), short link is
> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
> link shouldn't be much longer but isn't yet complete to test.
>
> -Jon
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


From jon at jonproulx.com  Tue Sep  8 21:22:18 2015
From: jon at jonproulx.com (Jonathan Proulx)
Date: Tue, 8 Sep 2015 17:22:18 -0400
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <55EF4C50.7020109@gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
Message-ID: <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>

Thanks Jay & Matt,

That's basically what I thought, so I'll keep thinking it :)

We're not replicating glance DB because images will be stored in
different local Ceph storage on each side so the images won't be
directly available.  We thought about moving back to a file back end
and rsync'ing but RBD gets us lots of fun things we want to keep
(quick start, copy on write thin cloned ephemeral storage etc...) so
decided to live with making our users copy images around.

-Jon



On Tue, Sep 8, 2015 at 5:00 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 09/08/2015 04:44 PM, Jonathan Proulx wrote:
>>
>> Hi All,
>>
>> I'm pretty close to opening a second region in my cloud at a second
>> physical location.
>>
>> The plan so far had been to only share keystone between the regions
>> (nova, glance, cinder etc would be distinct) and implement this by
>> using MariaDB with galera replication between sites with each site
>> having it's own gmcast_segment to minimize the long distance catter
>> plus a 3rd site with a galera arbitrator for the obvious reason.
>
>
> I would also strongly consider adding the Glance registry database to the
> same cross-WAN Galera cluster. At AT&T, we had such a setup for Keystone and
> Glance registry databases at 10+ deployment zones across 6+ datacenters
> across the nation. Besides adjusting the latency timeout for the Galera
> settings, we made no other modifications to our
> internal-to-an-availability-zone Nova database Galera cluster settings.
>
> The Keystone and Glance registry databases have a virtually identical read
> and write data access pattern: small record/row size, small number of
> INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT operations
> on a small data set. This data access pattern is an ideal fit for a
> WAN-replicated Galera cluster.
>
>> Today I was warned against using this in a multi writer setup. I'd planned
>>   on one writer per physical location.
>
>
> I don't know who warned you about this, but it's not an issue in the real
> world. We ran in full multi-writer mode, with each deployment zone writing
> to and reading from its nearest Galera cluster nodes. No issues.
>
> Best,
> -jay
>
>> I had been under the impression this was the 'done thing' for
>> geographically sepperate regions, was I wrong? Should I replicate just
>> for DR and always pick a single possible remote write site?
>>
>> site to site link is 2x10G (different physical paths), short link is
>> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
>> link shouldn't be much longer but isn't yet complete to test.
>>
>> -Jon
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


From jean-daniel.bonnetot at ovh.net  Wed Sep  9 08:56:20 2015
From: jean-daniel.bonnetot at ovh.net (Jean-Daniel Bonnetot)
Date: Wed, 9 Sep 2015 10:56:20 +0200
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
Message-ID: <9C1474B8-214E-4B0B-8E4A-CCD3567987DF@ovh.net>

I?m very surprised to be the only one with this need 8)

So I write a blueprint.
https://blueprints.launchpad.net/nova/+spec/limit-spawn-rate-for-users
https://review.openstack.org/#/c/221375/

?
Jean-Daniel
@pilgrimstack




> Le 7 sept. 2015 ? 16:48, Jean-Daniel Bonnetot <jean-daniel.bonnetot at ovh.net> a ?crit :
> 
> Hi,
> 
> I try to limit the max instances a user can create per minute.
> 
> With rate limit, we can limit the number of call/min on POST */servers for example.
> But the user can still use the max_count paramteter in his API call to boot dozen of thousand of instances and make the scheduler crazy.
> 
> I?m pretty sure that there is a possiblity to limit the max_count and so define a max instances/min.
> Do you know something to do it?
> 
> --
> Jean-Daniel
> @pilgrimstack
> 
> 
> 
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


From serverascode at gmail.com  Wed Sep  9 13:05:16 2015
From: serverascode at gmail.com (Curtis)
Date: Wed, 9 Sep 2015 07:05:16 -0600
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <9C1474B8-214E-4B0B-8E4A-CCD3567987DF@ovh.net>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
 <9C1474B8-214E-4B0B-8E4A-CCD3567987DF@ovh.net>
Message-ID: <CAJ_JamDjsDd9qWOd04MEf1ED7ZbKwZEA7bDkKgjgK4SHiL9wkw@mail.gmail.com>

On Wed, Sep 9, 2015 at 2:56 AM, Jean-Daniel Bonnetot
<jean-daniel.bonnetot at ovh.net> wrote:
> I?m very surprised to be the only one with this need 8)

Hi,

I think it makes a lot of sense and would be useful to me for sure, so
thanks for taking the time to write the blueprint. :)

Thanks,
Curtis.

>
> So I write a blueprint.
> https://blueprints.launchpad.net/nova/+spec/limit-spawn-rate-for-users
> https://review.openstack.org/#/c/221375/
>
> ?
> Jean-Daniel
> @pilgrimstack
>
>
>
>
>> Le 7 sept. 2015 ? 16:48, Jean-Daniel Bonnetot <jean-daniel.bonnetot at ovh.net> a ?crit :
>>
>> Hi,
>>
>> I try to limit the max instances a user can create per minute.
>>
>> With rate limit, we can limit the number of call/min on POST */servers for example.
>> But the user can still use the max_count paramteter in his API call to boot dozen of thousand of instances and make the scheduler crazy.
>>
>> I?m pretty sure that there is a possiblity to limit the max_count and so define a max instances/min.
>> Do you know something to do it?
>>
>> --
>> Jean-Daniel
>> @pilgrimstack
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Twitter: @serverascode
Blog: serverascode.com


From serverascode at gmail.com  Wed Sep  9 16:18:28 2015
From: serverascode at gmail.com (Curtis)
Date: Wed, 9 Sep 2015 10:18:28 -0600
Subject: [Openstack-operators] [Tools/Monitoring] Finding a new Tools
 and Monitoring Working group Time
In-Reply-To: <CAGm6i3mfx27NShPvFA2ftoCdcN86TyjbMnUYN+VkFw_coxURfw@mail.gmail.com>
References: <CAGm6i3mfx27NShPvFA2ftoCdcN86TyjbMnUYN+VkFw_coxURfw@mail.gmail.com>
Message-ID: <CAJ_JamAN6ZH7jeT6pnC4omp=QAsqEXZqQy1V+WnDOBOjv=aHHQ@mail.gmail.com>

On Tue, Sep 8, 2015 at 5:42 AM, Joseph Bajin <josephbajin at gmail.com> wrote:
> Hi Everyone,
>
> One of the items taken from the Operators Meet-up was that the time (10am
> EST) was too early for the west coast people.   I've been looking at the
> meeting calendar and have a few suggested times that I'd like to see if they
> would work for others to get more participation.
>
> Odd every other Wednesday's - ( 9/9, 9/23, etc)
>
> Suggested times - (All these are in EST)
>
> - 1pm
> - 2pm
> - 3pm

Hi,

I haven't attended previously but would like to.

Any of those times work for me.

Also, not sure if most meetings do this or not, but I like how the
os-ansible-deployment project has a list of regular users on their
wiki and the person running the meeting can just paste that into IRC
to remind ppl of the meeting [1].

Thanks,
Curtis.

[1]: https://wiki.openstack.org/wiki/Meetings/openstack-ansible

>
> If Wednesday's do not work, please let me know as well, and I can find
> additional times.  It seemed that Wednesdays worked for most when we first
> stood up the group, but it could be moved.
>
> --Joe
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Twitter: @serverascode
Blog: serverascode.com


From david.wahlstrom at gmail.com  Wed Sep  9 16:21:46 2015
From: david.wahlstrom at gmail.com (David Wahlstrom)
Date: Wed, 9 Sep 2015 09:21:46 -0700
Subject: [Openstack-operators] [Tools/Monitoring] Finding a new Tools
 and Monitoring Working group Time
In-Reply-To: <CAJ_JamAN6ZH7jeT6pnC4omp=QAsqEXZqQy1V+WnDOBOjv=aHHQ@mail.gmail.com>
References: <CAGm6i3mfx27NShPvFA2ftoCdcN86TyjbMnUYN+VkFw_coxURfw@mail.gmail.com>
 <CAJ_JamAN6ZH7jeT6pnC4omp=QAsqEXZqQy1V+WnDOBOjv=aHHQ@mail.gmail.com>
Message-ID: <CAJ4zFrYpzjoLGSHRui-_FUuUOvGXVtp5F+OdyW6_B4zEMpVKdg@mail.gmail.com>

I too have not attended any meetings previously, but would like to start
getting involved here.  The 1pm time would be the least convenient for me,
but not impossible for me to make work.

On Wed, Sep 9, 2015 at 9:18 AM, Curtis <serverascode at gmail.com> wrote:

> On Tue, Sep 8, 2015 at 5:42 AM, Joseph Bajin <josephbajin at gmail.com>
> wrote:
> > Hi Everyone,
> >
> > One of the items taken from the Operators Meet-up was that the time (10am
> > EST) was too early for the west coast people.   I've been looking at the
> > meeting calendar and have a few suggested times that I'd like to see if
> they
> > would work for others to get more participation.
> >
> > Odd every other Wednesday's - ( 9/9, 9/23, etc)
> >
> > Suggested times - (All these are in EST)
> >
> > - 1pm
> > - 2pm
> > - 3pm
>
> Hi,
>
> I haven't attended previously but would like to.
>
> Any of those times work for me.
>
> Also, not sure if most meetings do this or not, but I like how the
> os-ansible-deployment project has a list of regular users on their
> wiki and the person running the meeting can just paste that into IRC
> to remind ppl of the meeting [1].
>
> Thanks,
> Curtis.
>
> [1]: https://wiki.openstack.org/wiki/Meetings/openstack-ansible
>
> >
> > If Wednesday's do not work, please let me know as well, and I can find
> > additional times.  It seemed that Wednesdays worked for most when we
> first
> > stood up the group, but it could be moved.
> >
> > --Joe
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> --
> Twitter: @serverascode
> Blog: serverascode.com
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
David W.
Unix, because every barista in Seattle has an MCSE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150909/6bbba2a5/attachment.html>

From openstack at medberry.net  Wed Sep  9 16:36:17 2015
From: openstack at medberry.net (David Medberry)
Date: Wed, 9 Sep 2015 10:36:17 -0600
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
Message-ID: <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>

Your users should also have reasonable quotas set. If they can boot
thousands of instances, you may have a quota issue to address. (No problem
with the blueprint or need to set an overall limit though--just that you
should be able to address this without waiting for that to land.)

On Mon, Sep 7, 2015 at 8:48 AM, Jean-Daniel Bonnetot <
jean-daniel.bonnetot at ovh.net> wrote:

> Hi,
>
> I try to limit the max instances a user can create per minute.
>
> With rate limit, we can limit the number of call/min on POST */servers for
> example.
> But the user can still use the max_count paramteter in his API call to
> boot dozen of thousand of instances and make the scheduler crazy.
>
> I?m pretty sure that there is a possiblity to limit the max_count and so
> define a max instances/min.
> Do you know something to do it?
>
> --
> Jean-Daniel
> @pilgrimstack
>
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150909/5c7034f1/attachment.html>

From carol.l.barrett at intel.com  Wed Sep  9 16:53:10 2015
From: carol.l.barrett at intel.com (Barrett, Carol L)
Date: Wed, 9 Sep 2015 16:53:10 +0000
Subject: [Openstack-operators] [OpenStack][Operators] Follow-up on Mid-cycle
 discussion on RPC Compatibility
Message-ID: <2D352D0CD819F64F9715B1B89695400D5C8A961C@ORSMSX113.amr.corp.intel.com>

Ops - I'm looking for an example of the RPC compatibility issue that was discussed in Palo Alto. Can someone help me out?
Thanks
Carol

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150909/a9e7925f/attachment.html>

From josephbajin at gmail.com  Wed Sep  9 17:31:48 2015
From: josephbajin at gmail.com (Joseph Bajin)
Date: Wed, 9 Sep 2015 13:31:48 -0400
Subject: [Openstack-operators] [OpenStack][Operators] Follow-up on
 Mid-cycle discussion on RPC Compatibility
In-Reply-To: <2D352D0CD819F64F9715B1B89695400D5C8A961C@ORSMSX113.amr.corp.intel.com>
References: <2D352D0CD819F64F9715B1B89695400D5C8A961C@ORSMSX113.amr.corp.intel.com>
Message-ID: <CAGm6i3n3Y2rOFuv6qS06zCFYpOZ+HW8Qe5DEMYhBjeUoFHFQrg@mail.gmail.com>

We recently just upgraded to Juno from Icehouse.

We used the upgrade_levels feature to get Nova off the ground, but ran into
major issues around conductor being too slow to respond to messages and
would cause a lot of our instances to not create.  This would only happen
at a particular high amount of load.  A few vms being built were no
problem, but get into anything over say 15, then the conductor queue would
start showing a lot of unacknowledged messages and basically start causing
a lot of instance creation failures.

I'm happy to provide any other details that are needed.

--Joe


On Wed, Sep 9, 2015 at 12:53 PM, Barrett, Carol L <carol.l.barrett at intel.com
> wrote:

> Ops ? I?m looking for an example of the RPC compatibility issue that was
> discussed in Palo Alto. Can someone help me out?
> Thanks
> Carol
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150909/1eef696d/attachment.html>

From chris.friesen at windriver.com  Wed Sep  9 18:49:48 2015
From: chris.friesen at windriver.com (Chris Friesen)
Date: Wed, 9 Sep 2015 12:49:48 -0600
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
 <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>
Message-ID: <55F07F4C.4030305@windriver.com>

On 09/09/2015 10:36 AM, David Medberry wrote:
> Your users should also have reasonable quotas set. If they can boot thousands of
> instances, you may have a quota issue to address. (No problem with the blueprint
> or need to set an overall limit though--just that you should be able to address
> this without waiting for that to land.)

I'm pretty sure if I paid for a suitable Rackspace account they would let me 
boot up thousands of instances as long as I could pay for them...

Chris


From nik.komawar at gmail.com  Wed Sep  9 22:41:16 2015
From: nik.komawar at gmail.com (Nikhil Komawar)
Date: Wed, 9 Sep 2015 18:41:16 -0400
Subject: [Openstack-operators] Adding v1 LIKE support to python-glanceclient
	releases 1.x.x
Message-ID: <55F0B58C.80209@gmail.com>

Hi all,

We recently release python-glanceclient 1.0.0 and it has the default
shell version as v2. This may result into some scripts not detecting the
change by default and discomfort to an extent.

So, I am reaching out to this list with the hope of getting some
feedback on the requirements, pros and cons you all think exist for
adding some support for v1 like calls as hidden command to the default
python-glanceclient shell API that is v2 centric by default. This should
unbreak the scripts to an extent and give a warning to users to update
the scripts in a stipulated time period so that they use the v2 API.

Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
are not yet sure if we need to get it merged by tomorrow so that it can
be in stable/liberty by the end of the week. There has been one request
to get those in and the feedback we received from the developer
community was neutral.

In order to form an opinion on what's best for our users, we need some
feedback on this topic. Please send us your thoughts as soon as possible
and we will try to accommodate the same if permissible within the
technical limitations:

1. Whether you would like these commands added as hidden commands so
that shell API works like before (to extent possible).
2. You would like to use v2 shell API of the client by default and don't
care about this commit.
3. You don't care about the change. Your scripts are awesome and can
adjust to the upgrade of the client easily.
4. Anything else.

-- 

Thanks,
Nikhil



From jj at chef.io  Wed Sep  9 23:53:53 2015
From: jj at chef.io (JJ Asghar)
Date: Wed, 9 Sep 2015 18:53:53 -0500
Subject: [Openstack-operators] [openstack-dev][openstack-operators][chef]
 Pre-release of new kitchen-openstack driver,
 Windows and 1.4 test-kitchen support
Message-ID: <55F0C691.3010804@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Everyone!

I'd like to announce a pre-release[1] of 2.0.0.dev of the
kitchen-openstack[2] driver gem.  I've been able to test this with
Windows 2012R2 and all the flavors of Linux I have on my OpenStack
Cloud, but would love some more feedback.[3]

If you could give this pre-release a shot, and post any issues, negative
or positive; I'd like to get this pushed out to a real release late next
week. (Sept. 17 or 18)

If you don't know you can install the gem via: `gem install
kitchen-openstack --pre`

Please take note, with 1.4 TK, there is now a transport option for the
transport driver, so you'll most likely need to add a transport section
to your .kitchen.yml. I've made note of this here[3].

[1]: https://rubygems.org/gems/kitchen-openstack/versions/2.0.0.dev
[2]: https://github.com/test-kitchen/kitchen-openstack
[3]: https://github.com/test-kitchen/kitchen-openstack/issues
[4]: https://github.com/test-kitchen/kitchen-openstack#usage

- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV8MaQAAoJEDZbxzMH0+jTCYUP/iUEqNG3WOZ6VJjuZCBO+4Wt
5h2DSvg7Tc7gB+IIUyvz8G++ymatvGyY9zRNhxCJcpQuwndxrfYJuVFB+2KiJ8hS
oVfHcggVms0/DlmGUn8Lr/8GdCCawU2qwjkYg1STJorXCwH6phh6dIhWcPSjus8r
f2/JKStmawFqQ7MW/hI5qvJ2o46AvfHEbzyPChD9YYNMffdZzrUfKVNL9JcCpl4+
N9VU+Y2e2oo1yjKro68tM7JR0qE5gF5k0BgRXcxWkSzPVLB+ilD+mAqCwoaaRmkr
yuxAgWV7kwFWXQnK8O/OJEEX4/EQx6QqC7oR36DrPLGafxW9Jk9Jyj6eh12mt7G9
/uEAuKcket5F6CNLYikGH3Lm7ZhaFD75Of/9ourVWZy4aTl3zX7PaC7SwSb6Yx9B
Flt4O4hf4Nl7PgPzf3kyuWaR+39HmEpF4WwCNQ+NdA92IKebDcsR6SgdcwxxkiOl
5wXhSs8vr+fgEGBYp4ZoEHmGUMWghd/fcoH5yDVt+neM1FB9wJwQAjMUV0z3kCJ1
AEyzwyNHTtflsnL3613//zwWTjKE9U3cHhY7KaiBrL2jO+rDsfi1cAD34usYI1G0
T76D9IAkxZz4TycGWgVzSVTY1ESqJFIxE2BLGeCDHZq/8fQsa7ZlrKif02V/eO+o
jMSXjkVcXHATaMqFIMNe
=f+U2
-----END PGP SIGNATURE-----



From clayton at oneill.net  Thu Sep 10 01:46:46 2015
From: clayton at oneill.net (Clayton O'Neill)
Date: Wed, 9 Sep 2015 21:46:46 -0400
Subject: [Openstack-operators] Adding v1 LIKE support to
 python-glanceclient releases 1.x.x
In-Reply-To: <55F0B58C.80209@gmail.com>
References: <55F0B58C.80209@gmail.com>
Message-ID: <CADg-rOXwmSfVMWRzCLaWkO4v=Um-tkW834KBRz=uo3WZ1V=RAQ@mail.gmail.com>

I'd be glad to see the backwards compatibility parts go in.  I got bitten
by this earlier this week and ended up switching my scripts over to using
the python-openstackclient library to work around it.

On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar <nik.komawar at gmail.com>
wrote:

> Hi all,
>
> We recently release python-glanceclient 1.0.0 and it has the default
> shell version as v2. This may result into some scripts not detecting the
> change by default and discomfort to an extent.
>
> So, I am reaching out to this list with the hope of getting some
> feedback on the requirements, pros and cons you all think exist for
> adding some support for v1 like calls as hidden command to the default
> python-glanceclient shell API that is v2 centric by default. This should
> unbreak the scripts to an extent and give a warning to users to update
> the scripts in a stipulated time period so that they use the v2 API.
>
> Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
> are not yet sure if we need to get it merged by tomorrow so that it can
> be in stable/liberty by the end of the week. There has been one request
> to get those in and the feedback we received from the developer
> community was neutral.
>
> In order to form an opinion on what's best for our users, we need some
> feedback on this topic. Please send us your thoughts as soon as possible
> and we will try to accommodate the same if permissible within the
> technical limitations:
>
> 1. Whether you would like these commands added as hidden commands so
> that shell API works like before (to extent possible).
> 2. You would like to use v2 shell API of the client by default and don't
> care about this commit.
> 3. You don't care about the change. Your scripts are awesome and can
> adjust to the upgrade of the client easily.
> 4. Anything else.
>
> --
>
> Thanks,
> Nikhil
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150909/220bbee2/attachment.html>

From sorrison at gmail.com  Thu Sep 10 05:18:15 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Thu, 10 Sep 2015 15:18:15 +1000
Subject: [Openstack-operators] Adding v1 LIKE support to
	python-glanceclient releases 1.x.x
In-Reply-To: <55F0B58C.80209@gmail.com>
References: <55F0B58C.80209@gmail.com>
Message-ID: <48801E87-9070-4948-90AC-401299AE15DE@gmail.com>

I?d just like things like image-list to work under the new client :-)

https://bugs.launchpad.net/python-glanceclient/+bug/1492887


> On 10 Sep 2015, at 8:41 am, Nikhil Komawar <nik.komawar at gmail.com> wrote:
> 
> Hi all,
> 
> We recently release python-glanceclient 1.0.0 and it has the default
> shell version as v2. This may result into some scripts not detecting the
> change by default and discomfort to an extent.
> 
> So, I am reaching out to this list with the hope of getting some
> feedback on the requirements, pros and cons you all think exist for
> adding some support for v1 like calls as hidden command to the default
> python-glanceclient shell API that is v2 centric by default. This should
> unbreak the scripts to an extent and give a warning to users to update
> the scripts in a stipulated time period so that they use the v2 API.
> 
> Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
> are not yet sure if we need to get it merged by tomorrow so that it can
> be in stable/liberty by the end of the week. There has been one request
> to get those in and the feedback we received from the developer
> community was neutral.
> 
> In order to form an opinion on what's best for our users, we need some
> feedback on this topic. Please send us your thoughts as soon as possible
> and we will try to accommodate the same if permissible within the
> technical limitations:
> 
> 1. Whether you would like these commands added as hidden commands so
> that shell API works like before (to extent possible).
> 2. You would like to use v2 shell API of the client by default and don't
> care about this commit.
> 3. You don't care about the change. Your scripts are awesome and can
> adjust to the upgrade of the client easily.
> 4. Anything else.
> 
> -- 
> 
> Thanks,
> Nikhil
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From Neil.Jerram at metaswitch.com  Thu Sep 10 08:36:09 2015
From: Neil.Jerram at metaswitch.com (Neil Jerram)
Date: Thu, 10 Sep 2015 08:36:09 +0000
Subject: [Openstack-operators] Adding v1 LIKE support to
 python-glanceclient	releases 1.x.x
Message-ID: <20150910083606.31731798.4057.9025@metaswitch.com>

I think it should be a requirement for the client to provide back-compatibility; or else to use a standard deprecation pattern?, i.e. to emit a deprecation warning message, for a cycle or two, before removing support for something.?

(I was just caught out by the change from '--is-public=true' to '--visibility public', which - from an uninformed point of view - feels like an unnecessary irritation.)

Regards,?
? ? ? Neil?

?
? Original Message ?
From: Nikhil Komawar
Sent: Wednesday, 9 September 2015 23:42
To: openstack-operators at lists.openstack.org
Subject: [Openstack-operators] Adding v1 LIKE support to python-glanceclient	releases 1.x.x

Hi all,

We recently release python-glanceclient 1.0.0 and it has the default
shell version as v2. This may result into some scripts not detecting the
change by default and discomfort to an extent.

So, I am reaching out to this list with the hope of getting some
feedback on the requirements, pros and cons you all think exist for
adding some support for v1 like calls as hidden command to the default
python-glanceclient shell API that is v2 centric by default. This should
unbreak the scripts to an extent and give a warning to users to update
the scripts in a stipulated time period so that they use the v2 API.

Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
are not yet sure if we need to get it merged by tomorrow so that it can
be in stable/liberty by the end of the week. There has been one request
to get those in and the feedback we received from the developer
community was neutral.

In order to form an opinion on what's best for our users, we need some
feedback on this topic. Please send us your thoughts as soon as possible
and we will try to accommodate the same if permissible within the
technical limitations:

1. Whether you would like these commands added as hidden commands so
that shell API works like before (to extent possible).
2. You would like to use v2 shell API of the client by default and don't
care about this commit.
3. You don't care about the change. Your scripts are awesome and can
adjust to the upgrade of the client easily.
4. Anything else.

-- 

Thanks,
Nikhil


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

From jean-daniel.bonnetot at ovh.net  Thu Sep 10 08:38:34 2015
From: jean-daniel.bonnetot at ovh.net (Jean-Daniel Bonnetot)
Date: Thu, 10 Sep 2015 10:38:34 +0200
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
 <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>
Message-ID: <4DBA33DB-D5EB-428F-9F40-30BB9E040BDB@ovh.net>

The use case is a crossing of two
1. As user, I want to use X,000 instances, in order to accept the load increment during my activity (long period). So the boot rate for instances is low.
2. As operator, I need to be able to set high quota (thousands of instances to cover the first use case) AND prevent users to start too many of instances at a time. In other word, force my client to use a boot rate ? low ?.
--
Jean-Daniel
@pilgrimstack




> Le 9 sept. 2015 ? 18:36, David Medberry <openstack at medberry.net> a ?crit :
> 
> Your users should also have reasonable quotas set. If they can boot thousands of instances, you may have a quota issue to address. (No problem with the blueprint or need to set an overall limit though--just that you should be able to address this without waiting for that to land.)
> 
> On Mon, Sep 7, 2015 at 8:48 AM, Jean-Daniel Bonnetot <jean-daniel.bonnetot at ovh.net <mailto:jean-daniel.bonnetot at ovh.net>> wrote:
> Hi,
> 
> I try to limit the max instances a user can create per minute.
> 
> With rate limit, we can limit the number of call/min on POST */servers for example.
> But the user can still use the max_count paramteter in his API call to boot dozen of thousand of instances and make the scheduler crazy.
> 
> I?m pretty sure that there is a possiblity to limit the max_count and so define a max instances/min.
> Do you know something to do it?
> 
> --
> Jean-Daniel
> @pilgrimstack
> 
> 
> 
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150910/2f3f64f9/attachment.html>

From abhishek.talwar at tcs.com  Thu Sep 10 10:55:37 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Thu, 10 Sep 2015 16:25:37 +0530
Subject: [Openstack-operators] [openstack-operators] [kilo-devstack]
	[disk-usage]
Message-ID: <OFE521095F.7002CD28-ON65257EBC.003C060D-65257EBC.003C060F@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150910/cd0cbc7a/attachment.html>

From serverascode at gmail.com  Thu Sep 10 13:55:34 2015
From: serverascode at gmail.com (Curtis)
Date: Thu, 10 Sep 2015 07:55:34 -0600
Subject: [Openstack-operators] Adding v1 LIKE support to
 python-glanceclient releases 1.x.x
In-Reply-To: <20150910083606.31731798.4057.9025@metaswitch.com>
References: <20150910083606.31731798.4057.9025@metaswitch.com>
Message-ID: <CAJ_JamAVMbiqb6dOmN8oEi57+jpjXTHLFaSUY=Aa1V3KyrvVNw@mail.gmail.com>

On Thu, Sep 10, 2015 at 2:36 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
> I think it should be a requirement for the client to provide back-compatibility; or else to use a standard deprecation pattern?, i.e. to emit a deprecation warning message, for a cycle or two, before removing support for something.
>

Yes, +1 on that. Glance 1.0.0 returns an empty list for our public
cloud right now.

Thanks,
Curtis.

> (I was just caught out by the change from '--is-public=true' to '--visibility public', which - from an uninformed point of view - feels like an unnecessary irritation.)
>
> Regards,
>       Neil
>
> ?
>   Original Message
> From: Nikhil Komawar
> Sent: Wednesday, 9 September 2015 23:42
> To: openstack-operators at lists.openstack.org
> Subject: [Openstack-operators] Adding v1 LIKE support to python-glanceclient    releases 1.x.x
>
> Hi all,
>
> We recently release python-glanceclient 1.0.0 and it has the default
> shell version as v2. This may result into some scripts not detecting the
> change by default and discomfort to an extent.
>
> So, I am reaching out to this list with the hope of getting some
> feedback on the requirements, pros and cons you all think exist for
> adding some support for v1 like calls as hidden command to the default
> python-glanceclient shell API that is v2 centric by default. This should
> unbreak the scripts to an extent and give a warning to users to update
> the scripts in a stipulated time period so that they use the v2 API.
>
> Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
> are not yet sure if we need to get it merged by tomorrow so that it can
> be in stable/liberty by the end of the week. There has been one request
> to get those in and the feedback we received from the developer
> community was neutral.
>
> In order to form an opinion on what's best for our users, we need some
> feedback on this topic. Please send us your thoughts as soon as possible
> and we will try to accommodate the same if permissible within the
> technical limitations:
>
> 1. Whether you would like these commands added as hidden commands so
> that shell API works like before (to extent possible).
> 2. You would like to use v2 shell API of the client by default and don't
> care about this commit.
> 3. You don't care about the change. Your scripts are awesome and can
> adjust to the upgrade of the client easily.
> 4. Anything else.
>
> --
>
> Thanks,
> Nikhil
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Twitter: @serverascode
Blog: serverascode.com


From matt at mattfischer.com  Thu Sep 10 14:11:19 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Thu, 10 Sep 2015 08:11:19 -0600
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <4DBA33DB-D5EB-428F-9F40-30BB9E040BDB@ovh.net>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
 <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>
 <4DBA33DB-D5EB-428F-9F40-30BB9E040BDB@ovh.net>
Message-ID: <CAHr1CO_EzYmg8MDbvJz1TY5x055swAjN4RP=7m8oNksHjESYXw@mail.gmail.com>

While I think there is probably some value in rate limiting API calls, I
think your "user wants to launch x000 instances" is extremely limited.
There's maybe 1 or 2 (or 0) operators that have that amount of spare
capacity just sitting around that they can allow a user to have a quota of
2000 instances without doing an infrastructure build-out.

The real value in rate limiting, as long as it can be done without limiting
performance, is in handling users who are DoSing the APIs, intentionally or
not.

On Thu, Sep 10, 2015 at 2:38 AM, Jean-Daniel Bonnetot <
jean-daniel.bonnetot at ovh.net> wrote:

> The use case is a crossing of two
> 1. As user, I want to use X,000 instances, in order to accept the load
> increment during my activity (long period). So the boot rate for instances
> is low.
> 2. As operator, I need to be able to set high quota (thousands of
> instances to cover the first use case) AND prevent users to start too many
> of instances at a time. In other word, force my client to use a boot rate
> ? low ?.
> --
> Jean-Daniel
> @pilgrimstack
>
>
>
>
> Le 9 sept. 2015 ? 18:36, David Medberry <openstack at medberry.net> a ?crit :
>
> Your users should also have reasonable quotas set. If they can boot
> thousands of instances, you may have a quota issue to address. (No problem
> with the blueprint or need to set an overall limit though--just that you
> should be able to address this without waiting for that to land.)
>
> On Mon, Sep 7, 2015 at 8:48 AM, Jean-Daniel Bonnetot <
> jean-daniel.bonnetot at ovh.net> wrote:
>
>> Hi,
>>
>> I try to limit the max instances a user can create per minute.
>>
>> With rate limit, we can limit the number of call/min on POST */servers
>> for example.
>> But the user can still use the max_count paramteter in his API call to
>> boot dozen of thousand of instances and make the scheduler crazy.
>>
>> I?m pretty sure that there is a possiblity to limit the max_count and so
>> define a max instances/min.
>> Do you know something to do it?
>>
>> --
>> Jean-Daniel
>> @pilgrimstack
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150910/de89f077/attachment.html>

From applyhhj at 163.com  Thu Sep 10 14:31:29 2015
From: applyhhj at 163.com (applyhhj)
Date: Thu, 10 Sep 2015 22:31:29 +0800
Subject: [Openstack-operators] about network configuration
Message-ID: <3a8ba791.616e.14fb7ab28bc.Coremail.applyhhj@163.com>

Hi Everyone,
   I am new to openstack. When following the Install Guidance(kilo version) for Ubuntu, I was unable to correctly configure the network. I followed the Guidance and set up 1 controller node, 1 network node and 3 computing nodes. All configuration is almost the same as the Guidance. However, if I set the gateway of management interface in network node to 10.0.0.1 and change external interface to ?dhcp? mode, which is required by my external network environment, then I cannot ping other nodes from network nodes. So I comment the gateway configuration and everything works fine. But only network node can access to external network, other nodes are not able to ping outside website. It will throw ?unknown host? error. Can anyone help me with this problem please? Thank you very much!!


2015-09-10



applyhhj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150910/c50b2c2f/attachment.html>

From ignaziocassano at gmail.com  Thu Sep 10 15:49:33 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Thu, 10 Sep 2015 17:49:33 +0200
Subject: [Openstack-operators] openstack kilo hyperv networking
Message-ID: <CAB7j8cUx6117GH-mcLe61859fd+mAEJAafALQDRznRhe7YKqjw@mail.gmail.com>

Hi all,
I successfully installed openstack kilo with kvm and server 2012 hyperv
nodes.
Using  hyperv networking mechanism drivers I can connect hyperv virtual
switch with neutron in "vlan tenant mode" but I also would use gre .
Is it possible ?
I tried cloudbase openvswitch for hyper-v but it causes windows blue screen.
Any workaround using hyperv switch nvgre ?
Regards
Ignazio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150910/951942dc/attachment.html>

From paraskgeor at gmail.com  Thu Sep 10 16:35:14 2015
From: paraskgeor at gmail.com (George Paraskevas)
Date: Thu, 10 Sep 2015 16:35:14 +0000
Subject: [Openstack-operators] about network configuration
In-Reply-To: <3a8ba791.616e.14fb7ab28bc.Coremail.applyhhj@163.com>
References: <3a8ba791.616e.14fb7ab28bc.Coremail.applyhhj@163.com>
Message-ID: <CAMY8EK-g8OusQLuPWFWJY6ARmxFfZStbicb76ZGvE2gA6Cu1rg@mail.gmail.com>

Hello,

Why dhcp; configure it manual. Also what kind of network setup do you have;
does your network have a gateway on management subnet;

George.

On Thu, Sep 10, 2015, 17:31 applyhhj <applyhhj at 163.com> wrote:

> Hi Everyone,
>
>    I am new to openstack. When following the Install Guidance(kilo
> version) for Ubuntu, I was unable to correctly configure the network. I
> followed the Guidance and set up 1 controller node, 1 network node and 3
> computing nodes. All configuration is almost the same as the Guidance.
> However, if I set the gateway of management interface in network node to
> 10.0.0.1 and change external interface to ?dhcp? mode, which is required by
> my external network environment, then I cannot ping other nodes from
> network nodes. So I comment the gateway configuration and everything works
> fine. But only network node can access to external network, other nodes are
> not able to ping outside website. It will throw ?unknown host? error. Can
> anyone help me with this problem please? Thank you very much!!
>
>
> 2015-09-10
> ------------------------------
> applyhhj
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150910/183274f4/attachment.html>

From chris.friesen at windriver.com  Thu Sep 10 16:41:20 2015
From: chris.friesen at windriver.com (Chris Friesen)
Date: Thu, 10 Sep 2015 10:41:20 -0600
Subject: [Openstack-operators] Rate limit an max_count
In-Reply-To: <CAHr1CO_EzYmg8MDbvJz1TY5x055swAjN4RP=7m8oNksHjESYXw@mail.gmail.com>
References: <309045EC-58A0-4A04-9C6B-BB9F7D9225B9@ovh.net>
 <CAJhvMSubpWhpinEQT9mWrT0Xbeg8xk6MX9=wBPAkK4p2LFBe7A@mail.gmail.com>
 <4DBA33DB-D5EB-428F-9F40-30BB9E040BDB@ovh.net>
 <CAHr1CO_EzYmg8MDbvJz1TY5x055swAjN4RP=7m8oNksHjESYXw@mail.gmail.com>
Message-ID: <55F1B2B0.4010802@windriver.com>

On 09/10/2015 08:11 AM, Matt Fischer wrote:
> While I think there is probably some value in rate limiting API calls, I think
> your "user wants to launch x000 instances" is extremely limited. There's maybe 1
> or 2 (or 0) operators that have that amount of spare capacity just sitting
> around that they can allow a user to have a quota of 2000 instances without
> doing an infrastructure build-out.

At the default CPU overcommit of 16x, 2000 instances at say 2 cores/instance is 
only 250 physical cores.

Chris


From jay at openstack.org  Fri Sep 11 21:59:43 2015
From: jay at openstack.org (Jay Fankhauser)
Date: Fri, 11 Sep 2015 16:59:43 -0500
Subject: [Openstack-operators] =?utf-8?q?OpenStack_Community_Weekly_Newsle?=
 =?utf-8?b?dHRlciAoU2VwdC4sIDUg4oCTIDExKQ==?=
Message-ID: <C2681519-0262-49F8-87E1-F89FF3E3110F@openstack.org>

Why you should take TryStack for a spin now <http://superuser.openstack.org/articles/why-you-should-take-trystack-for-a-spin-now>
The free OpenStack testing sandbox is back -- and it's bigger, badder and better than ever.
Liberty cycle retrospective in Puppet OpenStack <http://my1.fr/blog/liberty-cycle-retrospective-in-puppet-openstack/>
Things are moving very fast in OpenStack; it might be useful to take a short break and write down a little bit of retrospective; it will help to see what happened in Puppet OpenStack project during the last months.

The Road to Tokyo 

Register now: full access registration prices increase on?9/30 <https://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598>
Discounted registration for?nonprofit/government/students deadline is?9/25? <https://openstack.formstack.com/forms/openstack_summit_tokyo_discounted_registration>
Get your OpenStack Summit Tokyo visa in five steps: Deadline for Visa invitation requests is?10/1 <http://superuser.openstack.org/articles/get-your-openstack-summit-tokyo-visa-in-five-steps>
The schedule for the OpenStack Summit in Tokyo is now available <https://www.openstack.org/summit/tokyo-2015/schedule/>
Reports from Previous Events 

None this week
Deadlines and Contributors Notifications 

[openstack-dev] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074171.html>
[openstack-announce] [Ironic] Introducing Ironic 4.1.0 <http://lists.openstack.org/pipermail/openstack-announce/2015-September/000616.html>
Security Advisories and Notices 

OSSA-2015-018: Neutron firewall rules bypass through port update <https://security.openstack.org/ossa/OSSA-2015-018.html>
Tips ?n Tricks 

By Ben Armstrong: Getting Hyper-V and OpenStack set up quickly <http://superuser.openstack.org/articles/getting-hyper-v-and-openstack-set-up-quickly>
By Boris Kuschel: How to monitor OpenStack deployments with Docker, Graphite, Grafana, collectd and Chef <http://superuser.openstack.org/articles/how-to-monitor-openstack-deployments-with-docker-graphite-grafana-collectd-and-chef>
By John Garbutt: [openstack-dev] [nova] [all] Updated String Freeze Guidelines <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073942.html>
By Gord Chung: [openstack-dev] [aodh][ceilometer] (re)introducing Aodh - OpenStack Alarming <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073897.html>
Upcoming Events <https://www.openstack.org/community/events> 

Sep 12, 2015?OpenStack Bangalore Meetup?Bangalore, Karnataka, IN <http://www.meetup.com/Indian-OpenStack-User-Group/events/224709593/>
Sep 14 - 15, 2015?Extensibility in OpenStack Swift and what you can do with it! (#25)?Washington D.C., DC, US <http://www.meetup.com/OpenStackDC/events/223978615/>
Sep 15, 2015?OpenStack Project Leader - visiting Belgium?Diegem, BE <http://www.meetup.com/OpenStack-Belgium-Meetup/events/224736832/>
Sep 16 - 17, 2015?OpenStack Austin - Sept. Meetup?Austin, TX, US <http://www.meetup.com/OpenStack-Austin/events/224238339/>
Sep 17, 2015?OpenStack Benelux Conference 2015?Bussum, NL <http://www.meetup.com/Openstack-Amsterdam/events/223038288/>
Sep 18, 2015?OpenStack PDX Meetup <http://www.meetup.com/openstack-pdx/events/224572482/>
 <http://www.meetup.com/openstack/events/223231183/>Sep 18, 2015?SFBay OpenStack Hackathon #OSSFO <http://www.meetup.com/openstack/events/223231183/> San Francisco, CA, US <http://www.meetup.com/openstack/events/223231183/>
Sep 21 - 24, 2015?Storage Developer Conference?Santa Clara, CA, US <http://www.snia.org/events/storage-developer>
Sep 29?? 30, 2015 Cloud Storage in OpenStack <https://groups.openstack.org/groups/frederick-md/cloud-storage-openstack>
Oct 01, 2015?OpenStack Meetup Cluj?Cluj-Napoc, Cluj, RO <http://www.meetup.com/OpenStackRomania/events/222910344/>
Oct 01, 2015?South Bay OpenStack Meetup, Beginner track San Francisco, CA, US <http://www.meetup.com/openstack/events/221806052/>
Oct 01 - 02, 2015?October OpenStack Meetup - SDN and Containers?Chicago, IL, US <http://www.meetup.com/meetup-group-NjZdcegA/events/225081881/>
Oct 04 - 08, 2015?Gartner SymposiumITxpo?Orlando, FL, US <http://www.gartner.com/events/na/orlando-symposium>
Oct 06, 2015?October Sydney Meetup <http://www.meetup.com/Australian-OpenStack-User-Group/events/220202327/> 
Oct 07, 2015?Houston OpenStack Meetup?Houston, TX, US <http://www.meetup.com/openstackhoustonmeetup/events/224870393/?eventId=224870393&action=detail>
Oct 07 ? 08, 2015?OpenStack Liberty Release?Richardson, TX, US <http://www.meetup.com/OpenStack-DFW/events/225014699/>
Oct 07 ? 08, 2015?OpenStack 101?Houston, TX, US <http://www.meetup.com/openstackhoustonmeetup/events/224870393/>
Oct 10, 2015?OpenStack India Meetup, Pune?Pune, IN <http://www.meetup.com/Indian-OpenStack-User-Group/events/225039190/>


Other News 

Managing OpenStack: Integration Matters!? <http://redhatstackblog.redhat.com/2015/09/08/managing-openstack-integration-matters/>
Why OpenStack needs to keep it simple <http://superuser.openstack.org/articles/why-openstack-needs-to-keep-it-simple>


The weekly newsletter is a way for the community to learn about all the various activities in the OpenStack world._______________________________________________
Community mailing list
Community at lists.openstack.org <mailto:Community at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/community <http://lists.openstack.org/cgi-bin/mailman/listinfo/community>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150911/1b38c3df/attachment.html>

From tom at openstack.org  Mon Sep 14 04:49:46 2015
From: tom at openstack.org (Tom Fifield)
Date: Mon, 14 Sep 2015 12:49:46 +0800
Subject: [Openstack-operators] [tags] Results of PAO Ops Meeting
Message-ID: <55F651EA.9070401@openstack.org>

Hi all,

A quick update from our tags team meeting in Palo Alto last month.

1) Containerizable - new tag

David Medberry suggested and then submitted a patch to start discussion 
around a tag for whether or not a service is containerizable  - which is 
hard-won knowledge that was deemed nice to have during the containers 
session of the meetup.

Read and comment on the review here: 
https://review.openstack.org/#/c/214801/


2) Scalable - not possible to tag

Using the large number of scaling problems with Ceilometer as an 
example, in addition to many other ideas, we did a deep dive into how a 
tag related to scalability would be implemented.

The end conclusion was that whether a service scales or not is extremely 
complex information and has an associated decision making process that 
means it isn't possible to condense into a tag or even a few tags. The 
only real way to do this is to provide information about example 
deployments (eg rax, cern)

3) "works in rally" - new tag suggestion

There was general interest in asking the Rally team to consider making a 
"works in rally" tag, since the rally tests were deemed 'good'.



There were a number of other suggestions, including some items to 
propose to the software projects for consideration. All that and more 
can be found at the etherpad: https://etherpad.openstack.org/p/PAO-ops-tags

Your comments are welcome, and as always, patches visible and submitted to:

https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z



Regards,


Tom


From academicgareth at gmail.com  Mon Sep 14 05:12:49 2015
From: academicgareth at gmail.com (Gareth)
Date: Mon, 14 Sep 2015 13:12:49 +0800
Subject: [Openstack-operators] [tags] Results of PAO Ops Meeting
In-Reply-To: <55F651EA.9070401@openstack.org>
References: <55F651EA.9070401@openstack.org>
Message-ID: <CAAhuP_811fy2+A=VogjbTz0VP7w5V+Sth0DzKccB+rQKhNWWCQ@mail.gmail.com>

BTW, does Boris reply the "works in rally" tag?

On Mon, Sep 14, 2015 at 12:49 PM, Tom Fifield <tom at openstack.org> wrote:
> Hi all,
>
> A quick update from our tags team meeting in Palo Alto last month.
>
> 1) Containerizable - new tag
>
> David Medberry suggested and then submitted a patch to start discussion
> around a tag for whether or not a service is containerizable  - which is
> hard-won knowledge that was deemed nice to have during the containers
> session of the meetup.
>
> Read and comment on the review here:
> https://review.openstack.org/#/c/214801/
>
>
> 2) Scalable - not possible to tag
>
> Using the large number of scaling problems with Ceilometer as an example, in
> addition to many other ideas, we did a deep dive into how a tag related to
> scalability would be implemented.
>
> The end conclusion was that whether a service scales or not is extremely
> complex information and has an associated decision making process that means
> it isn't possible to condense into a tag or even a few tags. The only real
> way to do this is to provide information about example deployments (eg rax,
> cern)
>
> 3) "works in rally" - new tag suggestion
>
> There was general interest in asking the Rally team to consider making a
> "works in rally" tag, since the rally tests were deemed 'good'.
>
>
>
> There were a number of other suggestions, including some items to propose to
> the software projects for consideration. All that and more can be found at
> the etherpad: https://etherpad.openstack.org/p/PAO-ops-tags
>
> Your comments are welcome, and as always, patches visible and submitted to:
>
> https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z
>
>
>
> Regards,
>
>
> Tom
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang at freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ?1 to an open organization you specify.


From tom at openstack.org  Mon Sep 14 06:26:04 2015
From: tom at openstack.org (Tom Fifield)
Date: Mon, 14 Sep 2015 14:26:04 +0800
Subject: [Openstack-operators] [tags] Results of PAO Ops Meeting
In-Reply-To: <CAAhuP_811fy2+A=VogjbTz0VP7w5V+Sth0DzKccB+rQKhNWWCQ@mail.gmail.com>
References: <55F651EA.9070401@openstack.org>
 <CAAhuP_811fy2+A=VogjbTz0VP7w5V+Sth0DzKccB+rQKhNWWCQ@mail.gmail.com>
Message-ID: <55F6687C.6030809@openstack.org>

On 14/09/15 13:12, Gareth wrote:
> BTW, does Boris reply the "works in rally" tag?

Noone's asked yet :) Anyone feel like asking the Rally team?


> On Mon, Sep 14, 2015 at 12:49 PM, Tom Fifield <tom at openstack.org> wrote:
>> Hi all,
>>
>> A quick update from our tags team meeting in Palo Alto last month.
>>
>> 1) Containerizable - new tag
>>
>> David Medberry suggested and then submitted a patch to start discussion
>> around a tag for whether or not a service is containerizable  - which is
>> hard-won knowledge that was deemed nice to have during the containers
>> session of the meetup.
>>
>> Read and comment on the review here:
>> https://review.openstack.org/#/c/214801/
>>
>>
>> 2) Scalable - not possible to tag
>>
>> Using the large number of scaling problems with Ceilometer as an example, in
>> addition to many other ideas, we did a deep dive into how a tag related to
>> scalability would be implemented.
>>
>> The end conclusion was that whether a service scales or not is extremely
>> complex information and has an associated decision making process that means
>> it isn't possible to condense into a tag or even a few tags. The only real
>> way to do this is to provide information about example deployments (eg rax,
>> cern)
>>
>> 3) "works in rally" - new tag suggestion
>>
>> There was general interest in asking the Rally team to consider making a
>> "works in rally" tag, since the rally tests were deemed 'good'.
>>
>>
>>
>> There were a number of other suggestions, including some items to propose to
>> the software projects for consideration. All that and more can be found at
>> the etherpad: https://etherpad.openstack.org/p/PAO-ops-tags
>>
>> Your comments are welcome, and as always, patches visible and submitted to:
>>
>> https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z
>>
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>



From academicgareth at gmail.com  Mon Sep 14 06:27:15 2015
From: academicgareth at gmail.com (Gareth)
Date: Mon, 14 Sep 2015 14:27:15 +0800
Subject: [Openstack-operators] [tags] Results of PAO Ops Meeting
In-Reply-To: <55F6687C.6030809@openstack.org>
References: <55F651EA.9070401@openstack.org>
 <CAAhuP_811fy2+A=VogjbTz0VP7w5V+Sth0DzKccB+rQKhNWWCQ@mail.gmail.com>
 <55F6687C.6030809@openstack.org>
Message-ID: <CAAhuP_8Jk0YhE7GQzTi0EyUsGvr4BsYYO2VXSfZieR2kqy1=CA@mail.gmail.com>

There's rally meeting tonight. I would like to ask him :) I guess
Boris like this very much

On Mon, Sep 14, 2015 at 2:26 PM, Tom Fifield <tom at openstack.org> wrote:
> On 14/09/15 13:12, Gareth wrote:
>>
>> BTW, does Boris reply the "works in rally" tag?
>
>
> Noone's asked yet :) Anyone feel like asking the Rally team?
>
>
>
>> On Mon, Sep 14, 2015 at 12:49 PM, Tom Fifield <tom at openstack.org> wrote:
>>>
>>> Hi all,
>>>
>>> A quick update from our tags team meeting in Palo Alto last month.
>>>
>>> 1) Containerizable - new tag
>>>
>>> David Medberry suggested and then submitted a patch to start discussion
>>> around a tag for whether or not a service is containerizable  - which is
>>> hard-won knowledge that was deemed nice to have during the containers
>>> session of the meetup.
>>>
>>> Read and comment on the review here:
>>> https://review.openstack.org/#/c/214801/
>>>
>>>
>>> 2) Scalable - not possible to tag
>>>
>>> Using the large number of scaling problems with Ceilometer as an example,
>>> in
>>> addition to many other ideas, we did a deep dive into how a tag related
>>> to
>>> scalability would be implemented.
>>>
>>> The end conclusion was that whether a service scales or not is extremely
>>> complex information and has an associated decision making process that
>>> means
>>> it isn't possible to condense into a tag or even a few tags. The only
>>> real
>>> way to do this is to provide information about example deployments (eg
>>> rax,
>>> cern)
>>>
>>> 3) "works in rally" - new tag suggestion
>>>
>>> There was general interest in asking the Rally team to consider making a
>>> "works in rally" tag, since the rally tests were deemed 'good'.
>>>
>>>
>>>
>>> There were a number of other suggestions, including some items to propose
>>> to
>>> the software projects for consideration. All that and more can be found
>>> at
>>> the etherpad: https://etherpad.openstack.org/p/PAO-ops-tags
>>>
>>> Your comments are welcome, and as always, patches visible and submitted
>>> to:
>>>
>>>
>>> https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>



-- 
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang at freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ?1 to an open organization you specify.


From thierry at openstack.org  Mon Sep 14 08:35:13 2015
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 14 Sep 2015 10:35:13 +0200
Subject: [Openstack-operators] [tags] Results of PAO Ops Meeting
In-Reply-To: <55F651EA.9070401@openstack.org>
References: <55F651EA.9070401@openstack.org>
Message-ID: <55F686C1.8030409@openstack.org>

Tom Fifield wrote:
> A quick update from our tags team meeting in Palo Alto last month.
> [...]
> 1) Containerizable - new tag 

Great idea, and having downstream assess that is certainly the best
approach.

> [...]
> 3) "works in rally" - new tag suggestion
> 
> There was general interest in asking the Rally team to consider making a
> "works in rally" tag, since the rally tests were deemed 'good'.

This one is part of a larger family of tags describing cross-project
support (like "has an horizon plugin", or "has heat teamplates") that we
started to work on on the upstream side as well. Those would be simple
yes/no binary tags, and maintained by the related project team directly.

Do you expect the "works in rally" answer to be more complex than a
binary yes/no ? Do you think the tag should be maintained by operators
rather than directly by the Rally project team ? If not, it's probably
fine to get that one defined as other upstream-maintained tags in the
same family.

Cheers,

-- 
Thierry Carrez (ttx)


From tom at openstack.org  Mon Sep 14 09:54:01 2015
From: tom at openstack.org (Tom Fifield)
Date: Mon, 14 Sep 2015 17:54:01 +0800
Subject: [Openstack-operators] [tags] Results of PAO Ops Meeting
In-Reply-To: <55F686C1.8030409@openstack.org>
References: <55F651EA.9070401@openstack.org> <55F686C1.8030409@openstack.org>
Message-ID: <55F69939.6050106@openstack.org>

On 14/09/15 16:35, Thierry Carrez wrote:
> Tom Fifield wrote:
>> 3) "works in rally" - new tag suggestion
>>
>> There was general interest in asking the Rally team to consider making a
>> "works in rally" tag, since the rally tests were deemed 'good'.
>
> This one is part of a larger family of tags describing cross-project
> support (like "has an horizon plugin", or "has heat teamplates") that we
> started to work on on the upstream side as well. Those would be simple
> yes/no binary tags, and maintained by the related project team directly.
>
> Do you expect the "works in rally" answer to be more complex than a
> binary yes/no ? Do you think the tag should be maintained by operators
> rather than directly by the Rally project team ? If not, it's probably
> fine to get that one defined as other upstream-maintained tags in the
> same family.

Up to the rally team :) The ops present were just interested in seeing 
it happen!



From flavio at redhat.com  Mon Sep 14 11:18:02 2015
From: flavio at redhat.com (Flavio Percoco)
Date: Mon, 14 Sep 2015 13:18:02 +0200
Subject: [Openstack-operators] Adding v1 LIKE support to
 python-glanceclient releases 1.x.x
In-Reply-To: <CADg-rOXwmSfVMWRzCLaWkO4v=Um-tkW834KBRz=uo3WZ1V=RAQ@mail.gmail.com>
References: <55F0B58C.80209@gmail.com>
 <CADg-rOXwmSfVMWRzCLaWkO4v=Um-tkW834KBRz=uo3WZ1V=RAQ@mail.gmail.com>
Message-ID: <20150914111802.GB10859@redhat.com>

On 09/09/15 21:46 -0400, Clayton O'Neill wrote:
>I'd be glad to see the backwards compatibility parts go in.? I got bitten by
>this earlier this week and ended up switching my scripts over to using the
>python-openstackclient library to work around it.


Hey Clayton,

Thanks for the feedback.

Could you be more precise on what incompatibility affected you?

The patch that Nikhil linked in his email brings in several
"compatibilities" with v1. I personally think they should be examined
1 by 1 rather than pulling them all in, hence my question.

Switching to python-openstack client must have required some effort
and I'm curious to know why you decided to do that rather than
adapting your scripts to use the v2 cli. Do you have Glance's v2
deployed?

Ideally, I think we should just move to use openstackclient, really.
But glanceclient is what we have now and that's what the Glance team
has focused on the most lately so I'd appreaciate as much feedback as
possible from you and others.

Thanks for your time,
Flavio

>
>On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar <nik.komawar at gmail.com> wrote:
>
>    Hi all,
>
>    We recently release python-glanceclient 1.0.0 and it has the default
>    shell version as v2. This may result into some scripts not detecting the
>    change by default and discomfort to an extent.
>
>    So, I am reaching out to this list with the hope of getting some
>    feedback on the requirements, pros and cons you all think exist for
>    adding some support for v1 like calls as hidden command to the default
>    python-glanceclient shell API that is v2 centric by default. This should
>    unbreak the scripts to an extent and give a warning to users to update
>    the scripts in a stipulated time period so that they use the v2 API.
>
>    Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
>    are not yet sure if we need to get it merged by tomorrow so that it can
>    be in stable/liberty by the end of the week. There has been one request
>    to get those in and the feedback we received from the developer
>    community was neutral.
>
>    In order to form an opinion on what's best for our users, we need some
>    feedback on this topic. Please send us your thoughts as soon as possible
>    and we will try to accommodate the same if permissible within the
>    technical limitations:
>
>    1. Whether you would like these commands added as hidden commands so
>    that shell API works like before (to extent possible).
>    2. You would like to use v2 shell API of the client by default and don't
>    care about this commit.
>    3. You don't care about the change. Your scripts are awesome and can
>    adjust to the upgrade of the client easily.
>    4. Anything else.
>   
>    --
>
>    Thanks,
>    Nikhil
>
>
>    _______________________________________________
>    OpenStack-operators mailing list
>    OpenStack-operators at lists.openstack.org
>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150914/8f6f8234/attachment.pgp>

From clayton at oneill.net  Mon Sep 14 11:49:28 2015
From: clayton at oneill.net (Clayton O'Neill)
Date: Mon, 14 Sep 2015 07:49:28 -0400
Subject: [Openstack-operators] Adding v1 LIKE support to
 python-glanceclient releases 1.x.x
In-Reply-To: <20150914111802.GB10859@redhat.com>
References: <55F0B58C.80209@gmail.com>
 <CADg-rOXwmSfVMWRzCLaWkO4v=Um-tkW834KBRz=uo3WZ1V=RAQ@mail.gmail.com>
 <20150914111802.GB10859@redhat.com>
Message-ID: <CADg-rOV=2PJR-vZuPVaP+aw9Z=PzYyA61Q8sh40eO5S1TUPxVQ@mail.gmail.com>

I ran into this issue on my laptop where I had just pip installed glance
client and gotten the latest version.  The script I was working on I want
to run in multiple environments, so it was easier to rely on the openstack
client which has the same CLI API (and generally easier to integrate with)
than to make it work with two versions of the glance client or to force a
specific version on systems I may not control.

I don't remember the exact behavior change that bit me, but since it was
trying to upload an image if it didn't already exist by name, I suspect
that it was the --is-public/--is-protected change.

I think one of the issues here is that a lot of our users also install from
pip, and from their standpoint this is an "unannounced" change.  Not
because it's literally unannounced, but because many of them probably don't
install specific versions of the clients even though we do recommend
specific versions.  From their standpoint I think they consider this
"unannounced" mostly because I doubt any of them follow any of the mailing
lists where it would have been announced.  I'm not sure what the right
answer here is, but it's definitely a difficult situation.

On Mon, Sep 14, 2015 at 7:18 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 09/09/15 21:46 -0400, Clayton O'Neill wrote:
>
>> I'd be glad to see the backwards compatibility parts go in.  I got bitten
>> by
>> this earlier this week and ended up switching my scripts over to using the
>> python-openstackclient library to work around it.
>>
>
>
> Hey Clayton,
>
> Thanks for the feedback.
>
> Could you be more precise on what incompatibility affected you?
>
> The patch that Nikhil linked in his email brings in several
> "compatibilities" with v1. I personally think they should be examined
> 1 by 1 rather than pulling them all in, hence my question.
>
> Switching to python-openstack client must have required some effort
> and I'm curious to know why you decided to do that rather than
> adapting your scripts to use the v2 cli. Do you have Glance's v2
> deployed?
>
> Ideally, I think we should just move to use openstackclient, really.
> But glanceclient is what we have now and that's what the Glance team
> has focused on the most lately so I'd appreaciate as much feedback as
> possible from you and others.
>
> Thanks for your time,
> Flavio
>
>
>
>> On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar <nik.komawar at gmail.com>
>> wrote:
>>
>>    Hi all,
>>
>>    We recently release python-glanceclient 1.0.0 and it has the default
>>    shell version as v2. This may result into some scripts not detecting
>> the
>>    change by default and discomfort to an extent.
>>
>>    So, I am reaching out to this list with the hope of getting some
>>    feedback on the requirements, pros and cons you all think exist for
>>    adding some support for v1 like calls as hidden command to the default
>>    python-glanceclient shell API that is v2 centric by default. This
>> should
>>    unbreak the scripts to an extent and give a warning to users to update
>>    the scripts in a stipulated time period so that they use the v2 API.
>>
>>    Here's the proposed patch https://review.openstack.org/#/c/219802/ .
>> We
>>    are not yet sure if we need to get it merged by tomorrow so that it can
>>    be in stable/liberty by the end of the week. There has been one request
>>    to get those in and the feedback we received from the developer
>>    community was neutral.
>>
>>    In order to form an opinion on what's best for our users, we need some
>>    feedback on this topic. Please send us your thoughts as soon as
>> possible
>>    and we will try to accommodate the same if permissible within the
>>    technical limitations:
>>
>>    1. Whether you would like these commands added as hidden commands so
>>    that shell API works like before (to extent possible).
>>    2. You would like to use v2 shell API of the client by default and
>> don't
>>    care about this commit.
>>    3. You don't care about the change. Your scripts are awesome and can
>>    adjust to the upgrade of the client easily.
>>    4. Anything else.
>>      --
>>
>>    Thanks,
>>    Nikhil
>>
>>
>>    _______________________________________________
>>    OpenStack-operators mailing list
>>    OpenStack-operators at lists.openstack.org
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150914/6228fa21/attachment.html>

From julien at danjou.info  Mon Sep 14 15:36:47 2015
From: julien at danjou.info (Julien Danjou)
Date: Mon, 14 Sep 2015 17:36:47 +0200
Subject: [Openstack-operators] [Gnocchi] Some update on Grafana support
Message-ID: <m0egi1gghc.fsf@danjou.info>

Hi folks,

I've just published a little blog post about the job we've been working
on with the rest of the Gnocchi team: adding support for Gnocchi? in
Grafana?. As Gordon pointed out, that might be of some interest for some
of you, so I'll leave that here:

  https://julien.danjou.info/blog/2015/openstack-gnocchi-grafana


Feel free to reach me if you have questions.


?  http://launchpad.net/gnocchi

?  http://grafana.org

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150914/b78c3ccc/attachment.pgp>

From jj at chef.io  Mon Sep 14 21:04:18 2015
From: jj at chef.io (JJ Asghar)
Date: Mon, 14 Sep 2015 16:04:18 -0500
Subject: [Openstack-operators] [openstack-operators] Announcement! We
 have everything ready to get to Stackforge!
In-Reply-To: <55E74C4B.2020901@chef.io>
References: <55E71EDF.5060203@chef.io> <55E7206D.9050609@chef.io>
 <55E74C4B.2020901@chef.io>
Message-ID: <55F73652.1040208@chef.io>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 9/2/15 2:21 PM, JJ Asghar wrote:
> 
> I've put the review[1] and it looks like it's pretty good.

I'd like to announce it has been merged!

> 
> I've created a launchpad[2] with both answers[3] and bugs[4] to help
> organize this code base.
> 
> I've also created an initial wiki[5] page too to start help
> bootstrapping this.
> 
> [1]: https://review.openstack.org/#/c/219760/
> [2]: http://launchpad.net/osops
> [3]: https://answers.launchpad.net/osops
> [4]: https://bugs.launchpad.net/osops
> [5]: https://wiki.openstack.org/wiki/Osops
> 

Now the real work starts. It seems the core reviewers havent been set up
yet, I'm taking this Action Item to get resolved asap. I've reached out
to a lot of yall, and thank you for agreeing to step up.

Any other relevant info I'll pass along, otherwise this is great news!

- -J
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV9zZSAAoJEDZbxzMH0+jTd90P/2L3AsqZbh/T8eHSb8rC+hLb
Fp+v/rNXWmtPGCdzoc1ala8eZfQxFviJGz9ksljlQICGbEZJRl5HNdbbyLZmsxEA
Kld+fPC/OdWKmtWXcHT3kAiHTbBwfsbucitqBN79Z0u/Fj0tKF0h7EoBDEH4kFAw
SsZNT7ZE5kJkXVvwZnV5MWa7kPiFCCF8eIQW2N4eal9Q6hzfOkgoP9vDhjJH9MX0
ei8eIwJuH2TZK8w3iRBsxolnnCdI5QzBp3rrUq4ESLUbPjSuEMGP2/lws1purKlk
ZlDlLwRalr0tCITVjCIvMWBkyOznoJtfBcingcr8aZJRCkoJhWVl/2cutIXWSiAT
++v790lUPtAyc652VCQURV0BB4hOyDkhAuxVN27/JNbP3+sFlFqlIrYtjf5rGgVc
7sK3mXtzsfMNmVDk344JTCb5VF/vtlvPuMDbVeIIA2fyhdITkb7cinoB/l6Kg0bM
SLnN7zjsciw5IaoEzjcS80lLfiRD3VmNBPj8wHok3YLKo/APVZjORSKP142Tci6Z
Lfp7ktuLXJc9pspVaIcFnHqvq2/zbZR6dBbb5qCs9HombU+W2FUb2qFHFOs2VXdF
yMWIoH1ZBjoBL8FCPktkqjMrdEA5uLt2UhGtqanBZqdGcj2ZYTpHNYU0l8ul9gvu
we+X3XiUqr4XjtfbtPgX
=eGuQ
-----END PGP SIGNATURE-----


From tom at openstack.org  Tue Sep 15 08:11:26 2015
From: tom at openstack.org (Tom Fifield)
Date: Tue, 15 Sep 2015 16:11:26 +0800
Subject: [Openstack-operators] [tags] ease of upgrade
Message-ID: <55F7D2AE.8060201@openstack.org>

Hi all,

One of our long mooted tags has been something that captures the ease of 
upgrade for a service.

We've got a lot of inherit knowledge about this stuff that would be 
great to capture, for example:

* Swift just eats upgrades up - whether you go for every point release, 
or do the N to N+1 jump, provided you read the release notes it's 
basically always a good time with Swift.
* Nova's upgrade_levels is pretty amazing, too. In recent versions you 
can run N+1 apis with a mix of N and N+1 compute nodes - quite convenient.
* Neutron in some configurations dumps all of the flows, you have to 
watch dhcp timeouts, how long services are offline etc, so a few little 
traps that keep it from being perfect.

If we could somehow make this into a tag, that'd be great. Anyone want 
to have a go?


Regards,



Tom


From flavio at redhat.com  Tue Sep 15 13:04:48 2015
From: flavio at redhat.com (Flavio Percoco)
Date: Tue, 15 Sep 2015 15:04:48 +0200
Subject: [Openstack-operators] Adding v1 LIKE support to
 python-glanceclient releases 1.x.x
In-Reply-To: <48801E87-9070-4948-90AC-401299AE15DE@gmail.com>
References: <55F0B58C.80209@gmail.com>
 <48801E87-9070-4948-90AC-401299AE15DE@gmail.com>
Message-ID: <20150915130448.GF9301@redhat.com>

On 10/09/15 15:18 +1000, Sam Morrison wrote:
>I?d just like things like image-list to work under the new client :-)
>
>https://bugs.launchpad.net/python-glanceclient/+bug/1492887

https://pypi.python.org/pypi/python-glanceclient/1.1.0

Flavio

>> On 10 Sep 2015, at 8:41 am, Nikhil Komawar <nik.komawar at gmail.com> wrote:
>>
>> Hi all,
>>
>> We recently release python-glanceclient 1.0.0 and it has the default
>> shell version as v2. This may result into some scripts not detecting the
>> change by default and discomfort to an extent.
>>
>> So, I am reaching out to this list with the hope of getting some
>> feedback on the requirements, pros and cons you all think exist for
>> adding some support for v1 like calls as hidden command to the default
>> python-glanceclient shell API that is v2 centric by default. This should
>> unbreak the scripts to an extent and give a warning to users to update
>> the scripts in a stipulated time period so that they use the v2 API.
>>
>> Here's the proposed patch https://review.openstack.org/#/c/219802/ . We
>> are not yet sure if we need to get it merged by tomorrow so that it can
>> be in stable/liberty by the end of the week. There has been one request
>> to get those in and the feedback we received from the developer
>> community was neutral.
>>
>> In order to form an opinion on what's best for our users, we need some
>> feedback on this topic. Please send us your thoughts as soon as possible
>> and we will try to accommodate the same if permissible within the
>> technical limitations:
>>
>> 1. Whether you would like these commands added as hidden commands so
>> that shell API works like before (to extent possible).
>> 2. You would like to use v2 shell API of the client by default and don't
>> care about this commit.
>> 3. You don't care about the change. Your scripts are awesome and can
>> adjust to the upgrade of the client easily.
>> 4. Anything else.
>>
>> --
>>
>> Thanks,
>> Nikhil
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150915/dab32869/attachment.pgp>

From mkassawara at gmail.com  Tue Sep 15 13:26:29 2015
From: mkassawara at gmail.com (Matt Kassawara)
Date: Tue, 15 Sep 2015 07:26:29 -0600
Subject: [Openstack-operators] [tags] ease of upgrade
In-Reply-To: <55F7D2AE.8060201@openstack.org>
References: <55F7D2AE.8060201@openstack.org>
Message-ID: <CABA+jQr_=pjhLnYU55AS98=U441u70a==8L_r4-dV97vZa9e_A@mail.gmail.com>

I think these sorts of general upgrade notes from the trenches should also
belong in the operations guide.

On Tue, Sep 15, 2015 at 2:11 AM, Tom Fifield <tom at openstack.org> wrote:

> Hi all,
>
> One of our long mooted tags has been something that captures the ease of
> upgrade for a service.
>
> We've got a lot of inherit knowledge about this stuff that would be great
> to capture, for example:
>
> * Swift just eats upgrades up - whether you go for every point release, or
> do the N to N+1 jump, provided you read the release notes it's basically
> always a good time with Swift.
> * Nova's upgrade_levels is pretty amazing, too. In recent versions you can
> run N+1 apis with a mix of N and N+1 compute nodes - quite convenient.
> * Neutron in some configurations dumps all of the flows, you have to watch
> dhcp timeouts, how long services are offline etc, so a few little traps
> that keep it from being perfect.
>
> If we could somehow make this into a tag, that'd be great. Anyone want to
> have a go?
>
>
> Regards,
>
>
>
> Tom
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150915/0113d0a5/attachment.html>

From openstack at medberry.net  Tue Sep 15 15:39:56 2015
From: openstack at medberry.net (David Medberry)
Date: Tue, 15 Sep 2015 09:39:56 -0600
Subject: [Openstack-operators] [tags] ease of upgrade
In-Reply-To: <55F7D2AE.8060201@openstack.org>
References: <55F7D2AE.8060201@openstack.org>
Message-ID: <CAJhvMStuosg0BShJEn-zP1N++6j76NZKJQmuCJxFGAzBz0Upqg@mail.gmail.com>

Sure, I can take a pass at this.

On Tue, Sep 15, 2015 at 2:11 AM, Tom Fifield <tom at openstack.org> wrote:

> Hi all,
>
> One of our long mooted tags has been something that captures the ease of
> upgrade for a service.
>
> We've got a lot of inherit knowledge about this stuff that would be great
> to capture, for example:
>
> * Swift just eats upgrades up - whether you go for every point release, or
> do the N to N+1 jump, provided you read the release notes it's basically
> always a good time with Swift.
> * Nova's upgrade_levels is pretty amazing, too. In recent versions you can
> run N+1 apis with a mix of N and N+1 compute nodes - quite convenient.
> * Neutron in some configurations dumps all of the flows, you have to watch
> dhcp timeouts, how long services are offline etc, so a few little traps
> that keep it from being perfect.
>
> If we could somehow make this into a tag, that'd be great. Anyone want to
> have a go?
>
>
> Regards,
>
>
>
> Tom
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150915/929387a6/attachment.html>

From carol.l.barrett at intel.com  Tue Sep 15 17:39:01 2015
From: carol.l.barrett at intel.com (Barrett, Carol L)
Date: Tue, 15 Sep 2015 17:39:01 +0000
Subject: [Openstack-operators] [tags] ease of upgrade
In-Reply-To: <CAJhvMStuosg0BShJEn-zP1N++6j76NZKJQmuCJxFGAzBz0Upqg@mail.gmail.com>
References: <55F7D2AE.8060201@openstack.org>
 <CAJhvMStuosg0BShJEn-zP1N++6j76NZKJQmuCJxFGAzBz0Upqg@mail.gmail.com>
Message-ID: <2D352D0CD819F64F9715B1B89695400D5C8B4947@ORSMSX113.amr.corp.intel.com>

Michal/Grzegorz/Will ? Can you pls work with Dave to make sure all of the Liberty improvements are included?

Dave: The Enterprise WG has been focused on rolling upgrades and developed tracker for our work from Kilo to Liberty to Mitaka. You can find the info here: https://docs.google.com/spreadsheets/d/1iT0XraW8ORGk2fb1bJMigE6wWdKK6YgrNB4ishPOc1M/edit#gid=1668081475. The Product WG has prioritized this user story and we are collaborating on continued implementation. We have weekly team meetings if you?d like to come in for a discussion on this tag, happy to add this to an agenda. The meetings are Tuesdays at 1500 UTC. You can find more info here: https://wiki.openstack.org/wiki/Enterprise_Working_Group, scroll down to the Deployment Team section.

Thanks
Carol


From: David Medberry [mailto:openstack at medberry.net]
Sent: Tuesday, September 15, 2015 8:40 AM
To: Tom Fifield
Cc: OpenStack Operators
Subject: Re: [Openstack-operators] [tags] ease of upgrade

Sure, I can take a pass at this.

On Tue, Sep 15, 2015 at 2:11 AM, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:
Hi all,

One of our long mooted tags has been something that captures the ease of upgrade for a service.

We've got a lot of inherit knowledge about this stuff that would be great to capture, for example:

* Swift just eats upgrades up - whether you go for every point release, or do the N to N+1 jump, provided you read the release notes it's basically always a good time with Swift.
* Nova's upgrade_levels is pretty amazing, too. In recent versions you can run N+1 apis with a mix of N and N+1 compute nodes - quite convenient.
* Neutron in some configurations dumps all of the flows, you have to watch dhcp timeouts, how long services are offline etc, so a few little traps that keep it from being perfect.

If we could somehow make this into a tag, that'd be great. Anyone want to have a go?


Regards,



Tom

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150915/d744b52d/attachment.html>

From dazzachan at yahoo.com.au  Wed Sep 16 03:21:54 2015
From: dazzachan at yahoo.com.au (darren chan)
Date: Wed, 16 Sep 2015 03:21:54 +0000 (UTC)
Subject: [Openstack-operators] [ops-guide] Ops/Arch Guide specialty team
	meeting time
Message-ID: <148878072.142409.1442373714799.JavaMail.yahoo@mail.yahoo.com>

Hi everyone,
Currently our weekly meeting is held on Thursday 1500 UTC, with fairly poor attendance. Here are some options to cater for different timezones:

1. Every Thursday 2130 UTC (to suit US and APAC timezones)2.?Every Thursday at alternating times to cater for timezones - US: Thursday 1400 UTC, APAC: Thursday 2330 UTC3. Option 1 biweekly
Let me know your preference. I'm open to other suggestions.
If you are interested in joining the team, sign up here?https://wiki.openstack.org/wiki/Documentation/OpsGuide#Team_Members. Things will begin to ramp with the Architecture Design Guide specs approved for Mitaka, and Ops Guide conversion and reorganisation specs in the works. ?Hopefully, there will an opportunity to discuss these changes at the Tokyo summit.

Thanks!
Darren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/f713562e/attachment.html>

From tom at openstack.org  Wed Sep 16 03:40:30 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 16 Sep 2015 11:40:30 +0800
Subject: [Openstack-operators] User Survey - Deadline Sept 25th
Message-ID: <55F8E4AE.7060607@openstack.org>

Hi all,

If you run OpenStack, build apps on it, or have customers with OpenStack 
deployments, please take a few minutes to respond to the latest User 
Survey or pass it along to your friends.

Since 2013, the user survey has provided significant insight into what 
people are deploying and how they're using OpenStack. You can see the 
most recent results in these SuperUser Articles: [1][2][3].

Please follow the link and instructions below to complete the User 
Survey by ***April 8, 2015 at 23:00 UTC***. If you already completed the 
survey, there's no need to start over. You can simply log back in to 
update your Deployment Profile, as well as take the opportunity to 
provide additional input. You need to do this to keep your past survey 
responses active, but we hope you'll do it because we've made the survey 
shorter and with more interesting questions ;)



Take the Survey ( http://www.openstack.org/user-survey )


All of the information you provide is confidential to the Foundation and 
User Committee and will be aggregated anonymously unless you clearly 
indicate we can publish your organization?s profile.

Remember you can hear directly from users and see the aggregate survey 
findings by attending the next OpenStack Summit, October 27-30 in Tokyo 
(http://www.openstack.org/summit).

Thank you again for your support.


-Tom


[1] 
http://superuser.openstack.org/articles/user-survey-identifies-leading-industries-and-business-drivers-for-openstack-adoption
[2] 
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
[3] 
http://superuser.openstack.org/articles/openstack-application-developers-share-insights


From tom at openstack.org  Wed Sep 16 03:45:39 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 16 Sep 2015 11:45:39 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Agenda Brainstorming
In-Reply-To: <55EEA610.30802@openstack.org>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
Message-ID: <55F8E5E3.1030502@openstack.org>

Last chance to provide your ideas for our design summit track.

So far we are lacking:
* Lightning talks
* Working Groups
* General Sessions

Starting next week we're going to prepare the draft agenda for 
circulation and discussion. So, get in now. What would you like to 
discuss with fellow ops and developers?


https://etherpad.openstack.org/p/TYO-ops-meetup


Regards,


Tom

On 08/09/15 17:10, Tom Fifield wrote:
> Ping!
>
> This is your chance to provide input on our design summit track for
> Tokyo. Add your ideas on the etherpad below!
>
>
> https://etherpad.openstack.org/p/TYO-ops-meetup
>
>
> On 03/09/15 03:27, Tom Fifield wrote:
>> Hi all,
>>
>> Thanks for those who made it to the recent meetup in Palo Alto. It was a
>> fantastic couple of days, and many are excited to get started on talking
>> about our ops track in the Tokyo design summit.
>>
>>
>> Recall that this is in addition to the operations and other conference
>> track's presentations. It's aimed at giving us a design-summit-style
>> place to congregate, swap best practices, ideas and give feedback.
>>
>>
>> As usual, we're working to act on the feedback from all past events to
>> make this one better than ever. One that we continue to work on is the
>> need to see action happen as a result of this event, so please - when
>> you are suggesting sessions in the below etherpad please try and phrase
>> them in a way that will probably result in things happening afterward.
>>
>>
>> **********************************************************************
>>
>> Please propose session ideas on:
>>
>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>> ensuring each session suggestion will have a result.
>>
>> **********************************************************************
>>
>>
>> The room allocations are still being worked out, but the current
>> thinking is that we will interleave general sessions and working groups
>> across Tuesday and Wednesday, to allow for attendance from ops in the
>> cross-project sessions.
>>
>>
>> More as it comes, and as always, further information about ops meetups
>> and notes from the past can be found on the wiki @:
>>
>> https://wiki.openstack.org/wiki/Operations/Meetups
>>
>> Finally, don't forget to register ASAP!
>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From tom at openstack.org  Wed Sep 16 03:52:51 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 16 Sep 2015 11:52:51 +0800
Subject: [Openstack-operators] User Survey - Deadline Sept 25th
In-Reply-To: <55F8E4AE.7060607@openstack.org>
References: <55F8E4AE.7060607@openstack.org>
Message-ID: <55F8E793.1080204@openstack.org>

Copy and Paste Error Strikes Again!

The deadline is (as the subject says):  ***September 25 at 23:59 UTC***. 
That is next Friday - get on it :)

http://www.openstack.org/user-survey


Regards,

Tom

On 16/09/15 11:40, Tom Fifield wrote:
> Hi all,
>
> If you run OpenStack, build apps on it, or have customers with OpenStack
> deployments, please take a few minutes to respond to the latest User
> Survey or pass it along to your friends.
>
> Since 2013, the user survey has provided significant insight into what
> people are deploying and how they're using OpenStack. You can see the
> most recent results in these SuperUser Articles: [1][2][3].
>
> Please follow the link and instructions below to complete the User
> Survey by ***Sep 25, 2015 at 23:00 UTC***. If you already completed the
> survey, there's no need to start over. You can simply log back in to
> update your Deployment Profile, as well as take the opportunity to
> provide additional input. You need to do this to keep your past survey
> responses active, but we hope you'll do it because we've made the survey
> shorter and with more interesting questions ;)
>
>
>
> Take the Survey ( http://www.openstack.org/user-survey )
>
>
> All of the information you provide is confidential to the Foundation and
> User Committee and will be aggregated anonymously unless you clearly
> indicate we can publish your organization?s profile.
>
> Remember you can hear directly from users and see the aggregate survey
> findings by attending the next OpenStack Summit, October 27-30 in Tokyo
> (http://www.openstack.org/summit).
>
> Thank you again for your support.
>
>
> -Tom
>
>
> [1]
> http://superuser.openstack.org/articles/user-survey-identifies-leading-industries-and-business-drivers-for-openstack-adoption
>
> [2]
> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
>
> [3]
> http://superuser.openstack.org/articles/openstack-application-developers-share-insights
>



From shilla.saebi at gmail.com  Wed Sep 16 04:32:46 2015
From: shilla.saebi at gmail.com (Shilla Saebi)
Date: Wed, 16 Sep 2015 00:32:46 -0400
Subject: [Openstack-operators] [ops-guide] Ops/Arch Guide specialty team
	meeting time
In-Reply-To: <148878072.142409.1442373714799.JavaMail.yahoo@mail.yahoo.com>
References: <148878072.142409.1442373714799.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAPrU3jFz0DaHMAVdOLoH0gAzsyCF5jFEo8zDGL3UJpL_kwaONw@mail.gmail.com>

Darren,

Thanks for putting this together. I vote for Option 1 and 3.

On Tue, Sep 15, 2015 at 11:21 PM, darren chan <dazzachan at yahoo.com.au>
wrote:

> Hi everyone,
>
> Currently our weekly meeting is held on Thursday 1500 UTC, with fairly
> poor attendance. Here are some options to cater for different timezones:
>
> 1. Every Thursday 2130 UTC (to suit US and APAC timezones)
> 2. Every Thursday at alternating times to cater for timezones - US:
> Thursday 1400 UTC, APAC: Thursday 2330 UTC
> 3. Option 1 biweekly
>
> Let me know your preference. I'm open to other suggestions.
>
> If you are interested in joining the team, sign up here
> https://wiki.openstack.org/wiki/Documentation/OpsGuide#Team_Members.
> Things will begin to ramp with the Architecture Design Guide specs approved
> for Mitaka, and Ops Guide conversion and reorganisation specs in the
> works.  Hopefully, there will an opportunity to discuss these changes at
> the Tokyo summit.
>
> Thanks!
>
> Darren
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/13ac9748/attachment.html>

From abhishek.talwar at tcs.com  Wed Sep 16 10:24:13 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Wed, 16 Sep 2015 15:54:13 +0530
Subject: [Openstack-operators] [openstack-operators] how to get current
	resource usage of an instance
Message-ID: <OFA6687889.C76F7AC6-ON65257EC2.0039261D-65257EC2.0039261F@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/64ca56c6/attachment.html>

From mriedem at linux.vnet.ibm.com  Wed Sep 16 13:14:07 2015
From: mriedem at linux.vnet.ibm.com (Matt Riedemann)
Date: Wed, 16 Sep 2015 08:14:07 -0500
Subject: [Openstack-operators] [openstack-operators] how to get current
 resource usage of an instance
In-Reply-To: <OFA6687889.C76F7AC6-ON65257EC2.0039261D-65257EC2.0039261F@tcs.com>
References: <OFA6687889.C76F7AC6-ON65257EC2.0039261D-65257EC2.0039261F@tcs.com>
Message-ID: <55F96B1F.7070004@linux.vnet.ibm.com>



On 9/16/2015 5:24 AM, Abhishek Talwar wrote:
> Hi Folks,
>
>
>
> I have an OpenStack kilo setup and I am trying to get the memory usage
> of the instances created in it.
>
> I researched and found that ceilometer has a meter called "memory.usage"
> that can give us the memory utilization of an instance. However, on
> doing ceilometer meter-list it does not list "memory.usage" as a meter.
> After searching I found that this problem is being faced by many
> contributors and a possible solution is changing nova configurations
> that does not help.
>
> So can you help me with some other possible solution that can help me in
> finding an instance's current memory utilization. I am working with
> something that would require getting the memory and disk utilization.
>
> Please provide a solution for this.
>
> Thanks and Regards
>
> Abhishek Talwar
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

The server diagnostics API in nova would also provide memory usage:

/v2/?{tenant_id}?/servers/?{server_id}?/diagnostics

In stable/kilo the code for that is here:

https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/server_diagnostics.py

Note that in the v2 API the diagnostics returned from the API is 
different depending on the backing hypervisor.

In the v2.1 API there is a uniform diagnostics dict returned which is 
virt-driver agnostic.  In v2.1 you get a serialized form of this 
Diagnostics object:

https://github.com/openstack/nova/blob/stable/kilo/nova/virt/diagnostics.py#L93

-- 

Thanks,

Matt Riedemann



From jj at chef.io  Wed Sep 16 17:56:07 2015
From: jj at chef.io (JJ Asghar)
Date: Wed, 16 Sep 2015 10:56:07 -0700
Subject: [Openstack-operators] [openstack-operators][osops] It's alive!
Message-ID: <55F9AD37.1030009@chef.io>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

All,

Great news! Our OSOps project is alive and well in the openstack
namespace!

The start of the repos[1], our launchpad[2], answers[3], bugs[4], and
wiki[5].

Please take a moment and let's get our project going!

There are a few IRC meetings times, I'd love to have a conversation
about we can congregate the different times to streamline workflows.

Any thoughts or suggestions on these meetings?

[1]: http://git.openstack.org/cgit/?q=osops
[2]: http://launchpad.net/osops
[3]: https://answers.launchpad.net/osops
[4]: https://bugs.launchpad.net/osops
[5]: https://wiki.openstack.org/wiki/Osops


- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+a03AAoJEDZbxzMH0+jTde0P/0CXmdzNv029R967LoEaOASQ
qe4lkr85QBezKNlnvfsZz/d4q8upWcbUwF2fXsGcDFVECXWGZDa2mpXu/UxKnwtA
YHUO0cPo/aqh9bvxhzj+Bv1ouRgiOSpaj7zHmc9DujuZOfoOIniRKyqaSpI1xjHe
rzSuv7Z9bTgJH7cShHx+dUu10Vdzqay866BBrIl5BviH5/Nz0itO3azYd2TWfoVD
GKrA8UW35i3+4NFo6j6NZtawt8ByXUIwgSruJ4QYrIZbBNgzAhTAKotH7xyJ7oqo
WLv6J33cO+NFzcGkaVISjo7u+L3HlJGINrpvqEmNFqon6unUTVxJdg+G6EK3S3DP
+Bwl03bNtwFAZh20yGcEDu+W9pHlXaihaoL1MsKX7x38uSFSrKMfplp0GMhtLbWO
woIs/cRsc+loHm3y42Ycj/1+xvfceZU3606qdZ8IvtDF4N0zmVNLqeO9LzTntiB7
U23krYD2PqWGWD1VdfePUiWVdlgvyhMoXNAS8+/8BdIC2KqtBXKYRe9Zvmn9F+4/
ied3oiqFs3QokFO2vLgvithrFJ/rOzm4MRI2XALmeIPN/8sh9cxBvk5RjtrQVDEj
ZQ3QK32cirxNG4lJmsKLMyGL5MQHsOKlsi/M+SJ/7EQ7XanqmbTGa5Uw6s1g5mO+
pRmjnYle0YJWyIqsR6SD
=tPGS
-----END PGP SIGNATURE-----


From jbajin at verisign.com  Wed Sep 16 18:13:07 2015
From: jbajin at verisign.com (Bajin, Joseph)
Date: Wed, 16 Sep 2015 18:13:07 +0000
Subject: [Openstack-operators] [openstack-operators][osops] It's alive!
In-Reply-To: <55F9AD37.1030009@chef.io>
References: <55F9AD37.1030009@chef.io>
Message-ID: <E9B2DF6D-0038-4C50-8839-48AD91BCE044@verisign.com>

Thank JJ for getting this setup. 

Last week, I sent an email to the group about changing around the times for the Ops Tools and Monitoring Working group.  I got two responses based on it saying that basically 2pm or so is the best times that works on Wednesdays.   I was planning on getting that pushed and setup.  I know the first few meetings and all the Operator Meet-Up notes during these sessions all mentioned the repo and utilizing it, so if you would like to use that time I think that is fine by me. 

?Joe










On 9/16/15, 1:56 PM, "JJ Asghar" <jj at chef.io> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>All,
>
>Great news! Our OSOps project is alive and well in the openstack
>namespace!
>
>The start of the repos[1], our launchpad[2], answers[3], bugs[4], and
>wiki[5].
>
>Please take a moment and let's get our project going!
>
>There are a few IRC meetings times, I'd love to have a conversation
>about we can congregate the different times to streamline workflows.
>
>Any thoughts or suggestions on these meetings?
>
>[1]: http://git.openstack.org/cgit/?q=osops
>[2]: http://launchpad.net/osops
>[3]: https://answers.launchpad.net/osops
>[4]: https://bugs.launchpad.net/osops
>[5]: https://wiki.openstack.org/wiki/Osops
>
>
>- -- 
>Best Regards,
>JJ Asghar
>c: 512.619.0722 t: @jjasghar irc: j^2
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2
>Comment: GPGTools - https://gpgtools.org
>
>iQIcBAEBCgAGBQJV+a03AAoJEDZbxzMH0+jTde0P/0CXmdzNv029R967LoEaOASQ
>qe4lkr85QBezKNlnvfsZz/d4q8upWcbUwF2fXsGcDFVECXWGZDa2mpXu/UxKnwtA
>YHUO0cPo/aqh9bvxhzj+Bv1ouRgiOSpaj7zHmc9DujuZOfoOIniRKyqaSpI1xjHe
>rzSuv7Z9bTgJH7cShHx+dUu10Vdzqay866BBrIl5BviH5/Nz0itO3azYd2TWfoVD
>GKrA8UW35i3+4NFo6j6NZtawt8ByXUIwgSruJ4QYrIZbBNgzAhTAKotH7xyJ7oqo
>WLv6J33cO+NFzcGkaVISjo7u+L3HlJGINrpvqEmNFqon6unUTVxJdg+G6EK3S3DP
>+Bwl03bNtwFAZh20yGcEDu+W9pHlXaihaoL1MsKX7x38uSFSrKMfplp0GMhtLbWO
>woIs/cRsc+loHm3y42Ycj/1+xvfceZU3606qdZ8IvtDF4N0zmVNLqeO9LzTntiB7
>U23krYD2PqWGWD1VdfePUiWVdlgvyhMoXNAS8+/8BdIC2KqtBXKYRe9Zvmn9F+4/
>ied3oiqFs3QokFO2vLgvithrFJ/rOzm4MRI2XALmeIPN/8sh9cxBvk5RjtrQVDEj
>ZQ3QK32cirxNG4lJmsKLMyGL5MQHsOKlsi/M+SJ/7EQ7XanqmbTGa5Uw6s1g5mO+
>pRmjnYle0YJWyIqsR6SD
>=tPGS
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From ignaziocassano at gmail.com  Wed Sep 16 18:18:41 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Wed, 16 Sep 2015 20:18:41 +0200
Subject: [Openstack-operators] best openstack distro for vmware
In-Reply-To: <CAB7j8cXzt99w7ADXrFkq8xwSTg-1GWTCaGdASNDKLspXVjwBvw@mail.gmail.com>
References: <CAB7j8cXzt99w7ADXrFkq8xwSTg-1GWTCaGdASNDKLspXVjwBvw@mail.gmail.com>
Message-ID: <CAB7j8cUxq8Qk0mP+ub0kCf708AdYSLxzDw5FMx_NULomqLESuQ@mail.gmail.com>

Hi all,
I am looking for an openstack distro with a good integration with vmware
esxi.
I know the best result is using kvm but we have a lot of vm on vmware.
I read about vio, platform9  and red hat but I need  to retrive some
comparison document and openstack roadmap on vmware.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/feab4c55/attachment.html>

From jj at chef.io  Wed Sep 16 18:19:27 2015
From: jj at chef.io (JJ Asghar)
Date: Wed, 16 Sep 2015 11:19:27 -0700
Subject: [Openstack-operators] [openstack-operators][osops] It's alive!
In-Reply-To: <E9B2DF6D-0038-4C50-8839-48AD91BCE044@verisign.com>
References: <55F9AD37.1030009@chef.io>
 <E9B2DF6D-0038-4C50-8839-48AD91BCE044@verisign.com>
Message-ID: <55F9B2AF.8020308@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Awesome. This is great.

I could try to find it, but can you link me to the agenda? There's a
couple things I'd like to ask and look for some consensus so we can
continue moving the framework forward.


Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2

On 9/16/15 11:13 AM, Bajin, Joseph wrote:
> Thank JJ for getting this setup.
>
> Last week, I sent an email to the group about changing around the
times for the Ops Tools and Monitoring Working group.  I got two
responses based on it saying that basically 2pm or so is the best times
that works on Wednesdays.   I was planning on getting that pushed and
setup.  I know the first few meetings and all the Operator Meet-Up notes
during these sessions all mentioned the repo and utilizing it, so if you
would like to use that time I think that is fine by me.
>
> ?Joe
>
>
>
>
>
>
>
>
>
>
> On 9/16/15, 1:56 PM, "JJ Asghar" <jj at chef.io> wrote:
>
> All,
>
> Great news! Our OSOps project is alive and well in the openstack
> namespace!
>
> The start of the repos[1], our launchpad[2], answers[3], bugs[4], and
> wiki[5].
>
> Please take a moment and let's get our project going!
>
> There are a few IRC meetings times, I'd love to have a conversation
> about we can congregate the different times to streamline workflows.
>
> Any thoughts or suggestions on these meetings?
>
> [1]: http://git.openstack.org/cgit/?q=osops
> [2]: http://launchpad.net/osops
> [3]: https://answers.launchpad.net/osops
> [4]: https://bugs.launchpad.net/osops
> [5]: https://wiki.openstack.org/wiki/Osops
>
>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+bKvAAoJEDZbxzMH0+jTGOcQAKk09+Nakm89r7xlzyeeQqjx
Hi2sK+/DANhUCF2cXakgB14Fo0QOlVoewBez2IjtRbwZIq3TlJHPITD/bCG5vMe4
EdP5tuBj4B4RITOgN7Sgl8vE7+hFNKaizSra30GLuVcX2YrJrtd+Wz7SWvOYiioh
f7hd4PJE6Xxe+MoCk5jpAtl0SZ7XzCtkvvd2GYCUa4lx6cec9ur7KeuztPyLA2Ye
ko0hPwjefS7NUziPqLuLEuUdvp4rsYHyDCUI2Zq/1q3Gm6oAjdPLgaCN/U5gTT+M
bDOhfMxa8PpEimsEDRNBHBKpVMrWYp01izqsTqlWoZ3ScM7+mrTT8vrMEvNY3RMh
bBmbAxsYOQr7Zq0EptgN+vxqaD00pcvqqUUKKKN2jcRnlJI1k8/SIq62N+PVRI6C
Gt94opAr6miD8kCYTKX6VFUPDSm2+uDFw7BnEekAGdM45sj2SBRl83MAYBpNbnMb
jNBeqAB65U3q0vt1FGAE7XeEx+hfJiMEoTKXVYP8okA6tznaaWnZ3BJVBT4ACRD9
kxDlEJRrp6IRE1kuhFp+XXtDJ9ohOlQgFQ6qSCsns0fHro9WzKrTad70yFZgjQE9
/rguqgPtS+5agonHnbAXLAlIJJZbkhxVKihGydB2hEAclafdWmwYAykEOObw0BAh
UhF7DiLrrxA4aBvKG6Sl
=xMj8
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/f4da3322/attachment.html>

From edgar.magana at workday.com  Wed Sep 16 18:40:10 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Wed, 16 Sep 2015 18:40:10 +0000
Subject: [Openstack-operators] [openstack-operators][osops] It's alive!
In-Reply-To: <55F9AD37.1030009@chef.io>
References: <55F9AD37.1030009@chef.io>
Message-ID: <127FC61A-D111-4260-862B-A873DA00F7D5@workday.com>

Congratulations!!! This is a great achievement.
I just fixed the link to github/openstack instead of stackforge ones.

We should add into the Wiki details about the IRC meetings.

So excited about committing code!

Cheers,

Edgar




On 9/16/15, 10:56 AM, "JJ Asghar" <jj at chef.io> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>All,
>
>Great news! Our OSOps project is alive and well in the openstack
>namespace!
>
>The start of the repos[1], our launchpad[2], answers[3], bugs[4], and
>wiki[5].
>
>Please take a moment and let's get our project going!
>
>There are a few IRC meetings times, I'd love to have a conversation
>about we can congregate the different times to streamline workflows.
>
>Any thoughts or suggestions on these meetings?
>
>[1]: http://git.openstack.org/cgit/?q=osops
>[2]: http://launchpad.net/osops
>[3]: https://answers.launchpad.net/osops
>[4]: https://bugs.launchpad.net/osops
>[5]: https://wiki.openstack.org/wiki/Osops
>
>
>- -- 
>Best Regards,
>JJ Asghar
>c: 512.619.0722 t: @jjasghar irc: j^2
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2
>Comment: GPGTools - https://gpgtools.org
>
>iQIcBAEBCgAGBQJV+a03AAoJEDZbxzMH0+jTde0P/0CXmdzNv029R967LoEaOASQ
>qe4lkr85QBezKNlnvfsZz/d4q8upWcbUwF2fXsGcDFVECXWGZDa2mpXu/UxKnwtA
>YHUO0cPo/aqh9bvxhzj+Bv1ouRgiOSpaj7zHmc9DujuZOfoOIniRKyqaSpI1xjHe
>rzSuv7Z9bTgJH7cShHx+dUu10Vdzqay866BBrIl5BviH5/Nz0itO3azYd2TWfoVD
>GKrA8UW35i3+4NFo6j6NZtawt8ByXUIwgSruJ4QYrIZbBNgzAhTAKotH7xyJ7oqo
>WLv6J33cO+NFzcGkaVISjo7u+L3HlJGINrpvqEmNFqon6unUTVxJdg+G6EK3S3DP
>+Bwl03bNtwFAZh20yGcEDu+W9pHlXaihaoL1MsKX7x38uSFSrKMfplp0GMhtLbWO
>woIs/cRsc+loHm3y42Ycj/1+xvfceZU3606qdZ8IvtDF4N0zmVNLqeO9LzTntiB7
>U23krYD2PqWGWD1VdfePUiWVdlgvyhMoXNAS8+/8BdIC2KqtBXKYRe9Zvmn9F+4/
>ied3oiqFs3QokFO2vLgvithrFJ/rOzm4MRI2XALmeIPN/8sh9cxBvk5RjtrQVDEj
>ZQ3QK32cirxNG4lJmsKLMyGL5MQHsOKlsi/M+SJ/7EQ7XanqmbTGa5Uw6s1g5mO+
>pRmjnYle0YJWyIqsR6SD
>=tPGS
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From edgar.magana at workday.com  Wed Sep 16 18:42:03 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Wed, 16 Sep 2015 18:42:03 +0000
Subject: [Openstack-operators] best openstack distro for vmware
In-Reply-To: <CAB7j8cUxq8Qk0mP+ub0kCf708AdYSLxzDw5FMx_NULomqLESuQ@mail.gmail.com>
References: <CAB7j8cXzt99w7ADXrFkq8xwSTg-1GWTCaGdASNDKLspXVjwBvw@mail.gmail.com>
 <CAB7j8cUxq8Qk0mP+ub0kCf708AdYSLxzDw5FMx_NULomqLESuQ@mail.gmail.com>
Message-ID: <DE2CF3AA-1D5E-4D28-A88D-AC4E9E98F613@workday.com>

You may need to be more specific about the integration that you are looking for.
Do you need ESXi only support or integration with other vmware components.

Cheers,

Edgar

From: Ignazio Cassano
Date: Wednesday, September 16, 2015 at 11:18 AM
To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
Subject: [Openstack-operators] best openstack distro for vmware


Hi all,
I am looking for an openstack distro with a good integration with vmware esxi.
I know the best result is using kvm but we have a lot of vm on vmware.
I read about vio, platform9  and red hat but I need  to retrive some comparison document and openstack roadmap on vmware.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/8de8520c/attachment.html>

From jbajin at verisign.com  Wed Sep 16 18:49:07 2015
From: jbajin at verisign.com (Bajin, Joseph)
Date: Wed, 16 Sep 2015 18:49:07 +0000
Subject: [Openstack-operators] [openstack-operators][osops] It's alive!
In-Reply-To: <55F9B2AF.8020308@chef.io>
References: <55F9AD37.1030009@chef.io>
 <E9B2DF6D-0038-4C50-8839-48AD91BCE044@verisign.com>
 <55F9B2AF.8020308@chef.io>
Message-ID: <D5EE5210-E006-4A1A-8D78-01516E8B7F1B@verisign.com>


Everyone that initially set this up, hadn?t done this before, so we actually never setup another page to where the agenda was posted.  I would just send a note to the ListServ putting out a link to the log of the meeting room and then what actions were left.

Here are all the links that I have:
http://eavesdrop.openstack.org/#Operators_Monitoring/Ops_Tools_Working_Group
http://eavesdrop.openstack.org/meetings/operators_ops_tools_monitoring/2015/

If someone lets me know this should be done, I?m happy to setup a page and get that going.



From: JJ Asghar
Reply-To: "jj at chef.io<mailto:jj at chef.io>"
Date: Wednesday, September 16, 2015 at 2:19 PM
To: "Bajin, Joseph", OpenStack Operators Mailing List
Subject: Re: [Openstack-operators] [openstack-operators][osops] It's alive!


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Awesome. This is great.

I could try to find it, but can you link me to the agenda? There's a couple things I'd like to ask and look for some consensus so we can continue moving the framework forward.


Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2

On 9/16/15 11:13 AM, Bajin, Joseph wrote:
> Thank JJ for getting this setup.
>
> Last week, I sent an email to the group about changing around the times for the Ops Tools and Monitoring Working group.  I got two responses based on it saying that basically 2pm or so is the best times that works on Wednesdays.   I was planning on getting that pushed and setup.  I know the first few meetings and all the Operator Meet-Up notes during these sessions all mentioned the repo and utilizing it, so if you would like to use that time I think that is fine by me.
>
> ?Joe
>
>
>
>
>
>
>
>
>
>
> On 9/16/15, 1:56 PM, "JJ Asghar" <jj at chef.io><mailto:jj at chef.io> wrote:
>
> All,
>
> Great news! Our OSOps project is alive and well in the openstack
> namespace!
>
> The start of the repos[1], our launchpad[2], answers[3], bugs[4], and
> wiki[5].
>
> Please take a moment and let's get our project going!
>
> There are a few IRC meetings times, I'd love to have a conversation
> about we can congregate the different times to streamline workflows.
>
> Any thoughts or suggestions on these meetings?
>
> [1]: http://git.openstack.org/cgit/?q=osops
> [2]: http://launchpad.net/osops
> [3]: https://answers.launchpad.net/osops
> [4]: https://bugs.launchpad.net/osops
> [5]: https://wiki.openstack.org/wiki/Osops
>
>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+bKvAAoJEDZbxzMH0+jTGOcQAKk09+Nakm89r7xlzyeeQqjx
Hi2sK+/DANhUCF2cXakgB14Fo0QOlVoewBez2IjtRbwZIq3TlJHPITD/bCG5vMe4
EdP5tuBj4B4RITOgN7Sgl8vE7+hFNKaizSra30GLuVcX2YrJrtd+Wz7SWvOYiioh
f7hd4PJE6Xxe+MoCk5jpAtl0SZ7XzCtkvvd2GYCUa4lx6cec9ur7KeuztPyLA2Ye
ko0hPwjefS7NUziPqLuLEuUdvp4rsYHyDCUI2Zq/1q3Gm6oAjdPLgaCN/U5gTT+M
bDOhfMxa8PpEimsEDRNBHBKpVMrWYp01izqsTqlWoZ3ScM7+mrTT8vrMEvNY3RMh
bBmbAxsYOQr7Zq0EptgN+vxqaD00pcvqqUUKKKN2jcRnlJI1k8/SIq62N+PVRI6C
Gt94opAr6miD8kCYTKX6VFUPDSm2+uDFw7BnEekAGdM45sj2SBRl83MAYBpNbnMb
jNBeqAB65U3q0vt1FGAE7XeEx+hfJiMEoTKXVYP8okA6tznaaWnZ3BJVBT4ACRD9
kxDlEJRrp6IRE1kuhFp+XXtDJ9ohOlQgFQ6qSCsns0fHro9WzKrTad70yFZgjQE9
/rguqgPtS+5agonHnbAXLAlIJJZbkhxVKihGydB2hEAclafdWmwYAykEOObw0BAh
UhF7DiLrrxA4aBvKG6Sl
=xMj8
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/4cfd1e09/attachment.html>

From gspot.afdb at gmail.com  Wed Sep 16 18:51:36 2015
From: gspot.afdb at gmail.com (G Spot)
Date: Wed, 16 Sep 2015 14:51:36 -0400
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
Message-ID: <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>

Hi All,

I want patch bugs in openstack like downloading patch from github and patch
it manually is there any document or procedure to follow? please guide me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/582de935/attachment.html>

From edgar.magana at workday.com  Wed Sep 16 19:00:23 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Wed, 16 Sep 2015 19:00:23 +0000
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
Message-ID: <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>

Do not do that!!!

Fix the bug upstream and then back port your commit.

https://wiki.openstack.org/wiki/How_To_Contribute
http://docs.openstack.org/infra/manual/developers.html

Edgar

From: G Spot
Date: Wednesday, September 16, 2015 at 11:51 AM
To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
Subject: [Openstack-operators] Fwd: Patching openstack


Hi All,

I want patch bugs in openstack like downloading patch from github and patch it manually is there any document or procedure to follow? please guide me




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/3530a9d1/attachment.html>

From bhines at gmail.com  Wed Sep 16 19:04:28 2015
From: bhines at gmail.com (Ben Hines)
Date: Wed, 16 Sep 2015 12:04:28 -0700
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
Message-ID: <CABGPr5knkxpgciVCmYVjcR_yo9G=67Xkj1=AfcKT9wj1ExC6KQ@mail.gmail.com>

It sounds like he's talking about bugs which are already fixed, on
github or elsewhere. You can't always wait until the next openstack
release to apply a critical fix.

I use Puppet to apply any custom patches, which keeps them carefully
tracked and source controlled.

-Ben


From edgar.magana at workday.com  Wed Sep 16 19:06:37 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Wed, 16 Sep 2015 19:06:37 +0000
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <CABGPr5knkxpgciVCmYVjcR_yo9G=67Xkj1=AfcKT9wj1ExC6KQ@mail.gmail.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
 <CABGPr5knkxpgciVCmYVjcR_yo9G=67Xkj1=AfcKT9wj1ExC6KQ@mail.gmail.com>
Message-ID: <347BBB57-546F-434E-BBB2-28FFB5AC2C44@workday.com>

Got it! We are using chef cookbook wrapper for those cases!!

Edgar




On 9/16/15, 12:04 PM, "Ben Hines" <bhines at gmail.com> wrote:

>It sounds like he's talking about bugs which are already fixed, on
>github or elsewhere. You can't always wait until the next openstack
>release to apply a critical fix.
>
>I use Puppet to apply any custom patches, which keeps them carefully
>tracked and source controlled.
>
>-Ben

From david.wahlstrom at gmail.com  Wed Sep 16 19:19:58 2015
From: david.wahlstrom at gmail.com (David Wahlstrom)
Date: Wed, 16 Sep 2015 12:19:58 -0700
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <347BBB57-546F-434E-BBB2-28FFB5AC2C44@workday.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
 <CABGPr5knkxpgciVCmYVjcR_yo9G=67Xkj1=AfcKT9wj1ExC6KQ@mail.gmail.com>
 <347BBB57-546F-434E-BBB2-28FFB5AC2C44@workday.com>
Message-ID: <CAJ4zFrYG42jQqpUavVBgCCfiw-J10sjqLL+XKqyru5mm00mCvA@mail.gmail.com>

We package our own openstack software from git (with a jenkins job).
During this process, we will include any custom packages that may not have
been officially backported yet.

On Wed, Sep 16, 2015 at 12:06 PM, Edgar Magana <edgar.magana at workday.com>
wrote:

> Got it! We are using chef cookbook wrapper for those cases!!
>
> Edgar
>
>
>
>
> On 9/16/15, 12:04 PM, "Ben Hines" <bhines at gmail.com> wrote:
>
> >It sounds like he's talking about bugs which are already fixed, on
> >github or elsewhere. You can't always wait until the next openstack
> >release to apply a critical fix.
> >
> >I use Puppet to apply any custom patches, which keeps them carefully
> >tracked and source controlled.
> >
> >-Ben
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
David W.
Unix, because every barista in Seattle has an MCSE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/44fa2aec/attachment.html>

From raju.roks at gmail.com  Wed Sep 16 19:24:31 2015
From: raju.roks at gmail.com (raju)
Date: Wed, 16 Sep 2015 15:24:31 -0400
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <CABGPr5knkxpgciVCmYVjcR_yo9G=67Xkj1=AfcKT9wj1ExC6KQ@mail.gmail.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
 <CABGPr5knkxpgciVCmYVjcR_yo9G=67Xkj1=AfcKT9wj1ExC6KQ@mail.gmail.com>
Message-ID: <CAMhjf2hFuObt1XOjho2vT+KGoejO0pTWBMR3ifsykrhQQe-Pzw@mail.gmail.com>

Exactly Ben, lets say I have issues with nova in my environment how to fix
those bugs by manually getting it from git and packaging are there any
steps how to follow and backup the current version to roll back?

On Wed, Sep 16, 2015 at 3:04 PM, Ben Hines <bhines at gmail.com> wrote:

> It sounds like he's talking about bugs which are already fixed, on
> github or elsewhere. You can't always wait until the next openstack
> release to apply a critical fix.
>
> I use Puppet to apply any custom patches, which keeps them carefully
> tracked and source controlled.
>
> -Ben
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/d0dbc9ce/attachment.html>

From mgagne at internap.com  Wed Sep 16 19:25:50 2015
From: mgagne at internap.com (=?UTF-8?Q?Mathieu_Gagn=c3=a9?=)
Date: Wed, 16 Sep 2015 15:25:50 -0400
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
Message-ID: <55F9C23E.7080009@internap.com>

On 2015-09-16 3:00 PM, Edgar Magana wrote:
> Do not do that!!!
> 
> Fix the bug upstream and then back port your commit.
> 
> https://wiki.openstack.org/wiki/How_To_Contribute
> http://docs.openstack.org/infra/manual/developers.html
> 

I think he is referring to the "What packages does this deployment size
use?" question from "Packaging" section found in the User Survey [1].

Operators and deployers will often package their own versions to get
bugfixes or features more quickly than the upstream package can do. (See
results for the "If you have modified packages or have built your own
packages, why?")

Unfortunately the packaging and patching process isn't a turn-key
solution. Each operators developed their own. Some open-sourced their
solution [2][3] which might or not answer your needs. This explains why
we are still having "Packaging" sessions in the OpenStack Ops Meetup.

We use a manual process with imply importing and forking Ubuntu packages
and applying our own patches in debian/patches. The packages are then
built and published by Jenkins.

[1]
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
[2] https://github.com/blueboxgroup/giftwrap
[3] https://github.com/rconradharris/ply

-- 
Mathieu


From gspot.afdb at gmail.com  Wed Sep 16 19:27:10 2015
From: gspot.afdb at gmail.com (G Spot)
Date: Wed, 16 Sep 2015 15:27:10 -0400
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
Message-ID: <CAMO2T7E0SMo7WxgsRSX8hTBe=dn0e1OWAR88OY3mxnBgd50SXg@mail.gmail.com>

Thanks Edgar,

I want to patch bugs in my openstack test environment are there any
documents to follow without upgrading to major release?

On Wed, Sep 16, 2015 at 3:00 PM, Edgar Magana <edgar.magana at workday.com>
wrote:

> Do not do that!!!
>
> Fix the bug upstream and then back port your commit.
>
> https://wiki.openstack.org/wiki/How_To_Contribute
> http://docs.openstack.org/infra/manual/developers.html
>
> Edgar
>
> From: G Spot
> Date: Wednesday, September 16, 2015 at 11:51 AM
> To: "openstack-operators at lists.openstack.org"
> Subject: [Openstack-operators] Fwd: Patching openstack
>
>
> Hi All,
>
> I want patch bugs in openstack like downloading patch from github and
> patch it manually is there any document or procedure to follow? please
> guide me
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/9c4fb937/attachment.html>

From gspot.afdb at gmail.com  Wed Sep 16 19:29:35 2015
From: gspot.afdb at gmail.com (G Spot)
Date: Wed, 16 Sep 2015 15:29:35 -0400
Subject: [Openstack-operators] Fwd: Patching openstack
In-Reply-To: <55F9C23E.7080009@internap.com>
References: <CAMO2T7GLcG9cJCfBMwf7W1=Gf9m_-EJQoPa_093PFzKjCCNRdQ@mail.gmail.com>
 <CAMO2T7H2cpU-df2=V05NfPmoen7Hm+OZNk9-Lm+C+TBxPkfGvA@mail.gmail.com>
 <60D18519-24E0-43A5-88B1-E1E672CA9E85@workday.com>
 <55F9C23E.7080009@internap.com>
Message-ID: <CAMO2T7E9L6gqUXm4f9Uu9GriRr4W0GGkjBMaBjMdp6e0MBy1Pw@mail.gmail.com>

Thanks Mathieu Gagn?, got some idea.

On Wed, Sep 16, 2015 at 3:25 PM, Mathieu Gagn? <mgagne at internap.com> wrote:

> On 2015-09-16 3:00 PM, Edgar Magana wrote:
> > Do not do that!!!
> >
> > Fix the bug upstream and then back port your commit.
> >
> > https://wiki.openstack.org/wiki/How_To_Contribute
> > http://docs.openstack.org/infra/manual/developers.html
> >
>
> I think he is referring to the "What packages does this deployment size
> use?" question from "Packaging" section found in the User Survey [1].
>
> Operators and deployers will often package their own versions to get
> bugfixes or features more quickly than the upstream package can do. (See
> results for the "If you have modified packages or have built your own
> packages, why?")
>
> Unfortunately the packaging and patching process isn't a turn-key
> solution. Each operators developed their own. Some open-sourced their
> solution [2][3] which might or not answer your needs. This explains why
> we are still having "Packaging" sessions in the OpenStack Ops Meetup.
>
> We use a manual process with imply importing and forking Ubuntu packages
> and applying our own patches in debian/patches. The packages are then
> built and published by Jenkins.
>
> [1]
>
> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
> [2] https://github.com/blueboxgroup/giftwrap
> [3] https://github.com/rconradharris/ply
>
> --
> Mathieu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/452be428/attachment.html>

From ignaziocassano at gmail.com  Wed Sep 16 20:05:08 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Wed, 16 Sep 2015 22:05:08 +0200
Subject: [Openstack-operators] best openstack distro for vmware
In-Reply-To: <DE2CF3AA-1D5E-4D28-A88D-AC4E9E98F613@workday.com>
References: <CAB7j8cXzt99w7ADXrFkq8xwSTg-1GWTCaGdASNDKLspXVjwBvw@mail.gmail.com>
 <CAB7j8cUxq8Qk0mP+ub0kCf708AdYSLxzDw5FMx_NULomqLESuQ@mail.gmail.com>
 <DE2CF3AA-1D5E-4D28-A88D-AC4E9E98F613@workday.com>
Message-ID: <CAB7j8cUH0e41iZqVmOu4Vz-0QtnU8STDB0BXtGD3jMhJsAGB_Q@mail.gmail.com>

Hi Edgar,  I am looking for vcenter compontents functionalities.
Regards
Il giorno 16/set/2015 20:42, "Edgar Magana" <edgar.magana at workday.com> ha
scritto:

> You may need to be more specific about the integration that you are
> looking for.
> Do you need ESXi only support or integration with other vmware components.
>
> Cheers,
>
> Edgar
>
> From: Ignazio Cassano
> Date: Wednesday, September 16, 2015 at 11:18 AM
> To: "openstack-operators at lists.openstack.org"
> Subject: [Openstack-operators] best openstack distro for vmware
>
> Hi all,
> I am looking for an openstack distro with a good integration with vmware
> esxi.
> I know the best result is using kvm but we have a lot of vm on vmware.
> I read about vio, platform9  and red hat but I need  to retrive some
> comparison document and openstack roadmap on vmware.
> Regards
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150916/050605ac/attachment.html>

From abhishek.talwar at tcs.com  Thu Sep 17 05:37:50 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Thu, 17 Sep 2015 11:07:50 +0530
Subject: [Openstack-operators]  How to shift from V2 to V2.1 API
Message-ID: <OFD54FE4F6.76E441FC-ON65257EC3.001EEDF7-65257EC3.001EEDF9@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/24822ddc/attachment.html>

From ignaziocassano at gmail.com  Thu Sep 17 06:39:40 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Thu, 17 Sep 2015 08:39:40 +0200
Subject: [Openstack-operators] best openstack distro for vmware
In-Reply-To: <DE2CF3AA-1D5E-4D28-A88D-AC4E9E98F613@workday.com>
References: <CAB7j8cXzt99w7ADXrFkq8xwSTg-1GWTCaGdASNDKLspXVjwBvw@mail.gmail.com>
 <CAB7j8cUxq8Qk0mP+ub0kCf708AdYSLxzDw5FMx_NULomqLESuQ@mail.gmail.com>
 <DE2CF3AA-1D5E-4D28-A88D-AC4E9E98F613@workday.com>
Message-ID: <CAB7j8cUiv-k_PosCvQooGvJUr9TgWiy0cO_jdh-2Dt_Hu-cQEA@mail.gmail.com>

Hi Edgar, to be more specific I heard about some limitations:

- Openstack does use regions, zones and aggregates with vmware
- Openstack sees vmware clusters like a unique node
- Openstack supports only vmware drs full automation
- Openstack does not support obeject storage with vmware
- Opestanck gance does not support ovf format
- Openstack with vmware does not support ephemeral storage
- Opstanck celiometer is not ehough for vmware and we need vrealize
etc etc etc ....
Regards

2015-09-16 20:42 GMT+02:00 Edgar Magana <edgar.magana at workday.com>:

> You may need to be more specific about the integration that you are
> looking for.
> Do you need ESXi only support or integration with other vmware components.
>
> Cheers,
>
> Edgar
>
> From: Ignazio Cassano
> Date: Wednesday, September 16, 2015 at 11:18 AM
> To: "openstack-operators at lists.openstack.org"
> Subject: [Openstack-operators] best openstack distro for vmware
>
> Hi all,
> I am looking for an openstack distro with a good integration with vmware
> esxi.
> I know the best result is using kvm but we have a lot of vm on vmware.
> I read about vio, platform9  and red hat but I need  to retrive some
> comparison document and openstack roadmap on vmware.
> Regards
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/41eb0ea4/attachment.html>

From abhishek.talwar at tcs.com  Thu Sep 17 07:05:17 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Thu, 17 Sep 2015 12:35:17 +0530
Subject: [Openstack-operators]   how to get an instance vcpu usage
Message-ID: <OF13973131.65BEAA50-ON65257EC3.0026EFB3-65257EC3.0026EFB5@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/8a69e963/attachment.html>

From lisha2010hust at gmail.com  Thu Sep 17 07:38:42 2015
From: lisha2010hust at gmail.com (Sha Li)
Date: Thu, 17 Sep 2015 15:38:42 +0800
Subject: [Openstack-operators] deploy nova cells with neutron network
Message-ID: <CAFKq=acs2Qy7jwhm84U2N44X1-jMxvZ0K2L=NDTpfNu2oDDGxQ@mail.gmail.com>

Hi,

I am try to test the nova cells function.
My test deployment consits of one api-cell node, one child-cell node and
one compute node.

api-cell node:  nova-api, nova-cells, nova-cert, nova-condoleauth,
nova-novncproxy
child-cell node: nova-cells, nova-conductor, nova-scheduler
compute node: nova-compute

I found most deployment example is using nova-network with nova-cells. I
want to use neutron. So I had keystone , glance, and neutron-server,
neutron-dhcp, neutron-l3  shared between all cells and deployed all on the
api-cell node.

I encounterd similar problem as described in this bug report
https://bugs.launchpad.net/nova/+bug/1348103

When boot a new instance, nova-compute fails to get the network-vif-plugged
 notification and get time out waiting for the call back.
But on the neutron server side, it looks like the notification had been
successfully sent and get the 200 response code from nova-api server

I had to set
vif_plugging_is_fatal = False
Then the instnace can be spawned normally

I am wondering how people use neutron with nova-cells, is this going to
cause any trouble in large scale production deployment.


Cheers,
Sha



--- neutron server log file

2015-08-22 00:20:35.464 16812 DEBUG neutron.notifiers.nova [-] Sending
events: [{'status': 'completed', 'tag':
u'2839ca4d-b632-4d64-a174-ecfe34a7a746', 'name': 'network-vif-plugged',
'server_uuid': u'092c8bc4-3643-44c0-b79e-ad5caac18b3d'}] send_events
/usr/lib/python2.7/site-packages/neutron/notifiers/nova.py:232

2015-08-22 00:20:35.468 16812 INFO urllib3.connectionpool [-] Starting new
HTTP connection (1): 192.168.81.221

2015-08-22 00:20:35.548 16812 DEBUG urllib3.connectionpool [-] "POST
/v2/338aad513c604880a6a0dcc58b88b905/*os**-server-external-events *HTTP/1.1"
200 183 _make_request /usr/lib/python2.7/site-packages/urllib3/connectionp
ool.py:357

2015-08-22 00:20:35.550 16812 INFO neutron.notifiers.nova [-] Nova event
*response*: {u'status': u'completed', u'tag':
u'2839ca4d-b632-4d64-a174-ecfe34a7a746', u'name': u'network-vif-plugged',
u'server_uuid': u'092c8bc4-3643-44c0-b79e-ad5caac18b3d', u'code': 200}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/ae724064/attachment.html>

From matt.jarvis at datacentred.co.uk  Thu Sep 17 07:52:55 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Thu, 17 Sep 2015 08:52:55 +0100
Subject: [Openstack-operators] European Operators
Message-ID: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>

Hi All

Don't know how many European folks are on this list, but just wondering if
there's any interest in a European Operators meet up ?

Matt

-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/2bbe04a2/attachment-0001.html>

From salman.toor at it.uu.se  Thu Sep 17 08:02:20 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Thu, 17 Sep 2015 08:02:20 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
Message-ID: <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>

Hi,

Why Not!

I think its a great Idea. I want to join.

Regards..
Salman


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>> wrote:

Hi All

Don't know how many European folks are on this list, but just wondering if there's any interest in a European Operators meet up ?

Matt

--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>

DataCentred Limited registered in England and Wales no. 05611763_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/a52190c4/attachment.html>

From Arne.Wiebalck at cern.ch  Thu Sep 17 08:06:47 2015
From: Arne.Wiebalck at cern.ch (Arne Wiebalck)
Date: Thu, 17 Sep 2015 08:06:47 +0000
Subject: [Openstack-operators] Cinder Juno to Kilo upgrade and DB encodings
Message-ID: <E590B107-F40F-4D40-9C3E-4F6F579E2848@cern.ch>

Hi,

During our Cinder upgrade on CentOS7 from Juno to Kilo, we ran into this bug:
https://bugs.launchpad.net/cinder/+bug/1455726

As there is no fix available from what I see, what we came up with as a ?solution?
is to explicitly set the character and the collation in all existing tables in the database
before the upgrade:

?>
alter database cinder CHARACTER SET utf8 COLLATE utf8_unicode_ci;
SET foreign_key_checks = 0;
ALTER TABLE `backups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `cgsnapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `consistencygroups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `encryption` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `iscsi_targets` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `migrate_version` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quality_of_service_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quota_classes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quota_usages` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quotas` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `reservations` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `services` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `snapshot_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `snapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `transfers` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_admin_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_glance_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_type_extra_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_types` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volumes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
SET foreign_key_checks = 1;
<?

Note that in our case the databases default character set was already utf8 everywhere, while the collation
was utf8_general_ci. With that conversion the upgrade seems to work fine in our tests.

Before we retry the upgrade: do if people here think that this a reasonable approach or will this cause
other issues? Are there alternative approaches?

Thanks!
 Arne

?
Arne Wiebalck
CERN IT






From olivier.cant at exxoss.com  Thu Sep 17 08:08:58 2015
From: olivier.cant at exxoss.com (Olivier Cant)
Date: Thu, 17 Sep 2015 10:08:58 +0200
Subject: [Openstack-operators] European Operators
In-Reply-To: <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
Message-ID: <55FA751A.90908@exxoss.com>

Also very intrested.

Olivier

On 17/09/15S38 10:02, Salman Toor wrote:
> Hi,
>
> Why Not!
>
> I think its a great Idea. I want to join.
>
> Regards..
> Salman
>
>
> PhD, Scientific Computing
> Researcher, IT Department,
> Uppsala University.
> Cloud Application Expert,
> UPPMAX.
> Visiting Researcher,
> Helsinki Institute of Physics (HIP).
> salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
> http://www.it.uu.se/katalog/salto690
>
>> On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk 
>> <mailto:matt.jarvis at datacentred.co.uk>> wrote:
>>
>> Hi All
>>
>> Don't know how many European folks are on this list, but just 
>> wondering if there's any interest in a European Operators meet up ?
>>
>> Matt
>>
>> -- 
>> Matt Jarvis
>> Head of Cloud Computing
>> DataCentred
>> Office: (+44)0161 8703985
>> Mobile: (+44)07983 725372
>> Email: matt.jarvis at datacentred.co.uk 
>> <mailto:matt.jarvis at datacentred.co.uk>
>> Website: http://www.datacentred.co.uk <http://www.datacentred.co.uk/>
>>
>> DataCentred Limited registered in England and Wales no. 
>> 05611763_______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org 
>> <mailto:OpenStack-operators at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-- 


Exxoss <http://www.exxoss.com>
*Olivier Cant*, CEO | Gsm: +32(0)497/64.18.22
*Exxoss, SPRL <http://www.exxoss.com>*
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone: 
+32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
Twitter <http://twitter.com/exxossIT> Facebook 
<http://facebook.com/exxoss> Linked In 
<https://www.linkedin.com/company/exxoss>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/4f2f9fda/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-exxoss.png
Type: image/png
Size: 16268 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/4f2f9fda/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-twitter.png
Type: image/png
Size: 3376 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/4f2f9fda/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-facebook.png
Type: image/png
Size: 3460 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/4f2f9fda/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-linkedin.png
Type: image/png
Size: 3537 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/4f2f9fda/attachment-0003.png>

From matthias.britsch at telekom.de  Thu Sep 17 09:09:34 2015
From: matthias.britsch at telekom.de (matthias.britsch at telekom.de)
Date: Thu, 17 Sep 2015 11:09:34 +0200
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FA751A.90908@exxoss.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
Message-ID: <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>

I would be interested as well.

Best regards,       Matthias

Von: Olivier Cant [mailto:olivier.cant at exxoss.com]
Gesendet: Donnerstag, 17. September 2015 10:09
An: openstack-operators at lists.openstack.org
Betreff: Re: [Openstack-operators] European Operators

Also very intrested.

Olivier

On 17/09/15S38 10:02, Salman Toor wrote:
Hi,

Why Not!

I think its a great Idea. I want to join.

Regards..
Salman


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>> wrote:

Hi All

Don't know how many European folks are on this list, but just wondering if there's any interest in a European Operators meet up ?

Matt

--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>

DataCentred Limited registered in England and Wales no. 05611763_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





_______________________________________________

OpenStack-operators mailing list

OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--

[cid:image001.png at 01D0F139.55599AF0]<http://www.exxoss.com>
Olivier Cant, CEO | Gsm: +32(0)497/64.18.22
Exxoss, SPRL<http://www.exxoss.com>
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone: +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
[cid:image002.png at 01D0F139.55599AF0]<http://twitter.com/exxossIT>[cid:image003.png at 01D0F139.55599AF0]<http://facebook.com/exxoss>[cid:image004.png at 01D0F139.55599AF0]<https://www.linkedin.com/company/exxoss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/16360a9b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16268 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/16360a9b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3376 bytes
Desc: image002.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/16360a9b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3460 bytes
Desc: image003.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/16360a9b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3537 bytes
Desc: image004.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/16360a9b/attachment-0003.png>

From jerome.pansanel at iphc.cnrs.fr  Thu Sep 17 09:14:33 2015
From: jerome.pansanel at iphc.cnrs.fr (Jerome Pansanel)
Date: Thu, 17 Sep 2015 11:14:33 +0200
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FA751A.90908@exxoss.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
Message-ID: <55FA8479.3050902@iphc.cnrs.fr>

+1 !

Jerome

Le 17/09/2015 10:08, Olivier Cant a ?crit :
> Also very intrested.
>
> Olivier
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>> Hi,
>>
>> Why Not!
>>
>> I think its a great Idea. I want to join.
>>
>> Regards..
>> Salman
>>
>>
>> PhD, Scientific Computing
>> Researcher, IT Department,
>> Uppsala University.
>> Cloud Application Expert,
>> UPPMAX.
>> Visiting Researcher,
>> Helsinki Institute of Physics (HIP).
>> salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
>> http://www.it.uu.se/katalog/salto690
>>
>>> On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk 
>>> <mailto:matt.jarvis at datacentred.co.uk>> wrote:
>>>
>>> Hi All
>>>
>>> Don't know how many European folks are on this list, but just 
>>> wondering if there's any interest in a European Operators meet up ?
>>>
>>> Matt
>>>
>>> -- 
>>> Matt Jarvis
>>> Head of Cloud Computing
>>> DataCentred
>>> Office: (+44)0161 8703985
>>> Mobile: (+44)07983 725372
>>> Email: matt.jarvis at datacentred.co.uk 
>>> <mailto:matt.jarvis at datacentred.co.uk>
>>> Website: http://www.datacentred.co.uk <http://www.datacentred.co.uk/>
>>>
>>> DataCentred Limited registered in England and Wales no. 
>>> 05611763_______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org 
>>> <mailto:OpenStack-operators at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> -- 
>
>
> Exxoss <http://www.exxoss.com>
> *Olivier Cant*, CEO | Gsm: +32(0)497/64.18.22
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone: 
> +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
> Twitter <http://twitter.com/exxossIT> Facebook 
> <http://facebook.com/exxoss> Linked In 
> <https://www.linkedin.com/company/exxoss>
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-- 
Jerome Pansanel
Technical Director at France Grilles
Grid & Cloud Computing Operations Manager at IPHC
IPHC                        ||  GSM: +33 (0)6 25 19 24 43
23 rue du Loess, BP 28      ||  Tel: +33 (0)3 88 10 66 24
F-67037 STRASBOURG Cedex 2  ||  Fax: +33 (0)3 88 10 62 34

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/7e06fe3c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 16268 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/7e06fe3c/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3376 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/7e06fe3c/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3460 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/7e06fe3c/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3537 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/7e06fe3c/attachment-0007.png>

From dabarren at gmail.com  Thu Sep 17 09:19:13 2015
From: dabarren at gmail.com (Eduardo Gonzalez)
Date: Thu, 17 Sep 2015 09:19:13 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FA751A.90908@exxoss.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
Message-ID: <CAKZYVLzxqAK2ZboxiUCY9=9wvAoW_FrFKPqq1KtoJHQeZXTwFQ@mail.gmail.com>

I think is a good idea, very interested too

Regards

On Thu, Sep 17, 2015, 10:15 AM Olivier Cant <olivier.cant at exxoss.com> wrote:

> Also very intrested.
>
> Olivier
>
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>
> Hi,
>
> Why Not!
>
> I think its a great Idea. I want to join.
>
> Regards..
> Salman
>
>
> PhD, Scientific Computing
> Researcher, IT Department,
> Uppsala University.
> Cloud Application Expert,
> UPPMAX.
> Visiting Researcher,
> Helsinki Institute of Physics (HIP).
> salman.toor at it.uu.se
> http://www.it.uu.se/katalog/salto690
>
> On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk>
> wrote:
>
> Hi All
>
> Don't know how many European folks are on this list, but just wondering if
> there's any interest in a European Operators meet up ?
>
> Matt
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk
> Website: http://www.datacentred.co.uk
>
> DataCentred Limited registered in England and Wales no. 05611763
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing listOpenStack-operators at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> --
>
>
> [image: Exxoss] <http://www.exxoss.com>
> *Olivier Cant*, CEO | Gsm: +32(0)497/64.18.22
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
> [image: Twitter] <http://twitter.com/exxossIT> [image: Facebook]
> <http://facebook.com/exxoss> [image: Linked In]
> <https://www.linkedin.com/company/exxoss>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/932d93d3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-exxoss.png
Type: image/png
Size: 16268 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/932d93d3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-twitter.png
Type: image/png
Size: 3376 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/932d93d3/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-facebook.png
Type: image/png
Size: 3460 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/932d93d3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-linkedin.png
Type: image/png
Size: 3537 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/932d93d3/attachment-0003.png>

From Paulo.EspadaPereira at imgtec.com  Thu Sep 17 09:42:37 2015
From: Paulo.EspadaPereira at imgtec.com (Paulo Espada Pereira)
Date: Thu, 17 Sep 2015 09:42:37 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>,
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
Message-ID: <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>


Very good idea!
Count with me.



Paulo Pereira
Senior Systems Operations Manager, FlowCloud
Imagination Technologies Limited
t: +44 (0)1923 260511
www.imgtec.com<http://www.imgtec.com/>

________________________________
From: matthias.britsch at telekom.de [matthias.britsch at telekom.de]
Sent: 17 September 2015 10:09
To: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] European Operators

I would be interested as well.

Best regards,       Matthias

Von: Olivier Cant [mailto:olivier.cant at exxoss.com]
Gesendet: Donnerstag, 17. September 2015 10:09
An: openstack-operators at lists.openstack.org
Betreff: Re: [Openstack-operators] European Operators

Also very intrested.

Olivier

On 17/09/15S38 10:02, Salman Toor wrote:
Hi,

Why Not!

I think its a great Idea. I want to join.

Regards..
Salman


PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>> wrote:

Hi All

Don't know how many European folks are on this list, but just wondering if there's any interest in a European Operators meet up ?

Matt

--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>

DataCentred Limited registered in England and Wales no. 05611763_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





_______________________________________________

OpenStack-operators mailing list

OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--

[Exxoss]<http://www.exxoss.com>
Olivier Cant, CEO | Gsm: +32(0)497/64.18.22
Exxoss, SPRL<http://www.exxoss.com>
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone: +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
[Twitter]<http://twitter.com/exxossIT>[Facebook]<http://facebook.com/exxoss>[Linked               In]<https://www.linkedin.com/company/exxoss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/cc5b2d34/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16268 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/cc5b2d34/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3376 bytes
Desc: image002.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/cc5b2d34/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3460 bytes
Desc: image003.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/cc5b2d34/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3537 bytes
Desc: image004.png
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/cc5b2d34/attachment-0003.png>

From tom at openstack.org  Thu Sep 17 12:04:54 2015
From: tom at openstack.org (Tom Fifield)
Date: Thu, 17 Sep 2015 20:04:54 +0800
Subject: [Openstack-operators] European Operators
In-Reply-To: <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
Message-ID: <55FAAC66.4090004@openstack.org>

Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:
> 
> Very good idea!
> Count with me.
> 
> 
> 
> *Paulo Pereira*
> 
> Senior Systems Operations Manager, FlowCloud
> 
> Imagination Technologies Limited
> 
> t: +44 (0)1923 260511
> 
> www.imgtec.com <http://www.imgtec.com/>
> 
> 
> ------------------------------------------------------------------------
> *From:* matthias.britsch at telekom.de [matthias.britsch at telekom.de]
> *Sent:* 17 September 2015 10:09
> *To:* openstack-operators at lists.openstack.org
> *Subject:* Re: [Openstack-operators] European Operators
> 
> I would be interested as well.
> 
> Best regards,       Matthias
> 
> *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
> *Gesendet:* Donnerstag, 17. September 2015 10:09
> *An:* openstack-operators at lists.openstack.org
> *Betreff:* Re: [Openstack-operators] European Operators
> 
> Also very intrested.
> 
> Olivier
> 
> On 17/09/15S38 10:02, Salman Toor wrote:
> 
>     Hi,
> 
>     Why Not!
> 
>     I think its a great Idea. I want to join.
> 
>     Regards..
> 
>     Salman
> 
>     PhD, Scientific Computing
>     Researcher, IT Department,
>     Uppsala University.
>     Cloud Application Expert,
>     UPPMAX.
>     Visiting Researcher,
>     Helsinki Institute of Physics (HIP).
>     salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
>     http://www.it.uu.se/katalog/salto690
> 
>         On 17 Sep 2015, at 09:52, Matt Jarvis
>         <matt.jarvis at datacentred.co.uk
>         <mailto:matt.jarvis at datacentred.co.uk>> wrote:
> 
>         Hi All
> 
>         Don't know how many European folks are on this list, but just
>         wondering if there's any interest in a European Operators meet up ?
> 
>         Matt
> 
>         -- 
> 
>         Matt Jarvis
> 
>         Head of Cloud Computing
>         DataCentred
> 
>         Office: (+44)0161 8703985
>         Mobile: (+44)07983 725372
> 
>         Email: matt.jarvis at datacentred.co.uk
>         <mailto:matt.jarvis at datacentred.co.uk>
> 
>         Website: http://www.datacentred.co.uk
>         <http://www.datacentred.co.uk/>
> 
> 
>         DataCentred Limited registered in England and Wales no.
>         05611763_______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> 
> 
>     _______________________________________________
> 
>     OpenStack-operators mailing list
> 
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
> 
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> -- 
> 
> Exxoss <http://www.exxoss.com>
> 
> *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone: 
> +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
> Twitter <http://twitter.com/exxossIT>Facebook 
> <http://facebook.com/exxoss>Linked In 
> <https://www.linkedin.com/company/exxoss>
> 
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 



From matt.jarvis at datacentred.co.uk  Thu Sep 17 12:15:24 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Thu, 17 Sep 2015 13:15:24 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FAAC66.4090004@openstack.org>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
Message-ID: <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>

I'm thinking we'll let this thread run for a day or so and hopefully gather
a few more interested parties, then take the conversation off-list and see
what the consensus is from those who've expressed an interest about how we
might move this forward ?

On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org> wrote:

> Cool :)
>
> When are you guys free?
>
> On 17/09/15 17:42, Paulo Espada Pereira wrote:
> >
> > Very good idea!
> > Count with me.
> >
> >
> >
> > *Paulo Pereira*
> >
> > Senior Systems Operations Manager, FlowCloud
> >
> > Imagination Technologies Limited
> >
> > t: +44 (0)1923 260511
> >
> > www.imgtec.com <http://www.imgtec.com/>
> >
> >
> > ------------------------------------------------------------------------
> > *From:* matthias.britsch at telekom.de [matthias.britsch at telekom.de]
> > *Sent:* 17 September 2015 10:09
> > *To:* openstack-operators at lists.openstack.org
> > *Subject:* Re: [Openstack-operators] European Operators
> >
> > I would be interested as well.
> >
> > Best regards,       Matthias
> >
> > *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
> > *Gesendet:* Donnerstag, 17. September 2015 10:09
> > *An:* openstack-operators at lists.openstack.org
> > *Betreff:* Re: [Openstack-operators] European Operators
> >
> > Also very intrested.
> >
> > Olivier
> >
> > On 17/09/15S38 10:02, Salman Toor wrote:
> >
> >     Hi,
> >
> >     Why Not!
> >
> >     I think its a great Idea. I want to join.
> >
> >     Regards..
> >
> >     Salman
> >
> >     PhD, Scientific Computing
> >     Researcher, IT Department,
> >     Uppsala University.
> >     Cloud Application Expert,
> >     UPPMAX.
> >     Visiting Researcher,
> >     Helsinki Institute of Physics (HIP).
> >     salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
> >     http://www.it.uu.se/katalog/salto690
> >
> >         On 17 Sep 2015, at 09:52, Matt Jarvis
> >         <matt.jarvis at datacentred.co.uk
> >         <mailto:matt.jarvis at datacentred.co.uk>> wrote:
> >
> >         Hi All
> >
> >         Don't know how many European folks are on this list, but just
> >         wondering if there's any interest in a European Operators meet
> up ?
> >
> >         Matt
> >
> >         --
> >
> >         Matt Jarvis
> >
> >         Head of Cloud Computing
> >         DataCentred
> >
> >         Office: (+44)0161 8703985
> >         Mobile: (+44)07983 725372
> >
> >         Email: matt.jarvis at datacentred.co.uk
> >         <mailto:matt.jarvis at datacentred.co.uk>
> >
> >         Website: http://www.datacentred.co.uk
> >         <http://www.datacentred.co.uk/>
> >
> >
> >         DataCentred Limited registered in England and Wales no.
> >         05611763_______________________________________________
> >         OpenStack-operators mailing list
> >         OpenStack-operators at lists.openstack.org
> >         <mailto:OpenStack-operators at lists.openstack.org>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> >
> >     _______________________________________________
> >
> >     OpenStack-operators mailing list
> >
> >     OpenStack-operators at lists.openstack.org
> >     <mailto:OpenStack-operators at lists.openstack.org>
> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > --
> >
> > Exxoss <http://www.exxoss.com>
> >
> > *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
> > *Exxoss, SPRL <http://www.exxoss.com>*
> > Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> > +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
> > Twitter <http://twitter.com/exxossIT>Facebook
> > <http://facebook.com/exxoss>Linked In
> > <https://www.linkedin.com/company/exxoss>
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/5c337f77/attachment.html>

From salman.toor at it.uu.se  Thu Sep 17 12:17:30 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Thu, 17 Sep 2015 12:17:30 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FAAC66.4090004@openstack.org>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
Message-ID: <968F3E8A-0F3D-49EF-ACC8-1F3C437FE6ED@it.uu.se>

Hi,

First or second week of October will be good for me.

/Salman.

PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 17 Sep 2015, at 14:04, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:

Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:

Very good idea!
Count with me.



*Paulo Pereira*

Senior Systems Operations Manager, FlowCloud

Imagination Technologies Limited

t: +44 (0)1923 260511

www.imgtec.com<http://www.imgtec.com> <http://www.imgtec.com/>


------------------------------------------------------------------------
*From:* matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de> [matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de>]
*Sent:* 17 September 2015 10:09
*To:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
*Subject:* Re: [Openstack-operators] European Operators

I would be interested as well.

Best regards,       Matthias

*Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
*Gesendet:* Donnerstag, 17. September 2015 10:09
*An:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
*Betreff:* Re: [Openstack-operators] European Operators

Also very intrested.

Olivier

On 17/09/15S38 10:02, Salman Toor wrote:

   Hi,

   Why Not!

   I think its a great Idea. I want to join.

   Regards..

   Salman

   PhD, Scientific Computing
   Researcher, IT Department,
   Uppsala University.
   Cloud Application Expert,
   UPPMAX.
   Visiting Researcher,
   Helsinki Institute of Physics (HIP).
   salman.toor at it.uu.se<mailto:salman.toor at it.uu.se> <mailto:salman.toor at it.uu.se>
   http://www.it.uu.se/katalog/salto690

       On 17 Sep 2015, at 09:52, Matt Jarvis
       <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
       <mailto:matt.jarvis at datacentred.co.uk>> wrote:

       Hi All

       Don't know how many European folks are on this list, but just
       wondering if there's any interest in a European Operators meet up ?

       Matt

       --

       Matt Jarvis

       Head of Cloud Computing
       DataCentred

       Office: (+44)0161 8703985
       Mobile: (+44)07983 725372

       Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
       <mailto:matt.jarvis at datacentred.co.uk>

       Website: http://www.datacentred.co.uk
       <http://www.datacentred.co.uk/>


       DataCentred Limited registered in England and Wales no.
       05611763_______________________________________________
       OpenStack-operators mailing list
       OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
       <mailto:OpenStack-operators at lists.openstack.org>
       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




   _______________________________________________

   OpenStack-operators mailing list

   OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
   <mailto:OpenStack-operators at lists.openstack.org>

   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--

Exxoss <http://www.exxoss.com>

*Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
*Exxoss, SPRL <http://www.exxoss.com>*
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
+32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
Twitter <http://twitter.com/exxossIT>Facebook
<http://facebook.com/exxoss>Linked In
<https://www.linkedin.com/company/exxoss>



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/6f9e5072/attachment.html>

From Neil.Jerram at metaswitch.com  Thu Sep 17 12:41:01 2015
From: Neil.Jerram at metaswitch.com (Neil Jerram)
Date: Thu, 17 Sep 2015 12:41:01 +0000
Subject: [Openstack-operators] European Operators
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
Message-ID: <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>

Are Europe-based developers/vendors welcome too?  My project (Calico) is always keen to understand more about operator interests and requirements, so I'd be very happy to be there.

    Neil


On 17/09/15 13:17, Matt Jarvis wrote:
I'm thinking we'll let this thread run for a day or so and hopefully gather a few more interested parties, then take the conversation off-list and see what the consensus is from those who've expressed an interest about how we might move this forward ?

On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:
Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:
>
> Very good idea!
> Count with me.
>
>
>
> *Paulo Pereira*
>
> Senior Systems Operations Manager, FlowCloud
>
> Imagination Technologies Limited
>
> t: +44 (0)1923 260511<tel:%2B44%20%280%291923%20260511>
>
> www.imgtec.com<http://www.imgtec.com> <<http://www.imgtec.com/>http://www.imgtec.com/>
>
>
> ------------------------------------------------------------------------
> *From:* matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de> [matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de>]
> *Sent:* 17 September 2015 10:09
> *To:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
> *Subject:* Re: [Openstack-operators] European Operators
>
> I would be interested as well.
>
> Best regards,       Matthias
>
> *Von:*Olivier Cant [mailto:<mailto:olivier.cant at exxoss.com>olivier.cant at exxoss.com<mailto:olivier.cant at exxoss.com>]
> *Gesendet:* Donnerstag, 17. September 2015 10:09
> *An:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
> *Betreff:* Re: [Openstack-operators] European Operators
>
> Also very intrested.
>
> Olivier
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>
>     Hi,
>
>     Why Not!
>
>     I think its a great Idea. I want to join.
>
>     Regards..
>
>     Salman
>
>     PhD, Scientific Computing
>     Researcher, IT Department,
>     Uppsala University.
>     Cloud Application Expert,
>     UPPMAX.
>     Visiting Researcher,
>     Helsinki Institute of Physics (HIP).
>     salman.toor at it.uu.se<mailto:salman.toor at it.uu.se> <mailto:salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>>
>     http://www.it.uu.se/katalog/salto690
>
>         On 17 Sep 2015, at 09:52, Matt Jarvis
>         <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
>         <mailto:<mailto:matt.jarvis at datacentred.co.uk>matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>> wrote:
>
>         Hi All
>
>         Don't know how many European folks are on this list, but just
>         wondering if there's any interest in a European Operators meet up ?
>
>         Matt
>
>         --
>
>         Matt Jarvis
>
>         Head of Cloud Computing
>         DataCentred
>
>         Office: (+44)0161 8703985<tel:%28%2B44%290161%208703985>
>         Mobile: (+44)07983 725372<tel:%28%2B44%2907983%20725372>
>
>         Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
>         <mailto:matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>
>
>         Website: http://www.datacentred.co.uk
>         <http://www.datacentred.co.uk/>
>
>
>         DataCentred Limited registered in England and Wales no.
>         05611763_______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>         <mailto:OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>     _______________________________________________
>
>     OpenStack-operators mailing list
>
>     OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>     <mailto:OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
>
> Exxoss <http://www.exxoss.com>
>
> *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22<tel:%2B32%280%29497%2F64.18.22>
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> +32(0)4/341.25.81<tel:%2B32%280%294%2F341.25.81> | Fax: +32(0)4/371.94.06<tel:%2B32%280%294%2F371.94.06>
> Twitter <http://twitter.com/exxossIT>Facebook
> <http://facebook.com/exxoss>Linked In
> <https://www.linkedin.com/company/exxoss>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk

DataCentred Limited registered in England and Wales no. 05611763

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/c5c0b725/attachment.html>

From matt.jarvis at datacentred.co.uk  Thu Sep 17 13:09:19 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Thu, 17 Sep 2015 14:09:19 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
Message-ID: <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>

Don't see why not. Let's see what the overall interest is first :)

On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> Are Europe-based developers/vendors welcome too?  My project (Calico) is
> always keen to understand more about operator interests and requirements,
> so I'd be very happy to be there.
>
>     Neil
>
>
>
> On 17/09/15 13:17, Matt Jarvis wrote:
>
> I'm thinking we'll let this thread run for a day or so and hopefully
> gather a few more interested parties, then take the conversation off-list
> and see what the consensus is from those who've expressed an interest about
> how we might move this forward ?
>
> On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org> wrote:
>
>> Cool :)
>>
>> When are you guys free?
>>
>> On 17/09/15 17:42, Paulo Espada Pereira wrote:
>> >
>> > Very good idea!
>> > Count with me.
>> >
>> >
>> >
>> > *Paulo Pereira*
>> >
>> > Senior Systems Operations Manager, FlowCloud
>> >
>> > Imagination Technologies Limited
>> >
>> > t: +44 (0)1923 260511
>> >
>> > www.imgtec.com < <http://www.imgtec.com/>http://www.imgtec.com/>
>> >
>> >
>> > ------------------------------------------------------------------------
>> > *From:* matthias.britsch at telekom.de [matthias.britsch at telekom.de]
>> > *Sent:* 17 September 2015 10:09
>> > *To:* openstack-operators at lists.openstack.org
>> > *Subject:* Re: [Openstack-operators] European Operators
>> >
>> > I would be interested as well.
>> >
>> > Best regards,       Matthias
>> >
>> > *Von:*Olivier Cant [mailto: <olivier.cant at exxoss.com>
>> olivier.cant at exxoss.com]
>> > *Gesendet:* Donnerstag, 17. September 2015 10:09
>> > *An:* openstack-operators at lists.openstack.org
>> > *Betreff:* Re: [Openstack-operators] European Operators
>> >
>> > Also very intrested.
>> >
>> > Olivier
>> >
>> > On 17/09/15S38 10:02, Salman Toor wrote:
>> >
>> >     Hi,
>> >
>> >     Why Not!
>> >
>> >     I think its a great Idea. I want to join.
>> >
>> >     Regards..
>> >
>> >     Salman
>> >
>> >     PhD, Scientific Computing
>> >     Researcher, IT Department,
>> >     Uppsala University.
>> >     Cloud Application Expert,
>> >     UPPMAX.
>> >     Visiting Researcher,
>> >     Helsinki Institute of Physics (HIP).
>> >     salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
>> >     http://www.it.uu.se/katalog/salto690
>> >
>> >         On 17 Sep 2015, at 09:52, Matt Jarvis
>> >         <matt.jarvis at datacentred.co.uk
>> >         <mailto: <matt.jarvis at datacentred.co.uk>
>> matt.jarvis at datacentred.co.uk>> wrote:
>> >
>> >         Hi All
>> >
>> >         Don't know how many European folks are on this list, but just
>> >         wondering if there's any interest in a European Operators meet
>> up ?
>> >
>> >         Matt
>> >
>> >         --
>> >
>> >         Matt Jarvis
>> >
>> >         Head of Cloud Computing
>> >         DataCentred
>> >
>> >         Office: (+44)0161 8703985
>> >         Mobile: (+44)07983 725372
>> >
>> >         Email: matt.jarvis at datacentred.co.uk
>> >         <mailto:matt.jarvis at datacentred.co.uk>
>> >
>> >         Website: http://www.datacentred.co.uk
>> >         <http://www.datacentred.co.uk/>
>> >
>> >
>> >         DataCentred Limited registered in England and Wales no.
>> >         05611763_______________________________________________
>> >         OpenStack-operators mailing list
>> >         OpenStack-operators at lists.openstack.org
>> >         <mailto:OpenStack-operators at lists.openstack.org>
>> >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>> >
>> >
>> >
>> >     _______________________________________________
>> >
>> >     OpenStack-operators mailing list
>> >
>> >     OpenStack-operators at lists.openstack.org
>> >     <mailto:OpenStack-operators at lists.openstack.org>
>> >
>> >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>> > --
>> >
>> > Exxoss <http://www.exxoss.com>
>> >
>> > *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
>> > *Exxoss, SPRL <http://www.exxoss.com>*
>> > Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
>> > +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
>> > Twitter <http://twitter.com/exxossIT>Facebook
>> > <http://facebook.com/exxoss>Linked In
>> > <https://www.linkedin.com/company/exxoss>
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-operators mailing list
>> > OpenStack-operators at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk
> Website: http://www.datacentred.co.uk
>
> DataCentred Limited registered in England and Wales no. 05611763
>
>
>


-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/08e28f8c/attachment.html>

From klindgren at godaddy.com  Thu Sep 17 14:49:49 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Thu, 17 Sep 2015 14:49:49 +0000
Subject: [Openstack-operators] deploy nova cells with neutron network
In-Reply-To: <CAFKq=acs2Qy7jwhm84U2N44X1-jMxvZ0K2L=NDTpfNu2oDDGxQ@mail.gmail.com>
References: <CAFKq=acs2Qy7jwhm84U2N44X1-jMxvZ0K2L=NDTpfNu2oDDGxQ@mail.gmail.com>
Message-ID: <307EB6A8-1C5D-41DF-9292-4D1539C39FF9@godaddy.com>

Sha,

As you noticed the vif_plug_notification  does not work with cells under the stock confiuguration.  In icehouse/juno we simply ran with vif_plugging_is_fatal is false and set the timeout value to 5 or 10 seconds iirc.

Sam Morrison and made a patch and Mathieu Gagn? help updated it, to fix this.  You can find it here: https://review.openstack.org/#/c/215459/

We are running this patch under kilo without any issues in production.

From experience there are a number of other things that are broken in a cells setup:
1.) Flavor creation
2.) Availability zones
3.) Host aggregates creation for the API Cell
4.) Instance-name (doesn't match between api-cell/child-cell/HV)
5.) vif_plug_notification
6.) metadata with x509-keys (x509 key is updated in api cell and not pushed to child cell, but metadata tries to reference it from the child cell)

We (LDT) are in the process of documenting the patches that we use with Cells and trying to get those upstreamed, we are hoping to have a complete list by Tokyo:
https://etherpad.openstack.org/p/PAO-LDT-cells-patches

NeCTAR maintains a large number of patches that fix the above broken ness in cells.  You can find most of their patches by looking at the commit history on their kilo branch:
https://github.com/NeCTAR-RC/nova/commits/nectar/kilo?page=2 (mainly August 12/13/17/24) - We are running ~10 of those patches in production without any issues.
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Sha Li
Date: Thursday, September 17, 2015 at 1:38 AM
To: "OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>"
Cc: "sam.morrison at unimelb.edu.au<mailto:sam.morrison at unimelb.edu.au>", "belmiro.moreira at cern.ch<mailto:belmiro.moreira at cern.ch>"
Subject: [Openstack-operators] deploy nova cells with neutron network


Hi,

I am try to test the nova cells function.
My test deployment consits of one api-cell node, one child-cell node and one compute node.

api-cell node:  nova-api, nova-cells, nova-cert, nova-condoleauth, nova-novncproxy
child-cell node: nova-cells, nova-conductor, nova-scheduler
compute node: nova-compute

I found most deployment example is using nova-network with nova-cells. I want to use neutron. So I had keystone , glance, and neutron-server, neutron-dhcp, neutron-l3  shared between all cells and deployed all on the api-cell node.

I encounterd similar problem as described in this bug report
https://bugs.launchpad.net/nova/+bug/1348103

When boot a new instance, nova-compute fails to get the network-vif-plugged  notification and get time out waiting for the call back.
But on the neutron server side, it looks like the notification had been successfully sent and get the 200 response code from nova-api server

I had to set
vif_plugging_is_fatal = False
Then the instnace can be spawned normally

I am wondering how people use neutron with nova-cells, is this going to cause any trouble in large scale production deployment.


Cheers,
Sha



--- neutron server log file

2015-08-22 00:20:35.464 16812 DEBUG neutron.notifiers.nova [-] Sending events: [{'status': 'completed', 'tag': u'2839ca4d-b632-4d64-a174-ecfe34a7a746', 'name': 'network-vif-plugged', 'server_uuid': u'092c8bc4-3643-44c0-b79e-ad5caac18b3d'}] send_events /usr/lib/python2.7/site-packages/neutron/notifiers/nova.py:232

2015-08-22 00:20:35.468 16812 INFO urllib3.connectionpool [-] Starting new HTTP connection (1): 192.168.81.221

2015-08-22 00:20:35.548 16812 DEBUG urllib3.connectionpool [-] "POST /v2/338aad513c604880a6a0dcc58b88b905/os-server-external-events HTTP/1.1" 200 183 _make_request /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:357

2015-08-22 00:20:35.550 16812 INFO neutron.notifiers.nova [-] Nova event response: {u'status': u'completed', u'tag': u'2839ca4d-b632-4d64-a174-ecfe34a7a746', u'name': u'network-vif-plugged', u'server_uuid': u'092c8bc4-3643-44c0-b79e-ad5caac18b3d', u'code': 200}




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/a1335e96/attachment.html>

From applyhhj at 163.com  Thu Sep 17 14:55:06 2015
From: applyhhj at 163.com (applyhhj)
Date: Thu, 17 Sep 2015 22:55:06 +0800
Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by
	ICMP!!!!!!!
Message-ID: <4cb52501.8ae3.14fdbcd4e39.Coremail.applyhhj@163.com>

Hi,
I followed The Guidance and tried to configure openvswitch(OVS) service. I first created a bridge br-ex and then added eth2 to the bridge. After that I set the IP of eth2 to 0.0.0.0 and then reboot the system. However br-ex was not up when system launched. So I turned on br-ex manually and then restart the network, but br-ex could not get ip from dhcp server. Thus I used ?dhclient br-ex? to manually acquire IP. Well till then everything worked fine, but in the evening the Network Node was continuously attacked by ICMP package. Iptraf showed the following messages:
 
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on eth2                                                                                                                      
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2                                                                                                
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2                                                                                                 
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx on eth2                                                                                                            
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on eth2                                                                                                                      
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2                                                                                                
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2                                                                                                 
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.x on eth2                                                                                                            
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.63 on eth2                                                                                                                      
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2                                                                                                
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2                                                                                                 
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx on eth2                                                                                                            
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.x on eth2
 
My ip is none of the above ones. The download speed in system monitor went up to 3m/s or even higher to 8m/s. I tried to use iptables and ebtable to filter icmp packages and also set icmp_echo_ignore_all to drop all icmp pacakges. But, unfortunately, nothing works. As long as I deleted eth2 from br-ex or brought down br-ex, the network went back normal.If you have any idea, please help me. I have been stuck here for several days. Thank you very much!!
 
Regards!
hjh


2015-09-17



applyhhj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/840e4e80/attachment.html>

From klindgren at godaddy.com  Thu Sep 17 15:08:23 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Thu, 17 Sep 2015 15:08:23 +0000
Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by
 ICMP!!!!!!!
In-Reply-To: <4cb52501.8ae3.14fdbcd4e39.Coremail.applyhhj@163.com>
References: <4cb52501.8ae3.14fdbcd4e39.Coremail.applyhhj@163.com>
Message-ID: <3B1D2A13-ABD7-49F1-8E86-1C996F44C119@godaddy.com>

For us on boot, we configure the systems init scripts to bring up br-ext and plug in the ethernet (or in our case bond) device into the external bridge.  You should look at your specific distro for guidence here.  Redhat based (RHEL/CentOS/Fedora) use: http://blog.oddbit.com/2014/05/20/fedora-and-ovs-bridge-interfac/ as a guide.

We do not assign any ip address to the interface attached to the bridge.  If you assigned 0.0.0.0 netmask 0.0.0.0 you basically assigned every ip address in ipv4 to your interface, so anything that arps on your network for an ip address, you server is going to respond say "hey that?s me".
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: applyhhj
Date: Thursday, September 17, 2015 at 8:55 AM
To: openstack-operators
Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by ICMP!!!!!!!

Hi,
I followed The Guidance and tried to configure openvswitch(OVS) service. I first created a bridge br-ex and then added eth2 to the bridge. After that I set the IP of eth2 to 0.0.0.0 and then reboot the system. However br-ex was not up when system launched. So I turned on br-ex manually and then restart the network, but br-ex could not get ip from dhcp server. Thus I used ?dhclient br-ex? to manually acquire IP. Well till then everything worked fine, but in the evening the Network Node was continuously attacked by ICMP package. Iptraf showed the following messages:

x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on eth2
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx on eth2
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on eth2
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.x on eth2
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.63 on eth2
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx on eth2
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.x on eth2

My ip is none of the above ones. The download speed in system monitor went up to 3m/s or even higher to 8m/s. I tried to use iptables and ebtable to filter icmp packages and also set icmp_echo_ignore_all to drop all icmp pacakges. But, unfortunately, nothing works. As long as I deleted eth2 from br-ex or brought down br-ex, the network went back normal.If you have any idea, please help me. I have been stuck here for several days. Thank you very much!!

Regards!
hjh


2015-09-17
________________________________
applyhhj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/4b652b86/attachment-0001.html>

From Tim.Bell at cern.ch  Thu Sep 17 16:05:03 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Thu, 17 Sep 2015 16:05:03 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>

We could probably find one or more of the CERN operations team to come along too from the 3 OpenStack clouds we?ve got here.

 

Tim

 

From: Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk] 
Sent: 17 September 2015 15:09
To: Neil Jerram <Neil.Jerram at metaswitch.com>
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] European Operators

 

Don't see why not. Let's see what the overall interest is first :)

 

On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com> > wrote:

Are Europe-based developers/vendors welcome too?  My project (Calico) is always keen to understand more about operator interests and requirements, so I'd be very happy to be there.

    Neil




On 17/09/15 13:17, Matt Jarvis wrote:

I'm thinking we'll let this thread run for a day or so and hopefully gather a few more interested parties, then take the conversation off-list and see what the consensus is from those who've expressed an interest about how we might move this forward ? 

 

On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org <mailto:tom at openstack.org> > wrote:

Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:
>
> Very good idea!
> Count with me.
>
>
>
> *Paulo Pereira*
>
> Senior Systems Operations Manager, FlowCloud
>
> Imagination Technologies Limited
>
> t: +44 (0)1923 260511 <tel:%2B44%20%280%291923%20260511> 
>
> www.imgtec.com <http://www.imgtec.com>  <http://www.imgtec.com/>
>
>
> ------------------------------------------------------------------------
> *From:* matthias.britsch at telekom.de <mailto:matthias.britsch at telekom.de>  [matthias.britsch at telekom.de <mailto:matthias.britsch at telekom.de> ]
> *Sent:* 17 September 2015 10:09
> *To:* openstack-operators at lists.openstack.org <mailto:openstack-operators at lists.openstack.org> 
> *Subject:* Re: [Openstack-operators] European Operators
>
> I would be interested as well.
>
> Best regards,       Matthias
>
> *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com <mailto:olivier.cant at exxoss.com> ]
> *Gesendet:* Donnerstag, 17. September 2015 10:09
> *An:* openstack-operators at lists.openstack.org <mailto:openstack-operators at lists.openstack.org> 
> *Betreff:* Re: [Openstack-operators] European Operators
>
> Also very intrested.
>
> Olivier
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>
>     Hi,
>
>     Why Not!
>
>     I think its a great Idea. I want to join.
>
>     Regards..
>
>     Salman
>
>     PhD, Scientific Computing
>     Researcher, IT Department,
>     Uppsala University.
>     Cloud Application Expert,
>     UPPMAX.
>     Visiting Researcher,
>     Helsinki Institute of Physics (HIP).
>     salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>  <mailto:salman.toor at it.uu.se <mailto:salman.toor at it.uu.se> >
>     http://www.it.uu.se/katalog/salto690
>
>         On 17 Sep 2015, at 09:52, Matt Jarvis
>         <matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk> 
>         <mailto:matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk> >> wrote:
>
>         Hi All
>
>         Don't know how many European folks are on this list, but just
>         wondering if there's any interest in a European Operators meet up ?
>
>         Matt
>
>         --
>
>         Matt Jarvis
>
>         Head of Cloud Computing
>         DataCentred
>
>         Office: (+44)0161 8703985 <tel:%28%2B44%290161%208703985> 
>         Mobile: (+44)07983 725372 <tel:%28%2B44%2907983%20725372> 
>
>         Email: matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk> 
>         <mailto:matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk> >
>
>         Website: http://www.datacentred.co.uk
>         <http://www.datacentred.co.uk/>
>
>
>         DataCentred Limited registered in England and Wales no.
>         05611763_______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
>         <mailto:OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> >
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>     _______________________________________________
>
>     OpenStack-operators mailing list
>
>     OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
>     <mailto:OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> >
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
>
> Exxoss <http://www.exxoss.com>
>
> *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22 <tel:%2B32%280%29497%2F64.18.22> 
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> +32(0)4/341.25.81 <tel:%2B32%280%294%2F341.25.81>  | Fax: +32(0)4/371.94.06 <tel:%2B32%280%294%2F371.94.06> 
> Twitter <http://twitter.com/exxossIT>Facebook
> <http://facebook.com/exxoss>Linked In
> <https://www.linkedin.com/company/exxoss>

>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





 

-- 

Matt Jarvis 

Head of Cloud Computing
DataCentred

Office: (+44)0161 8703985 <tel:%28%2B44%290161%208703985> 
Mobile: (+44)07983 725372 <tel:%28%2B44%2907983%20725372> 

Email: matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk> 

Website: http://www.datacentred.co.uk


DataCentred Limited registered in England and Wales no. 05611763 

 





 

-- 

Matt Jarvis

Head of Cloud Computing
DataCentred

Office: (+44)0161 8703985
Mobile: (+44)07983 725372

Email: matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk> 

Website: http://www.datacentred.co.uk


DataCentred Limited registered in England and Wales no. 05611763

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/98665d29/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/98665d29/attachment.bin>

From mgagne at internap.com  Thu Sep 17 16:11:23 2015
From: mgagne at internap.com (=?UTF-8?Q?Mathieu_Gagn=c3=a9?=)
Date: Thu, 17 Sep 2015 12:11:23 -0400
Subject: [Openstack-operators] Cinder Juno to Kilo upgrade and DB
 encodings
In-Reply-To: <E590B107-F40F-4D40-9C3E-4F6F579E2848@cern.ch>
References: <E590B107-F40F-4D40-9C3E-4F6F579E2848@cern.ch>
Message-ID: <55FAE62B.703@internap.com>

On 2015-09-17 4:06 AM, Arne Wiebalck wrote:
> Hi,
> 
> During our Cinder upgrade on CentOS7 from Juno to Kilo, we ran into this bug:
> https://bugs.launchpad.net/cinder/+bug/1455726
> 
> As there is no fix available from what I see, what we came up with as a ?solution?
> is to explicitly set the character and the collation in all existing tables in the database
> before the upgrade:
> 
> ?>
> alter database cinder CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> SET foreign_key_checks = 0;
> ALTER TABLE `backups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `cgsnapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `consistencygroups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `encryption` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `iscsi_targets` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `migrate_version` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quality_of_service_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quota_classes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quota_usages` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quotas` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `reservations` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `services` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `snapshot_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `snapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `transfers` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_admin_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_glance_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_type_extra_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_types` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volumes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> SET foreign_key_checks = 1;
> <?
> 
> Note that in our case the databases default character set was already utf8 everywhere, while the collation
> was utf8_general_ci. With that conversion the upgrade seems to work fine in our tests.
> 
> Before we retry the upgrade: do if people here think that this a reasonable approach or will this cause
> other issues? Are there alternative approaches?
> 

In our case, we ran this command before upgrading:

ALTER DATABASE cinder CHARACTER SET utf8 COLLATE utf8_general_ci;

See this thread about the same problem:
http://lists.openstack.org/pipermail/openstack/2015-August/013599.html

And the proposed solution:
http://lists.openstack.org/pipermail/openstack/2015-August/013601.html

I suspect that people using Puppet to deploy OpenStack are encountering
this issue due to this change:
https://review.openstack.org/#/c/175991/

We thought this change wouldn't affect anyone but it looks it does.

-- 
Mathieu


From mvanwink at rackspace.com  Thu Sep 17 16:26:52 2015
From: mvanwink at rackspace.com (Matt Van Winkle)
Date: Thu, 17 Sep 2015 16:26:52 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
Message-ID: <D220534B.17AA00%vw@rackspace.com>

We have some Operations folks in London.  Depending on the timing of this, I  might be able to get some of them there as well.  With the next full summit being in North America, it makes a lot of sense to place the next Ops meet up in a different global location.  There has been discussion of this before to increase the chances of Operators being able to attend some portion of the events throughout the year by distributing their locations.

Thanks!
VW

From: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>
Date: Thursday, September 17, 2015 11:05 AM
To: Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>, Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] European Operators

We could probably find one or more of the CERN operations team to come along too from the 3 OpenStack clouds we?ve got here.

Tim

From: Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
Sent: 17 September 2015 15:09
To: Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] European Operators

Don't see why not. Let's see what the overall interest is first :)

On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>> wrote:
Are Europe-based developers/vendors welcome too?  My project (Calico) is always keen to understand more about operator interests and requirements, so I'd be very happy to be there.

    Neil



On 17/09/15 13:17, Matt Jarvis wrote:
I'm thinking we'll let this thread run for a day or so and hopefully gather a few more interested parties, then take the conversation off-list and see what the consensus is from those who've expressed an interest about how we might move this forward ?

On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:
Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:
>
> Very good idea!
> Count with me.
>
>
>
> *Paulo Pereira*
>
> Senior Systems Operations Manager, FlowCloud
>
> Imagination Technologies Limited
>
> t: +44 (0)1923 260511<tel:%2B44%20%280%291923%20260511>
>
> www.imgtec.com<http://www.imgtec.com> <http://www.imgtec.com/>
>
>
> ------------------------------------------------------------------------
> *From:* matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de> [matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de>]
> *Sent:* 17 September 2015 10:09
> *To:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
> *Subject:* Re: [Openstack-operators] European Operators
>
> I would be interested as well.
>
> Best regards,       Matthias
>
> *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com<mailto:olivier.cant at exxoss.com>]
> *Gesendet:* Donnerstag, 17. September 2015 10:09
> *An:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
> *Betreff:* Re: [Openstack-operators] European Operators
>
> Also very intrested.
>
> Olivier
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>
>     Hi,
>
>     Why Not!
>
>     I think its a great Idea. I want to join.
>
>     Regards..
>
>     Salman
>
>     PhD, Scientific Computing
>     Researcher, IT Department,
>     Uppsala University.
>     Cloud Application Expert,
>     UPPMAX.
>     Visiting Researcher,
>     Helsinki Institute of Physics (HIP).
>     salman.toor at it.uu.se<mailto:salman.toor at it.uu.se> <mailto:salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>>
>     http://www.it.uu.se/katalog/salto690
>
>         On 17 Sep 2015, at 09:52, Matt Jarvis
>         <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
>         <mailto:matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>> wrote:
>
>         Hi All
>
>         Don't know how many European folks are on this list, but just
>         wondering if there's any interest in a European Operators meet up ?
>
>         Matt
>
>         --
>
>         Matt Jarvis
>
>         Head of Cloud Computing
>         DataCentred
>
>         Office: (+44)0161 8703985<tel:%28%2B44%290161%208703985>
>         Mobile: (+44)07983 725372<tel:%28%2B44%2907983%20725372>
>
>         Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
>         <mailto:matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>
>
>         Website: http://www.datacentred.co.uk
>         <http://www.datacentred.co.uk/>
>
>
>         DataCentred Limited registered in England and Wales no.
>         05611763_______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>         <mailto:OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>     _______________________________________________
>
>     OpenStack-operators mailing list
>
>     OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>     <mailto:OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
>
> Exxoss <http://www.exxoss.com>
>
> *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22<tel:%2B32%280%29497%2F64.18.22>
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> +32(0)4/341.25.81<tel:%2B32%280%294%2F341.25.81> | Fax: +32(0)4/371.94.06<tel:%2B32%280%294%2F371.94.06>
> Twitter <http://twitter.com/exxossIT>Facebook
> <http://facebook.com/exxoss>Linked In
> <https://www.linkedin.com/company/exxoss>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985<tel:%28%2B44%290161%208703985>
Mobile: (+44)07983 725372<tel:%28%2B44%2907983%20725372>
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk

DataCentred Limited registered in England and Wales no. 05611763




--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk

DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/d636978a/attachment.html>

From apilotti at cloudbasesolutions.com  Thu Sep 17 17:26:13 2015
From: apilotti at cloudbasesolutions.com (Alessandro Pilotti)
Date: Thu, 17 Sep 2015 17:26:13 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <D220534B.17AA00%vw@rackspace.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
Message-ID: <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>

We (Cloudbase Solutions) have our HQ in Europe (Romania), so we?d be happy to take part in this.

Thanks,

Alessandro


On 17 Sep 2015, at 19:26, Matt Van Winkle <mvanwink at rackspace.com<mailto:mvanwink at rackspace.com>> wrote:

We have some Operations folks in London.  Depending on the timing of this, I  might be able to get some of them there as well.  With the next full summit being in North America, it makes a lot of sense to place the next Ops meet up in a different global location.  There has been discussion of this before to increase the chances of Operators being able to attend some portion of the events throughout the year by distributing their locations.

Thanks!
VW

From: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>
Date: Thursday, September 17, 2015 11:05 AM
To: Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>, Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] European Operators

We could probably find one or more of the CERN operations team to come along too from the 3 OpenStack clouds we?ve got here.

Tim

From: Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
Sent: 17 September 2015 15:09
To: Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] European Operators

Don't see why not. Let's see what the overall interest is first :)

On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>> wrote:
Are Europe-based developers/vendors welcome too?  My project (Calico) is always keen to understand more about operator interests and requirements, so I'd be very happy to be there.

    Neil



On 17/09/15 13:17, Matt Jarvis wrote:
I'm thinking we'll let this thread run for a day or so and hopefully gather a few more interested parties, then take the conversation off-list and see what the consensus is from those who've expressed an interest about how we might move this forward ?

On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:
Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:
>
> Very good idea!
> Count with me.
>
>
>
> *Paulo Pereira*
>
> Senior Systems Operations Manager, FlowCloud
>
> Imagination Technologies Limited
>
> t: +44 (0)1923 260511<tel:%2B44%20%280%291923%20260511>
>
> www.imgtec.com<http://www.imgtec.com/> <http://www.imgtec.com/>
>
>
> ------------------------------------------------------------------------
> *From:* matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de> [matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de>]
> *Sent:* 17 September 2015 10:09
> *To:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
> *Subject:* Re: [Openstack-operators] European Operators
>
> I would be interested as well.
>
> Best regards,       Matthias
>
> *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com<mailto:olivier.cant at exxoss.com>]
> *Gesendet:* Donnerstag, 17. September 2015 10:09
> *An:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
> *Betreff:* Re: [Openstack-operators] European Operators
>
> Also very intrested.
>
> Olivier
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>
>     Hi,
>
>     Why Not!
>
>     I think its a great Idea. I want to join.
>
>     Regards..
>
>     Salman
>
>     PhD, Scientific Computing
>     Researcher, IT Department,
>     Uppsala University.
>     Cloud Application Expert,
>     UPPMAX.
>     Visiting Researcher,
>     Helsinki Institute of Physics (HIP).
>     salman.toor at it.uu.se<mailto:salman.toor at it.uu.se> <mailto:salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>>
>     http://www.it.uu.se/katalog/salto690
>
>         On 17 Sep 2015, at 09:52, Matt Jarvis
>         <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
>         <mailto:matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>> wrote:
>
>         Hi All
>
>         Don't know how many European folks are on this list, but just
>         wondering if there's any interest in a European Operators meet up ?
>
>         Matt
>
>         --
>
>         Matt Jarvis
>
>         Head of Cloud Computing
>         DataCentred
>
>         Office: (+44)0161 8703985<tel:%28%2B44%290161%208703985>
>         Mobile: (+44)07983 725372<tel:%28%2B44%2907983%20725372>
>
>         Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
>         <mailto:matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>
>
>         Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>
>         <http://www.datacentred.co.uk/>
>
>
>         DataCentred Limited registered in England and Wales no.
>         05611763_______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>         <mailto:OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>     _______________________________________________
>
>     OpenStack-operators mailing list
>
>     OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
>     <mailto:OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
>
> Exxoss <http://www.exxoss.com<http://www.exxoss.com/>>
>
> *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22<tel:%2B32%280%29497%2F64.18.22>
> *Exxoss, SPRL <http://www.exxoss.com<http://www.exxoss.com/>>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> +32(0)4/341.25.81<tel:%2B32%280%294%2F341.25.81> | Fax: +32(0)4/371.94.06<tel:%2B32%280%294%2F371.94.06>
> Twitter <http://twitter.com/exxossIT>Facebook
> <http://facebook.com/exxoss>Linked In
> <https://www.linkedin.com/company/exxoss>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985<tel:%28%2B44%290161%208703985>
Mobile: (+44)07983 725372<tel:%28%2B44%2907983%20725372>
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>

DataCentred Limited registered in England and Wales no. 05611763




--
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>

DataCentred Limited registered in England and Wales no. 05611763
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/7795f477/attachment.html>

From doc at aedo.net  Thu Sep 17 18:33:24 2015
From: doc at aedo.net (Christopher Aedo)
Date: Thu, 17 Sep 2015 11:33:24 -0700
Subject: [Openstack-operators] [app-catalog] App Catalog IRC meeting minutes
	- 9/17/2015
Message-ID: <CA+odVQF_z2zCdRPnBWm-P98SshsYn-37e34sGyv466q46v0JEw@mail.gmail.com>

We had a nice meeting today and caught up on some of our
plans/intentions for the web site backend.  Long ago we knew that a
basically static site with assets listed in a YAML would not last for
long.  It's already causing issues with respect to versions and
updates, and makes determining when things were added really
cumbersome.

Over the next few weeks we will be transitioning to using flask for
the backend.  Initially we'll just replicate exactly what we have now,
then can slowly start adding the additional features we are planning.
We will also be using many of the same design elements (static files
and javascript) between the Horizon plugin and the website itself.

There's lots more happening here in the months to come at any rate :)
If you ever think about ways to make OpenStack clouds more useful for
the end-users (or are just curious about what we are up to), please
join us on IRC (#openstack-app-catalog).  Thanks!

-Christopher

=================================
#openstack-meeting-3: app-catalog
=================================
Meeting started by docaedo at 17:00:30 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-09-17-17.00.log.html

Meeting summary
---------------
* rollcall  (docaedo, 17:00:50)
* Status updates (docaedo)  (docaedo, 17:02:07)
  * ACTION: docaedo to get SSL cert for app catalog website  (docaedo,
    17:05:52)
* Discuss "new site plans" etherpad (docaedo)  (docaedo, 17:07:48)
  * LINK: https://etherpad.openstack.org/p/app-catalog-v2-backend
    (docaedo, 17:07:55)
  * ACTION: docaedo to request a new repo for common elements shared
    between app-catalog and ui  (docaedo, 17:15:38)
* Open discussion  (docaedo, 17:23:19)
Meeting ended at 17:28:31 UTC.

Action items, by person
-----------------------
* docaedo
  * docaedo to get SSL cert for app catalog website
  * docaedo to request a new repo for common elements shared between
    app-catalog and ui

People present (lines said)
---------------------------
* docaedo (40)
* kfox1111 (29)
* kzaitsev_mb (7)
* pkoros (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4


From mvanwink at rackspace.com  Thu Sep 17 21:27:12 2015
From: mvanwink at rackspace.com (Matt Van Winkle)
Date: Thu, 17 Sep 2015 21:27:12 +0000
Subject: [Openstack-operators] [Large Deployments Team] Monthly Meeting
	Reminder
In-Reply-To: <D22098CC.17AC78%vw@rackspace.com>
References: <D22098CC.17AC78%vw@rackspace.com>
Message-ID: <D2209A45.17AC97%vw@rackspace.com>

Hello all,
The LDT monthly meeting will be at 03:00 UTC, September 18th.  (22:00 Central on the 17th,  13:00 SYD on the 18th).  Sorry for the short notice on the reminder.  Ben heads down on some operational firefighting.  See you all in #openstack-operators!

Thanks!
VW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150917/8b3c8bfb/attachment.html>

From Arne.Wiebalck at cern.ch  Fri Sep 18 07:07:47 2015
From: Arne.Wiebalck at cern.ch (Arne Wiebalck)
Date: Fri, 18 Sep 2015 07:07:47 +0000
Subject: [Openstack-operators] Cinder Juno to Kilo upgrade and DB
 encodings
In-Reply-To: <55FAE62B.703@internap.com>
References: <E590B107-F40F-4D40-9C3E-4F6F579E2848@cern.ch>
 <55FAE62B.703@internap.com>
Message-ID: <B8A0AFCB-3555-4FCF-9275-14BA50F69574@cern.ch>


On 17 Sep 2015, at 18:11, Mathieu Gagn? <mgagne at internap.com<mailto:mgagne at internap.com>> wrote:

On 2015-09-17 4:06 AM, Arne Wiebalck wrote:
Hi,

During our Cinder upgrade on CentOS7 from Juno to Kilo, we ran into this bug:
https://bugs.launchpad.net/cinder/+bug/1455726

As there is no fix available from what I see, what we came up with as a ?solution?
is to explicitly set the character and the collation in all existing tables in the database
before the upgrade:

?>
alter database cinder CHARACTER SET utf8 COLLATE utf8_unicode_ci;
SET foreign_key_checks = 0;
ALTER TABLE `backups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `cgsnapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `consistencygroups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `encryption` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `iscsi_targets` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `migrate_version` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quality_of_service_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quota_classes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quota_usages` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `quotas` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `reservations` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `services` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `snapshot_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `snapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `transfers` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_admin_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_glance_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_type_extra_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volume_types` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE `volumes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
SET foreign_key_checks = 1;
<?

Note that in our case the databases default character set was already utf8 everywhere, while the collation
was utf8_general_ci. With that conversion the upgrade seems to work fine in our tests.

Before we retry the upgrade: do if people here think that this a reasonable approach or will this cause
other issues? Are there alternative approaches?


In our case, we ran this command before upgrading:

ALTER DATABASE cinder CHARACTER SET utf8 COLLATE utf8_general_ci;

See this thread about the same problem:
http://lists.openstack.org/pipermail/openstack/2015-August/013599.html

And the proposed solution:
http://lists.openstack.org/pipermail/openstack/2015-August/013601.html

I suspect that people using Puppet to deploy OpenStack are encountering
this issue due to this change:
https://review.openstack.org/#/c/175991/

We thought this change wouldn't affect anyone but it looks it does.


Thanks a lot for the pointers, Mathieu. I?ll give that a try.

Cheers,
 Arne

?
Arne Wiebalck
CERN IT






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/46d8ee4a/attachment-0001.html>

From matt.jarvis at datacentred.co.uk  Fri Sep 18 07:43:16 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Fri, 18 Sep 2015 08:43:16 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
Message-ID: <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>

So judging from the responses so far, I'd say there is an appetite for
doing this. There are also a lot of folks who don't seem to be on this list
including most of the other European commercial providers so I've started
reaching out to the contacts I have there, and to the other fairly large
scale private operators we know in the UK and Europe. It would be great if
others could do the same around any contacts they have in the European
OpenStack community who may have missed this thread.

So next steps - there's obviously a whole bunch of discussion to be had
around logistics, format, organisation etc. which is probably not best
placed on this list. Perhaps we can get an openstack-euoperators list on
lists.openstack.org set up ? Can someone from the Foundation organise that
for us ? It would also be great to have some input from the US folks to
guide us on format and structure as we try and move this forward.

Does that sound like a sensible first step ?

Matt

On 17 September 2015 at 18:26, Alessandro Pilotti <
apilotti at cloudbasesolutions.com> wrote:

> We (Cloudbase Solutions) have our HQ in Europe (Romania), so we?d be happy
> to take part in this.
>
> Thanks,
>
> Alessandro
>
>
> On 17 Sep 2015, at 19:26, Matt Van Winkle <mvanwink at rackspace.com> wrote:
>
> We have some Operations folks in London.  Depending on the timing of this,
> I  might be able to get some of them there as well.  With the next full
> summit being in North America, it makes a lot of sense to place the next
> Ops meet up in a different global location.  There has been discussion of
> this before to increase the chances of Operators being able to attend some
> portion of the events throughout the year by distributing their locations.
>
> Thanks!
> VW
>
> From: Tim Bell <Tim.Bell at cern.ch>
> Date: Thursday, September 17, 2015 11:05 AM
> To: Matt Jarvis <matt.jarvis at datacentred.co.uk>, Neil Jerram <
> Neil.Jerram at metaswitch.com>
> Cc: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] European Operators
>
> We could probably find one or more of the CERN operations team to come
> along too from the 3 OpenStack clouds we?ve got here.
>
> Tim
>
> *From:* Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk
> <matt.jarvis at datacentred.co.uk>]
> *Sent:* 17 September 2015 15:09
> *To:* Neil Jerram <Neil.Jerram at metaswitch.com>
> *Cc:* openstack-operators at lists.openstack.org
> *Subject:* Re: [Openstack-operators] European Operators
>
> Don't see why not. Let's see what the overall interest is first :)
>
> On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com>
> wrote:
>
> Are Europe-based developers/vendors welcome too?  My project (Calico) is
> always keen to understand more about operator interests and requirements,
> so I'd be very happy to be there.
>
>     Neil
>
>
>
> On 17/09/15 13:17, Matt Jarvis wrote:
>
> I'm thinking we'll let this thread run for a day or so and hopefully
> gather a few more interested parties, then take the conversation off-list
> and see what the consensus is from those who've expressed an interest about
> how we might move this forward ?
>
> On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org> wrote:
>
> Cool :)
>
> When are you guys free?
>
> On 17/09/15 17:42, Paulo Espada Pereira wrote:
> >
> > Very good idea!
> > Count with me.
> >
> >
> >
> > *Paulo Pereira*
> >
> > Senior Systems Operations Manager, FlowCloud
> >
> > Imagination Technologies Limited
> >
> > t: +44 (0)1923 260511
> >
> > www.imgtec.com <http://www.imgtec.com/>
> >
> >
> > ------------------------------------------------------------------------
> > *From:* matthias.britsch at telekom.de [matthias.britsch at telekom.de]
> > *Sent:* 17 September 2015 10:09
> > *To:* openstack-operators at lists.openstack.org
> > *Subject:* Re: [Openstack-operators] European Operators
> >
> > I would be interested as well.
> >
> > Best regards,       Matthias
> >
> > *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
> > *Gesendet:* Donnerstag, 17. September 2015 10:09
> > *An:* openstack-operators at lists.openstack.org
> > *Betreff:* Re: [Openstack-operators] European Operators
> >
> > Also very intrested.
> >
> > Olivier
> >
> > On 17/09/15S38 10:02, Salman Toor wrote:
> >
> >     Hi,
> >
> >     Why Not!
> >
> >     I think its a great Idea. I want to join.
> >
> >     Regards..
> >
> >     Salman
> >
> >     PhD, Scientific Computing
> >     Researcher, IT Department,
> >     Uppsala University.
> >     Cloud Application Expert,
> >     UPPMAX.
> >     Visiting Researcher,
> >     Helsinki Institute of Physics (HIP).
> >     salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
> >     http://www.it.uu.se/katalog/salto690
> >
> >         On 17 Sep 2015, at 09:52, Matt Jarvis
> >         <matt.jarvis at datacentred.co.uk
> >         <mailto:matt.jarvis at datacentred.co.uk>> wrote:
> >
> >         Hi All
> >
> >         Don't know how many European folks are on this list, but just
> >         wondering if there's any interest in a European Operators meet
> up ?
> >
> >         Matt
> >
> >         --
> >
> >         Matt Jarvis
> >
> >         Head of Cloud Computing
> >         DataCentred
> >
> >         Office: (+44)0161 8703985
> >         Mobile: (+44)07983 725372
> >
> >         Email: matt.jarvis at datacentred.co.uk
> >         <mailto:matt.jarvis at datacentred.co.uk>
> >
> >         Website: http://www.datacentred.co.uk
> >         <http://www.datacentred.co.uk/>
> >
> >
> >         DataCentred Limited registered in England and Wales no.
> >         05611763_______________________________________________
> >         OpenStack-operators mailing list
> >         OpenStack-operators at lists.openstack.org
> >         <mailto:OpenStack-operators at lists.openstack.org>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> >
> >     _______________________________________________
> >
> >     OpenStack-operators mailing list
> >
> >     OpenStack-operators at lists.openstack.org
> >     <mailto:OpenStack-operators at lists.openstack.org>
> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > --
> >
> > Exxoss <http://www.exxoss.com>
> >
> > *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
> > *Exxoss, SPRL <http://www.exxoss.com>*
> > Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
> > +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
> > Twitter <http://twitter.com/exxossIT>Facebook
> > <http://facebook.com/exxoss>Linked In
> > <https://www.linkedin.com/company/exxoss>
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk
> Website: http://www.datacentred.co.uk
>
> DataCentred Limited registered in England and Wales no. 05611763
>
>
>
>
>
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk
> Website: http://www.datacentred.co.uk
>
> DataCentred Limited registered in England and Wales no. 05611763
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/479561a0/attachment.html>

From alvise.dorigo at pd.infn.it  Fri Sep 18 07:48:49 2015
From: alvise.dorigo at pd.infn.it (Alvise Dorigo)
Date: Fri, 18 Sep 2015 09:48:49 +0200
Subject: [Openstack-operators] Juno nova-consoleauth stays down
Message-ID: <55FBC1E1.9080007@pd.infn.it>

Hi,
I've installed a Juno controller (which is also a network node). After 
configuring all service, I launched all of them, and I haven't found any 
error in the files /var/log/nova/*.
Despite this, the consoleauth seems to be "down", as reported by "nova 
service-list":

[root at controller-01 nova]# nova service-list|grep console
| 12 | nova-consoleauth | <HIDDEN_HOST> | internal | enabled | down  | 
2015-09-16T12:32:30.000000 | -               |

Its log just shows:

2015-09-18 09:40:06.697 5358 AUDIT nova.service [-] Starting consoleauth 
node (version 2014.2.2-1.el7)
2015-09-18 09:40:07.833 5358 INFO oslo.messaging._drivers.impl_rabbit 
[req-0ed5c7c0-a499-4afd-a005-a28367342be9 ] Connecting to AMQP server on 
x.y.z.w:5672
2015-09-18 09:40:07.855 5358 INFO oslo.messaging._drivers.impl_rabbit 
[req-0ed5c7c0-a499-4afd-a005-a28367342be9 ] Connected to AMQP server on 
x.y.z.w:5672

(the verbose in the nova.conf is already True).

The command "nova get-vnc-console test novnc" hungs for  long, and when 
it wake back:

DEBUG (shell:803) ('Connection aborted.', BadStatusLine("''",))
Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 
800, in main
     OpenStackComputeShell().main(argv)
   File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 
730, in main
     args.func(self.cs, args)
   File "/usr/lib/python2.7/site-packages/novaclient/v1_1/shell.py", 
line 1999, in do_get_vnc_console
     data = server.get_vnc_console(args.console_type)
   File "/usr/lib/python2.7/site-packages/novaclient/v1_1/servers.py", 
line 71, in get_vnc_console
     return self.manager.get_vnc_console(self, console_type)
   File "/usr/lib/python2.7/site-packages/novaclient/v1_1/servers.py", 
line 662, in get_vnc_console
     {'type': console_type})[1]
   File "/usr/lib/python2.7/site-packages/novaclient/v1_1/servers.py", 
line 1240, in _action
     return self.api.client.post(url, body=body)
   File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 
490, in post
     return self._cs_request(url, 'POST', **kwargs)
   File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 
465, in _cs_request
     resp, body = self._time_request(url, method, **kwargs)
   File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 
439, in _time_request
     resp, body = self.request(url, method, **kwargs)
   File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 
410, in request
     **kwargs)
   File "/usr/lib/python2.7/site-packages/requests/api.py", line 50, in 
request
     response = session.request(method=method, url=url, **kwargs)
   File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 
464, in request
     resp = self.send(prep, **send_kwargs)
   File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 
576, in send
     r = adapter.send(request, **kwargs)
   File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 
415, in send
     raise ConnectionError(err, request=request)
ConnectionError: ('Connection aborted.', BadStatusLine("''",))
ERROR (ConnectionError): ('Connection aborted.', BadStatusLine("''",))

Could someone suggest more debugging I could perform ?

thanks,

    Alvise


From gfa at zumbi.com.ar  Fri Sep 18 08:11:09 2015
From: gfa at zumbi.com.ar (gustavo panizzo (gfa))
Date: Fri, 18 Sep 2015 16:11:09 +0800
Subject: [Openstack-operators] European Operators
In-Reply-To: <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
References: <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
Message-ID: <20150918081109.GA18423@io.zumbi.casa>

On Fri, Sep 18, 2015 at 08:43:16 +0100, Matt Jarvis wrote:
> So judging from the responses so far, I'd say there is an appetite for
> doing this. There are also a lot of folks who don't seem to be on this list
> including most of the other European commercial providers so I've started
> reaching out to the contacts I have there, and to the other fairly large
> scale private operators we know in the UK and Europe. It would be great if
> others could do the same around any contacts they have in the European
> OpenStack community who may have missed this thread.
> 
> So next steps - there's obviously a whole bunch of discussion to be had
> around logistics, format, organisation etc. which is probably not best
> placed on this list. Perhaps we can get an openstack-euoperators list on
> lists.openstack.org set up ? Can someone from the Foundation organise that

I'm not an european op, but I just want to say please do not split
the list. just use a tag like [eu], [europe], etc to highlight that the emails
are about european ops meeting organization.

If we split the list we split the knowledge too, people will have to
check the ops and eu-ops list looking for anwsers.

my 0.02?

thanks!
-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa


From Neil.Jerram at metaswitch.com  Fri Sep 18 08:22:02 2015
From: Neil.Jerram at metaswitch.com (Neil Jerram)
Date: Fri, 18 Sep 2015 08:22:02 +0000
Subject: [Openstack-operators] European Operators
References: <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
 <20150918081109.GA18423@io.zumbi.casa>
Message-ID: <SN1PR02MB1695E2B86A30C83964949A1699590@SN1PR02MB1695.namprd02.prod.outlook.com>

On 18/09/15 09:13, gustavo panizzo (gfa) wrote:
> On Fri, Sep 18, 2015 at 08:43:16 +0100, Matt Jarvis wrote:
>> So judging from the responses so far, I'd say there is an appetite for
>> doing this. There are also a lot of folks who don't seem to be on this list
>> including most of the other European commercial providers so I've started
>> reaching out to the contacts I have there, and to the other fairly large
>> scale private operators we know in the UK and Europe. It would be great if
>> others could do the same around any contacts they have in the European
>> OpenStack community who may have missed this thread.
>>
>> So next steps - there's obviously a whole bunch of discussion to be had
>> around logistics, format, organisation etc. which is probably not best
>> placed on this list. Perhaps we can get an openstack-euoperators list on
>> lists.openstack.org set up ? Can someone from the Foundation organise that
> I'm not an european op, but I just want to say please do not split
> the list. just use a tag like [eu], [europe], etc to highlight that the emails
> are about european ops meeting organization.
>
> If we split the list we split the knowledge too, people will have to
> check the ops and eu-ops list looking for anwsers.
>
> my 0.02?
>
> thanks!
+1



From tom at openstack.org  Fri Sep 18 09:55:03 2015
From: tom at openstack.org (Tom Fifield)
Date: Fri, 18 Sep 2015 17:55:03 +0800
Subject: [Openstack-operators] European Operators
In-Reply-To: <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
Message-ID: <55FBDF77.4090909@openstack.org>

Hi,

Foundation person here, at your service :)

Most everything we know about the ops meetups is on the wiki @:

https://wiki.openstack.org/wiki/Operations/Meetups

including some data around those questions around logistics, structure, etc

I'm not a "US folk", but I'd like to help organise, and probably wander 
over if you'll have me :) I've also got colleagues that are pretty good 
at this event planning logistics kind of thing that we can also ask for 
assistance. Maybe also cash :)

As for the ML ... it seems like there is a great deal of interest on 
this mailing list in terms of how these kinds of events are run, based 
on the threads we had a few months back. We could perhaps start here and 
see how we go? I'm thinking that if there is a new ML justified by the 
traffic levels, it might be better to be named around organising ops 
events in general, rather than along geographical lines.


Regards,


Tom


On 18/09/15 15:43, Matt Jarvis wrote:
> So judging from the responses so far, I'd say there is an appetite for
> doing this. There are also a lot of folks who don't seem to be on this
> list including most of the other European commercial providers so I've
> started reaching out to the contacts I have there, and to the other
> fairly large scale private operators we know in the UK and Europe. It
> would be great if others could do the same around any contacts they have
> in the European OpenStack community who may have missed this thread.
>
> So next steps - there's obviously a whole bunch of discussion to be had
> around logistics, format, organisation etc. which is probably not best
> placed on this list. Perhaps we can get an openstack-euoperators list on
> lists.openstack.org <http://lists.openstack.org> set up ? Can someone
> from the Foundation organise that for us ? It would also be great to
> have some input from the US folks to guide us on format and structure as
> we try and move this forward.
>
> Does that sound like a sensible first step ?
>
> Matt
>
> On 17 September 2015 at 18:26, Alessandro Pilotti
> <apilotti at cloudbasesolutions.com
> <mailto:apilotti at cloudbasesolutions.com>> wrote:
>
>     We (Cloudbase Solutions) have our HQ in Europe (Romania), so we?d be
>     happy to take part in this.
>
>     Thanks,
>
>     Alessandro
>
>
>>     On 17 Sep 2015, at 19:26, Matt Van Winkle <mvanwink at rackspace.com
>>     <mailto:mvanwink at rackspace.com>> wrote:
>>
>>     We have some Operations folks in London.  Depending on the timing
>>     of this, I  might be able to get some of them there as well.  With
>>     the next full summit being in North America, it makes a lot of
>>     sense to place the next Ops meet up in a different global
>>     location.  There has been discussion of this before to increase
>>     the chances of Operators being able to attend some portion of the
>>     events throughout the year by distributing their locations.
>>
>>     Thanks!
>>     VW
>>
>>     From:Tim Bell <Tim.Bell at cern.ch <mailto:Tim.Bell at cern.ch>>
>>     Date:Thursday, September 17, 2015 11:05 AM
>>     To:Matt Jarvis <matt.jarvis at datacentred.co.uk
>>     <mailto:matt.jarvis at datacentred.co.uk>>, Neil Jerram
>>     <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>>
>>     Cc:"openstack-operators at lists.openstack.org
>>     <mailto:openstack-operators at lists.openstack.org>"
>>     <openstack-operators at lists.openstack.org
>>     <mailto:openstack-operators at lists.openstack.org>>
>>     Subject:Re: [Openstack-operators] European Operators
>>
>>>     We could probably find one or more of the CERN operations team to
>>>     come along too from the 3 OpenStack clouds we?ve got here.____
>>>     __ __
>>>     Tim____
>>>     __ __
>>>     *From:*Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
>>>     *Sent:*17 September 2015 15:09
>>>     *To:*Neil Jerram <Neil.Jerram at metaswitch.com
>>>     <mailto:Neil.Jerram at metaswitch.com>>
>>>     *Cc:*openstack-operators at lists.openstack.org
>>>     <mailto:openstack-operators at lists.openstack.org>
>>>     *Subject:*Re: [Openstack-operators] European Operators____
>>>     __ __
>>>     Don't see why not. Let's see what the overall interest is first
>>>     :)____
>>>     __ __
>>>     On 17 September 2015 at 13:41, Neil Jerram
>>>     <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>>
>>>     wrote:____
>>>>     Are Europe-based developers/vendors welcome too?  My project
>>>>     (Calico) is always keen to understand more about operator
>>>>     interests and requirements, so I'd be very happy to be there.
>>>>
>>>>         Neil____
>>>>
>>>>
>>>>
>>>>     On 17/09/15 13:17, Matt Jarvis wrote:____
>>>>>     I'm thinking we'll let this thread run for a day or so and
>>>>>     hopefully gather a few more interested parties, then take the
>>>>>     conversation off-list and see what the consensus is from those
>>>>>     who've expressed an interest about how we might move this
>>>>>     forward ? ____
>>>>>     __ __
>>>>>     On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org
>>>>>     <mailto:tom at openstack.org>> wrote:____
>>>>>>     Cool :)
>>>>>>
>>>>>>     When are you guys free?
>>>>>>
>>>>>>     On 17/09/15 17:42, Paulo Espada Pereira wrote:
>>>>>>     >
>>>>>>     > Very good idea!
>>>>>>     > Count with me.
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     > *Paulo Pereira*
>>>>>>     >
>>>>>>     > Senior Systems Operations Manager, FlowCloud
>>>>>>     >
>>>>>>     > Imagination Technologies Limited
>>>>>>     >
>>>>>>     > t:+44 (0)1923 260511 <tel:%2B44%20%280%291923%20260511>
>>>>>>     >
>>>>>>     >www.imgtec.com <http://www.imgtec.com/><http://www.imgtec.com/>
>>>>>>     >
>>>>>>     >
>>>>>>     > ------------------------------------------------------------------------
>>>>>>     > *From:*matthias.britsch at telekom.de
>>>>>>     <mailto:matthias.britsch at telekom.de>[matthias.britsch at telekom.de
>>>>>>     <mailto:matthias.britsch at telekom.de>]
>>>>>>     > *Sent:* 17 September 2015 10:09
>>>>>>     > *To:*openstack-operators at lists.openstack.org
>>>>>>     <mailto:openstack-operators at lists.openstack.org>
>>>>>>     > *Subject:* Re: [Openstack-operators] European Operators
>>>>>>     >
>>>>>>     > I would be interested as well.
>>>>>>     >
>>>>>>     > Best regards,       Matthias
>>>>>>     >
>>>>>>     > *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com <mailto:olivier.cant at exxoss.com>]
>>>>>>     > *Gesendet:* Donnerstag, 17. September 2015 10:09
>>>>>>     > *An:*openstack-operators at lists.openstack.org
>>>>>>     <mailto:openstack-operators at lists.openstack.org>
>>>>>>     > *Betreff:* Re: [Openstack-operators] European Operators
>>>>>>     >
>>>>>>     > Also very intrested.
>>>>>>     >
>>>>>>     > Olivier
>>>>>>     >
>>>>>>     > On 17/09/15S38 10:02, Salman Toor wrote:
>>>>>>     >
>>>>>>     >     Hi,
>>>>>>     >
>>>>>>     >     Why Not!
>>>>>>     >
>>>>>>     >     I think its a great Idea. I want to join.
>>>>>>     >
>>>>>>     >     Regards..
>>>>>>     >
>>>>>>     >     Salman
>>>>>>     >
>>>>>>     >     PhD, Scientific Computing
>>>>>>     >     Researcher, IT Department,
>>>>>>     >     Uppsala University.
>>>>>>     >     Cloud Application Expert,
>>>>>>     >     UPPMAX.
>>>>>>     >     Visiting Researcher,
>>>>>>     >     Helsinki Institute of Physics (HIP).
>>>>>>     >salman.toor at it.uu.se
>>>>>>     <mailto:salman.toor at it.uu.se><mailto:salman.toor at it.uu.se
>>>>>>     <mailto:salman.toor at it.uu.se>>
>>>>>>     >http://www.it.uu.se/katalog/salto690
>>>>>>     >
>>>>>>     >         On 17 Sep 2015, at 09:52, Matt Jarvis
>>>>>>     >         <matt.jarvis at datacentred.co.uk
>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>
>>>>>>     >         <mailto:matt.jarvis at datacentred.co.uk
>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>>> wrote:
>>>>>>     >
>>>>>>     >         Hi All
>>>>>>     >
>>>>>>     >         Don't know how many European folks are on this list, but just
>>>>>>     >         wondering if there's any interest in a European Operators meet up ?
>>>>>>     >
>>>>>>     >         Matt
>>>>>>     >
>>>>>>     >         --
>>>>>>     >
>>>>>>     >         Matt Jarvis
>>>>>>     >
>>>>>>     >         Head of Cloud Computing
>>>>>>     >         DataCentred
>>>>>>     >
>>>>>>     >         Office:(+44)0161 8703985 <tel:%28%2B44%290161%208703985>
>>>>>>     >         Mobile:(+44)07983 725372 <tel:%28%2B44%2907983%20725372>
>>>>>>     >
>>>>>>     >         Email:matt.jarvis at datacentred.co.uk
>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>
>>>>>>     >         <mailto:matt.jarvis at datacentred.co.uk
>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>>
>>>>>>     >
>>>>>>     >         Website:http://www.datacentred.co.uk <http://www.datacentred.co.uk/>
>>>>>>     >         <http://www.datacentred.co.uk/>
>>>>>>     >
>>>>>>     >
>>>>>>     >         DataCentred Limited registered in England and Wales no.
>>>>>>     >         05611763_______________________________________________
>>>>>>     >         OpenStack-operators mailing list
>>>>>>     >OpenStack-operators at lists.openstack.org
>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>     >         <mailto:OpenStack-operators at lists.openstack.org
>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>>
>>>>>>     >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     >     _______________________________________________
>>>>>>     >
>>>>>>     >     OpenStack-operators mailing list
>>>>>>     >
>>>>>>     >OpenStack-operators at lists.openstack.org
>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>     >     <mailto:OpenStack-operators at lists.openstack.org
>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>>
>>>>>>     >
>>>>>>     >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>     >
>>>>>>     > --
>>>>>>     >
>>>>>>     > Exxoss <http://www.exxoss.com <http://www.exxoss.com/>>
>>>>>>     >
>>>>>>     > *Olivier Cant*, CEO |Gsm:+32(0)497/64.18.22 <tel:%2B32%280%29497%2F64.18.22>
>>>>>>     > *Exxoss, SPRL <http://www.exxoss.com <http://www.exxoss.com/>>*
>>>>>>     > Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
>>>>>>     >+32(0)4/341.25.81 <tel:%2B32%280%294%2F341.25.81>|
>>>>>>     Fax:+32(0)4/371.94.06 <tel:%2B32%280%294%2F371.94.06>
>>>>>>     > Twitter <http://twitter.com/exxossIT>Facebook
>>>>>>     > <http://facebook.com/exxoss>Linked In
>>>>>>     > <https://www.linkedin.com/company/exxoss>____
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     > _______________________________________________
>>>>>>     > OpenStack-operators mailing list
>>>>>>     >OpenStack-operators at lists.openstack.org
>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>     >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>     >
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OpenStack-operators mailing list
>>>>>>     OpenStack-operators at lists.openstack.org
>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators____
>>>>>
>>>>>
>>>>>     ____
>>>>>     __ __
>>>>>     --____
>>>>>     Matt Jarvis____
>>>>>     Head of Cloud Computing
>>>>>     DataCentred____
>>>>>     Office:(+44)0161 8703985 <tel:%28%2B44%290161%208703985>
>>>>>     Mobile:(+44)07983 725372 <tel:%28%2B44%2907983%20725372>____
>>>>>     Email:matt.jarvis at datacentred.co.uk
>>>>>     <mailto:matt.jarvis at datacentred.co.uk>____
>>>>>     Website: http://www.datacentred.co.uk
>>>>>     <http://www.datacentred.co.uk/>____
>>>>>
>>>>>     DataCentred Limited registered in England and Wales no.
>>>>>     05611763____
>>>>     __ __
>>>
>>>
>>>     ____
>>>     __ __
>>>     --____
>>>     Matt Jarvis____
>>>     Head of Cloud Computing
>>>     DataCentred____
>>>     Office: (+44)0161 8703985 <tel:%28%2B44%290161%208703985>
>>>     Mobile: (+44)07983 725372 <tel:%28%2B44%2907983%20725372>____
>>>     Email:matt.jarvis at datacentred.co.uk
>>>     <mailto:matt.jarvis at datacentred.co.uk>____
>>>     Website: http://www.datacentred.co.uk
>>>     <http://www.datacentred.co.uk/>____
>>>
>>>     DataCentred Limited registered in England and Wales no. 05611763____
>>     _______________________________________________
>>     OpenStack-operators mailing list
>>     OpenStack-operators at lists.openstack.org
>>     <mailto:OpenStack-operators at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk <mailto:matt.jarvis at datacentred.co.uk>
> Website: http://www.datacentred.co.uk
>
> DataCentred Limited registered in England and Wales no. 05611763
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


From adam.huffman at gmail.com  Fri Sep 18 09:56:24 2015
From: adam.huffman at gmail.com (Adam Huffman)
Date: Fri, 18 Sep 2015 10:56:24 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <D220534B.17AA00%vw@rackspace.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
Message-ID: <CAP5prOidG7KF_SoGrRRo6T79_AjrFkFYXSnJ5pC7LbT+py00Qw@mail.gmail.com>

I would be very keen to attend an Operators' meeting in Europe,
probably along with a lot of other UK academic cloud people.

Cheers,
Adam

On Thu, Sep 17, 2015 at 5:26 PM, Matt Van Winkle <mvanwink at rackspace.com> wrote:
> We have some Operations folks in London.  Depending on the timing of this, I
> might be able to get some of them there as well.  With the next full summit
> being in North America, it makes a lot of sense to place the next Ops meet
> up in a different global location.  There has been discussion of this before
> to increase the chances of Operators being able to attend some portion of
> the events throughout the year by distributing their locations.
>
> Thanks!
> VW
>
> From: Tim Bell <Tim.Bell at cern.ch>
> Date: Thursday, September 17, 2015 11:05 AM
> To: Matt Jarvis <matt.jarvis at datacentred.co.uk>, Neil Jerram
> <Neil.Jerram at metaswitch.com>
> Cc: "openstack-operators at lists.openstack.org"
> <openstack-operators at lists.openstack.org>
>
> Subject: Re: [Openstack-operators] European Operators
>
> We could probably find one or more of the CERN operations team to come along
> too from the 3 OpenStack clouds we?ve got here.
>
>
>
> Tim
>
>
>
> From: Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
> Sent: 17 September 2015 15:09
> To: Neil Jerram <Neil.Jerram at metaswitch.com>
> Cc: openstack-operators at lists.openstack.org
> Subject: Re: [Openstack-operators] European Operators
>
>
>
> Don't see why not. Let's see what the overall interest is first :)
>
>
>
> On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com>
> wrote:
>
> Are Europe-based developers/vendors welcome too?  My project (Calico) is
> always keen to understand more about operator interests and requirements, so
> I'd be very happy to be there.
>
>     Neil
>
>
>
>
> On 17/09/15 13:17, Matt Jarvis wrote:
>
> I'm thinking we'll let this thread run for a day or so and hopefully gather
> a few more interested parties, then take the conversation off-list and see
> what the consensus is from those who've expressed an interest about how we
> might move this forward ?
>
>
>
> On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org> wrote:
>
> Cool :)
>
> When are you guys free?
>
> On 17/09/15 17:42, Paulo Espada Pereira wrote:
>>
>> Very good idea!
>> Count with me.
>>
>>
>>
>> *Paulo Pereira*
>>
>> Senior Systems Operations Manager, FlowCloud
>>
>> Imagination Technologies Limited
>>
>> t: +44 (0)1923 260511
>>
>> www.imgtec.com <http://www.imgtec.com/>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* matthias.britsch at telekom.de [matthias.britsch at telekom.de]
>> *Sent:* 17 September 2015 10:09
>> *To:* openstack-operators at lists.openstack.org
>> *Subject:* Re: [Openstack-operators] European Operators
>>
>> I would be interested as well.
>>
>> Best regards,       Matthias
>>
>> *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
>> *Gesendet:* Donnerstag, 17. September 2015 10:09
>> *An:* openstack-operators at lists.openstack.org
>> *Betreff:* Re: [Openstack-operators] European Operators
>>
>> Also very intrested.
>>
>> Olivier
>>
>> On 17/09/15S38 10:02, Salman Toor wrote:
>>
>>     Hi,
>>
>>     Why Not!
>>
>>     I think its a great Idea. I want to join.
>>
>>     Regards..
>>
>>     Salman
>>
>>     PhD, Scientific Computing
>>     Researcher, IT Department,
>>     Uppsala University.
>>     Cloud Application Expert,
>>     UPPMAX.
>>     Visiting Researcher,
>>     Helsinki Institute of Physics (HIP).
>>     salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
>>     http://www.it.uu.se/katalog/salto690
>>
>>         On 17 Sep 2015, at 09:52, Matt Jarvis
>>         <matt.jarvis at datacentred.co.uk
>>         <mailto:matt.jarvis at datacentred.co.uk>> wrote:
>>
>>         Hi All
>>
>>         Don't know how many European folks are on this list, but just
>>         wondering if there's any interest in a European Operators meet up
>> ?
>>
>>         Matt
>>
>>         --
>>
>>         Matt Jarvis
>>
>>         Head of Cloud Computing
>>         DataCentred
>>
>>         Office: (+44)0161 8703985
>>         Mobile: (+44)07983 725372
>>
>>         Email: matt.jarvis at datacentred.co.uk
>>         <mailto:matt.jarvis at datacentred.co.uk>
>>
>>         Website: http://www.datacentred.co.uk
>>         <http://www.datacentred.co.uk/>
>>
>>
>>         DataCentred Limited registered in England and Wales no.
>>         05611763_______________________________________________
>>         OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     OpenStack-operators mailing list
>>
>>     OpenStack-operators at lists.openstack.org
>>     <mailto:OpenStack-operators at lists.openstack.org>
>>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> --
>>
>> Exxoss <http://www.exxoss.com>
>>
>> *Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
>> *Exxoss, SPRL <http://www.exxoss.com>*
>> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
>> +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
>> Twitter <http://twitter.com/exxossIT>Facebook
>> <http://facebook.com/exxoss>Linked In
>> <https://www.linkedin.com/company/exxoss>
>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>
> --
>
> Matt Jarvis
>
> Head of Cloud Computing
> DataCentred
>
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
>
> Email: matt.jarvis at datacentred.co.uk
>
> Website: http://www.datacentred.co.uk
>
>
> DataCentred Limited registered in England and Wales no. 05611763
>
>
>
>
>
>
>
> --
>
> Matt Jarvis
>
> Head of Cloud Computing
> DataCentred
>
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
>
> Email: matt.jarvis at datacentred.co.uk
>
> Website: http://www.datacentred.co.uk
>
>
> DataCentred Limited registered in England and Wales no. 05611763
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


From matt.jarvis at datacentred.co.uk  Fri Sep 18 10:47:41 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Fri, 18 Sep 2015 11:47:41 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FBDF77.4090909@openstack.org>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
 <55FBDF77.4090909@openstack.org>
Message-ID: <CACpXDz9sHGaOkhDsjyCb-=EoOkp+ViTaBR26s6jXrEWeHzY4JA@mail.gmail.com>

Thanks for that Tom - more than welcome ! I'll take a look at the wiki, and
try to get an etherpad up where we can start doing some initial planning.
It sounds like tags on this ML are the way to go.

On 18 September 2015 at 10:55, Tom Fifield <tom at openstack.org> wrote:

> Hi,
>
> Foundation person here, at your service :)
>
> Most everything we know about the ops meetups is on the wiki @:
>
> https://wiki.openstack.org/wiki/Operations/Meetups
>
> including some data around those questions around logistics, structure, etc
>
> I'm not a "US folk", but I'd like to help organise, and probably wander
> over if you'll have me :) I've also got colleagues that are pretty good at
> this event planning logistics kind of thing that we can also ask for
> assistance. Maybe also cash :)
>
> As for the ML ... it seems like there is a great deal of interest on this
> mailing list in terms of how these kinds of events are run, based on the
> threads we had a few months back. We could perhaps start here and see how
> we go? I'm thinking that if there is a new ML justified by the traffic
> levels, it might be better to be named around organising ops events in
> general, rather than along geographical lines.
>
>
> Regards,
>
>
> Tom
>
>
> On 18/09/15 15:43, Matt Jarvis wrote:
>
>> So judging from the responses so far, I'd say there is an appetite for
>> doing this. There are also a lot of folks who don't seem to be on this
>> list including most of the other European commercial providers so I've
>> started reaching out to the contacts I have there, and to the other
>> fairly large scale private operators we know in the UK and Europe. It
>> would be great if others could do the same around any contacts they have
>> in the European OpenStack community who may have missed this thread.
>>
>> So next steps - there's obviously a whole bunch of discussion to be had
>> around logistics, format, organisation etc. which is probably not best
>> placed on this list. Perhaps we can get an openstack-euoperators list on
>> lists.openstack.org <http://lists.openstack.org> set up ? Can someone
>> from the Foundation organise that for us ? It would also be great to
>> have some input from the US folks to guide us on format and structure as
>> we try and move this forward.
>>
>> Does that sound like a sensible first step ?
>>
>> Matt
>>
>> On 17 September 2015 at 18:26, Alessandro Pilotti
>> <apilotti at cloudbasesolutions.com
>> <mailto:apilotti at cloudbasesolutions.com>> wrote:
>>
>>     We (Cloudbase Solutions) have our HQ in Europe (Romania), so we?d be
>>     happy to take part in this.
>>
>>     Thanks,
>>
>>     Alessandro
>>
>>
>>     On 17 Sep 2015, at 19:26, Matt Van Winkle <mvanwink at rackspace.com
>>>     <mailto:mvanwink at rackspace.com>> wrote:
>>>
>>>     We have some Operations folks in London.  Depending on the timing
>>>     of this, I  might be able to get some of them there as well.  With
>>>     the next full summit being in North America, it makes a lot of
>>>     sense to place the next Ops meet up in a different global
>>>     location.  There has been discussion of this before to increase
>>>     the chances of Operators being able to attend some portion of the
>>>     events throughout the year by distributing their locations.
>>>
>>>     Thanks!
>>>     VW
>>>
>>>     From:Tim Bell <Tim.Bell at cern.ch <mailto:Tim.Bell at cern.ch>>
>>>     Date:Thursday, September 17, 2015 11:05 AM
>>>     To:Matt Jarvis <matt.jarvis at datacentred.co.uk
>>>     <mailto:matt.jarvis at datacentred.co.uk>>, Neil Jerram
>>>     <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>>
>>>     Cc:"openstack-operators at lists.openstack.org
>>>     <mailto:openstack-operators at lists.openstack.org>"
>>>     <openstack-operators at lists.openstack.org
>>>     <mailto:openstack-operators at lists.openstack.org>>
>>>     Subject:Re: [Openstack-operators] European Operators
>>>
>>>     We could probably find one or more of the CERN operations team to
>>>>     come along too from the 3 OpenStack clouds we?ve got here.____
>>>>     __ __
>>>>     Tim____
>>>>     __ __
>>>>     *From:*Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
>>>>     *Sent:*17 September 2015 15:09
>>>>     *To:*Neil Jerram <Neil.Jerram at metaswitch.com
>>>>     <mailto:Neil.Jerram at metaswitch.com>>
>>>>     *Cc:*openstack-operators at lists.openstack.org
>>>>     <mailto:openstack-operators at lists.openstack.org>
>>>>     *Subject:*Re: [Openstack-operators] European Operators____
>>>>     __ __
>>>>     Don't see why not. Let's see what the overall interest is first
>>>>     :)____
>>>>     __ __
>>>>     On 17 September 2015 at 13:41, Neil Jerram
>>>>     <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>>
>>>>     wrote:____
>>>>
>>>>>     Are Europe-based developers/vendors welcome too?  My project
>>>>>     (Calico) is always keen to understand more about operator
>>>>>     interests and requirements, so I'd be very happy to be there.
>>>>>
>>>>>         Neil____
>>>>>
>>>>>
>>>>>
>>>>>     On 17/09/15 13:17, Matt Jarvis wrote:____
>>>>>
>>>>>>     I'm thinking we'll let this thread run for a day or so and
>>>>>>     hopefully gather a few more interested parties, then take the
>>>>>>     conversation off-list and see what the consensus is from those
>>>>>>     who've expressed an interest about how we might move this
>>>>>>     forward ? ____
>>>>>>     __ __
>>>>>>     On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org
>>>>>>     <mailto:tom at openstack.org>> wrote:____
>>>>>>
>>>>>>>     Cool :)
>>>>>>>
>>>>>>>     When are you guys free?
>>>>>>>
>>>>>>>     On 17/09/15 17:42, Paulo Espada Pereira wrote:
>>>>>>>     >
>>>>>>>     > Very good idea!
>>>>>>>     > Count with me.
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>>     > *Paulo Pereira*
>>>>>>>     >
>>>>>>>     > Senior Systems Operations Manager, FlowCloud
>>>>>>>     >
>>>>>>>     > Imagination Technologies Limited
>>>>>>>     >
>>>>>>>     > t:+44 (0)1923 260511 <tel:%2B44%20%280%291923%20260511>
>>>>>>>     >
>>>>>>>     >www.imgtec.com <http://www.imgtec.com/><http://www.imgtec.com/>
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>> ------------------------------------------------------------------------
>>>>>>>     > *From:*matthias.britsch at telekom.de
>>>>>>>     <mailto:matthias.britsch at telekom.de>[matthias.britsch at telekom.de
>>>>>>>     <mailto:matthias.britsch at telekom.de>]
>>>>>>>     > *Sent:* 17 September 2015 10:09
>>>>>>>     > *To:*openstack-operators at lists.openstack.org
>>>>>>>     <mailto:openstack-operators at lists.openstack.org>
>>>>>>>     > *Subject:* Re: [Openstack-operators] European Operators
>>>>>>>     >
>>>>>>>     > I would be interested as well.
>>>>>>>     >
>>>>>>>     > Best regards,       Matthias
>>>>>>>     >
>>>>>>>     > *Von:*Olivier Cant [mailto:olivier.cant at exxoss.com <mailto:
>>>>>>> olivier.cant at exxoss.com>]
>>>>>>>     > *Gesendet:* Donnerstag, 17. September 2015 10:09
>>>>>>>     > *An:*openstack-operators at lists.openstack.org
>>>>>>>     <mailto:openstack-operators at lists.openstack.org>
>>>>>>>     > *Betreff:* Re: [Openstack-operators] European Operators
>>>>>>>     >
>>>>>>>     > Also very intrested.
>>>>>>>     >
>>>>>>>     > Olivier
>>>>>>>     >
>>>>>>>     > On 17/09/15S38 10:02, Salman Toor wrote:
>>>>>>>     >
>>>>>>>     >     Hi,
>>>>>>>     >
>>>>>>>     >     Why Not!
>>>>>>>     >
>>>>>>>     >     I think its a great Idea. I want to join.
>>>>>>>     >
>>>>>>>     >     Regards..
>>>>>>>     >
>>>>>>>     >     Salman
>>>>>>>     >
>>>>>>>     >     PhD, Scientific Computing
>>>>>>>     >     Researcher, IT Department,
>>>>>>>     >     Uppsala University.
>>>>>>>     >     Cloud Application Expert,
>>>>>>>     >     UPPMAX.
>>>>>>>     >     Visiting Researcher,
>>>>>>>     >     Helsinki Institute of Physics (HIP).
>>>>>>>     >salman.toor at it.uu.se
>>>>>>>     <mailto:salman.toor at it.uu.se><mailto:salman.toor at it.uu.se
>>>>>>>     <mailto:salman.toor at it.uu.se>>
>>>>>>>     >http://www.it.uu.se/katalog/salto690
>>>>>>>     >
>>>>>>>     >         On 17 Sep 2015, at 09:52, Matt Jarvis
>>>>>>>     >         <matt.jarvis at datacentred.co.uk
>>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>
>>>>>>>     >         <mailto:matt.jarvis at datacentred.co.uk
>>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>>> wrote:
>>>>>>>     >
>>>>>>>     >         Hi All
>>>>>>>     >
>>>>>>>     >         Don't know how many European folks are on this list,
>>>>>>> but just
>>>>>>>     >         wondering if there's any interest in a European
>>>>>>> Operators meet up ?
>>>>>>>     >
>>>>>>>     >         Matt
>>>>>>>     >
>>>>>>>     >         --
>>>>>>>     >
>>>>>>>     >         Matt Jarvis
>>>>>>>     >
>>>>>>>     >         Head of Cloud Computing
>>>>>>>     >         DataCentred
>>>>>>>     >
>>>>>>>     >         Office:(+44)0161 8703985
>>>>>>> <tel:%28%2B44%290161%208703985>
>>>>>>>     >         Mobile:(+44)07983 725372
>>>>>>> <tel:%28%2B44%2907983%20725372>
>>>>>>>     >
>>>>>>>     >         Email:matt.jarvis at datacentred.co.uk
>>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>
>>>>>>>     >         <mailto:matt.jarvis at datacentred.co.uk
>>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>>
>>>>>>>     >
>>>>>>>     >         Website:http://www.datacentred.co.uk <
>>>>>>> http://www.datacentred.co.uk/>
>>>>>>>     >         <http://www.datacentred.co.uk/>
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >         DataCentred Limited registered in England and Wales no.
>>>>>>>     >         05611763_______________________________________________
>>>>>>>     >         OpenStack-operators mailing list
>>>>>>>     >OpenStack-operators at lists.openstack.org
>>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>>     >         <mailto:OpenStack-operators at lists.openstack.org
>>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>>
>>>>>>>     >
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >     _______________________________________________
>>>>>>>     >
>>>>>>>     >     OpenStack-operators mailing list
>>>>>>>     >
>>>>>>>     >OpenStack-operators at lists.openstack.org
>>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>>     >     <mailto:OpenStack-operators at lists.openstack.org
>>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>>
>>>>>>>     >
>>>>>>>     >
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>>     >
>>>>>>>     > --
>>>>>>>     >
>>>>>>>     > Exxoss <http://www.exxoss.com <http://www.exxoss.com/>>
>>>>>>>     >
>>>>>>>     > *Olivier Cant*, CEO |Gsm:+32(0)497/64.18.22
>>>>>>> <tel:%2B32%280%29497%2F64.18.22>
>>>>>>>     > *Exxoss, SPRL <http://www.exxoss.com <http://www.exxoss.com/
>>>>>>> >>*
>>>>>>>     > Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
>>>>>>>     >+32(0)4/341.25.81 <tel:%2B32%280%294%2F341.25.81>|
>>>>>>>     Fax:+32(0)4/371.94.06 <tel:%2B32%280%294%2F371.94.06>
>>>>>>>     > Twitter <http://twitter.com/exxossIT>Facebook
>>>>>>>     > <http://facebook.com/exxoss>Linked In
>>>>>>>     > <https://www.linkedin.com/company/exxoss>____
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>>     > _______________________________________________
>>>>>>>     > OpenStack-operators mailing list
>>>>>>>     >OpenStack-operators at lists.openstack.org
>>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>>     >
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>>     >
>>>>>>>
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     OpenStack-operators mailing list
>>>>>>>     OpenStack-operators at lists.openstack.org
>>>>>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>>>>>
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators____
>>>>>>>
>>>>>>
>>>>>>
>>>>>>     ____
>>>>>>     __ __
>>>>>>     --____
>>>>>>     Matt Jarvis____
>>>>>>     Head of Cloud Computing
>>>>>>     DataCentred____
>>>>>>     Office:(+44)0161 8703985 <tel:%28%2B44%290161%208703985>
>>>>>>     Mobile:(+44)07983 725372 <tel:%28%2B44%2907983%20725372>____
>>>>>>     Email:matt.jarvis at datacentred.co.uk
>>>>>>     <mailto:matt.jarvis at datacentred.co.uk>____
>>>>>>     Website: http://www.datacentred.co.uk
>>>>>>     <http://www.datacentred.co.uk/>____
>>>>>>
>>>>>>     DataCentred Limited registered in England and Wales no.
>>>>>>     05611763____
>>>>>>
>>>>>     __ __
>>>>>
>>>>
>>>>
>>>>     ____
>>>>     __ __
>>>>     --____
>>>>     Matt Jarvis____
>>>>     Head of Cloud Computing
>>>>     DataCentred____
>>>>     Office: (+44)0161 8703985 <tel:%28%2B44%290161%208703985>
>>>>     Mobile: (+44)07983 725372 <tel:%28%2B44%2907983%20725372>____
>>>>     Email:matt.jarvis at datacentred.co.uk
>>>>     <mailto:matt.jarvis at datacentred.co.uk>____
>>>>     Website: http://www.datacentred.co.uk
>>>>     <http://www.datacentred.co.uk/>____
>>>>
>>>>     DataCentred Limited registered in England and Wales no. 05611763____
>>>>
>>>     _______________________________________________
>>>     OpenStack-operators mailing list
>>>     OpenStack-operators at lists.openstack.org
>>>     <mailto:OpenStack-operators at lists.openstack.org>
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>>     _______________________________________________
>>     OpenStack-operators mailing list
>>     OpenStack-operators at lists.openstack.org
>>     <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>> --
>> Matt Jarvis
>> Head of Cloud Computing
>> DataCentred
>> Office: (+44)0161 8703985
>> Mobile: (+44)07983 725372
>> Email: matt.jarvis at datacentred.co.uk <mailto:
>> matt.jarvis at datacentred.co.uk>
>> Website: http://www.datacentred.co.uk
>>
>> DataCentred Limited registered in England and Wales no. 05611763
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/89f2ef41/attachment.html>

From salman.toor at it.uu.se  Fri Sep 18 12:24:11 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Fri, 18 Sep 2015 12:24:11 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <CAP5prOidG7KF_SoGrRRo6T79_AjrFkFYXSnJ5pC7LbT+py00Qw@mail.gmail.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <CAP5prOidG7KF_SoGrRRo6T79_AjrFkFYXSnJ5pC7LbT+py00Qw@mail.gmail.com>
Message-ID: <F6CB752F-5A06-4F00-9844-C31E7FC15D73@it.uu.se>

Hi everyone,

From the platform of SNIC (Swedish National Infrastructure for Computing), we are in the process of building a national level Cloud facility for research and academic activities in Sweden.

I can contribute our experiences and requirements from SNIC side.

Regards..
Salman.

PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 18 Sep 2015, at 11:56, Adam Huffman <adam.huffman at gmail.com<mailto:adam.huffman at gmail.com>> wrote:

I would be very keen to attend an Operators' meeting in Europe,
probably along with a lot of other UK academic cloud people.

Cheers,
Adam

On Thu, Sep 17, 2015 at 5:26 PM, Matt Van Winkle <mvanwink at rackspace.com<mailto:mvanwink at rackspace.com>> wrote:
We have some Operations folks in London.  Depending on the timing of this, I
might be able to get some of them there as well.  With the next full summit
being in North America, it makes a lot of sense to place the next Ops meet
up in a different global location.  There has been discussion of this before
to increase the chances of Operators being able to attend some portion of
the events throughout the year by distributing their locations.

Thanks!
VW

From: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>
Date: Thursday, September 17, 2015 11:05 AM
To: Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>, Neil Jerram
<Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
<openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>

Subject: Re: [Openstack-operators] European Operators

We could probably find one or more of the CERN operations team to come along
too from the 3 OpenStack clouds we?ve got here.



Tim



From: Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
Sent: 17 September 2015 15:09
To: Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] European Operators



Don't see why not. Let's see what the overall interest is first :)



On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
wrote:

Are Europe-based developers/vendors welcome too?  My project (Calico) is
always keen to understand more about operator interests and requirements, so
I'd be very happy to be there.

   Neil




On 17/09/15 13:17, Matt Jarvis wrote:

I'm thinking we'll let this thread run for a day or so and hopefully gather
a few more interested parties, then take the conversation off-list and see
what the consensus is from those who've expressed an interest about how we
might move this forward ?



On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:

Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:

Very good idea!
Count with me.



*Paulo Pereira*

Senior Systems Operations Manager, FlowCloud

Imagination Technologies Limited

t: +44 (0)1923 260511

www.imgtec.com<http://www.imgtec.com> <http://www.imgtec.com/>


------------------------------------------------------------------------
*From:* matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de> [matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de>]
*Sent:* 17 September 2015 10:09
*To:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
*Subject:* Re: [Openstack-operators] European Operators

I would be interested as well.

Best regards,       Matthias

*Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
*Gesendet:* Donnerstag, 17. September 2015 10:09
*An:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
*Betreff:* Re: [Openstack-operators] European Operators

Also very intrested.

Olivier

On 17/09/15S38 10:02, Salman Toor wrote:

   Hi,

   Why Not!

   I think its a great Idea. I want to join.

   Regards..

   Salman

   PhD, Scientific Computing
   Researcher, IT Department,
   Uppsala University.
   Cloud Application Expert,
   UPPMAX.
   Visiting Researcher,
   Helsinki Institute of Physics (HIP).
   salman.toor at it.uu.se<mailto:salman.toor at it.uu.se> <mailto:salman.toor at it.uu.se>
   http://www.it.uu.se/katalog/salto690

       On 17 Sep 2015, at 09:52, Matt Jarvis
       <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
       <mailto:matt.jarvis at datacentred.co.uk>> wrote:

       Hi All

       Don't know how many European folks are on this list, but just
       wondering if there's any interest in a European Operators meet up
?

       Matt

       --

       Matt Jarvis

       Head of Cloud Computing
       DataCentred

       Office: (+44)0161 8703985
       Mobile: (+44)07983 725372

       Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
       <mailto:matt.jarvis at datacentred.co.uk>

       Website: http://www.datacentred.co.uk
       <http://www.datacentred.co.uk/>


       DataCentred Limited registered in England and Wales no.
       05611763_______________________________________________
       OpenStack-operators mailing list
       OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
       <mailto:OpenStack-operators at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




   _______________________________________________

   OpenStack-operators mailing list

   OpenStack-operators at lists.openstack.org
   <mailto:OpenStack-operators at lists.openstack.org>


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--

Exxoss <http://www.exxoss.com>

*Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
*Exxoss, SPRL <http://www.exxoss.com>*
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
+32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
Twitter <http://twitter.com/exxossIT>Facebook
<http://facebook.com/exxoss>Linked In
<https://www.linkedin.com/company/exxoss>




_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





--

Matt Jarvis

Head of Cloud Computing
DataCentred

Office: (+44)0161 8703985
Mobile: (+44)07983 725372

Email: matt.jarvis at datacentred.co.uk

Website: http://www.datacentred.co.uk


DataCentred Limited registered in England and Wales no. 05611763







--

Matt Jarvis

Head of Cloud Computing
DataCentred

Office: (+44)0161 8703985
Mobile: (+44)07983 725372

Email: matt.jarvis at datacentred.co.uk

Website: http://www.datacentred.co.uk


DataCentred Limited registered in England and Wales no. 05611763


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


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/e31c7056/attachment.html>

From mcunietti at enter.it  Fri Sep 18 13:15:01 2015
From: mcunietti at enter.it (Mariano Cunietti)
Date: Fri, 18 Sep 2015 13:15:01 +0000
Subject: [Openstack-operators] European Operators
In-Reply-To: <F6CB752F-5A06-4F00-9844-C31E7FC15D73@it.uu.se>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <CAP5prOidG7KF_SoGrRRo6T79_AjrFkFYXSnJ5pC7LbT+py00Qw@mail.gmail.com>
 <F6CB752F-5A06-4F00-9844-C31E7FC15D73@it.uu.se>
Message-ID: <E4676B85-E18A-45A6-818B-F031D5D64C96@enter.it>

Ciao Matt, nice to meet you again!
Italians with ECS, www.entercloudsuite.com<http://www.entercloudsuite.com> onboard!

FYI, together with Numergy (Alexandre Steiner is CC?ed here), KPN, Gigas, Belgacom/Proximus, Portugal Telecom we are participating in the CTA, Cloud Team Alliance<http://www.cloudteamalliance.com/>, and we are already setting up meetings with the main Openstack (and not) players in Europe.
The goal is not only to set up a technology-driven group, but to create an ecosystem to work with and to carve out a real european offer. Which may be: not centralized, but distributed and respectful of #diversity (and hopefully as less bureaucratic as possible?). We think this could be a very interesting approach and very peculiar, compared to the "big guys?. We could end up with something that is a real singularity in the cloud scene.
Needless to say, Openstack would play a great role in building this kind of infrastructure.  Obviously, federation is something we need to address also on a technology and/or architecture standpoint.

I suggest join the efforts and set a date for a first meeting al together, and know each other. How about it? BTW, Tokyo may be an option: I am going.
The sooner we book agendas and flights, the better.

Ciao

Mariano

--------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

On 18 Sep 2015, at 14:24, Salman Toor <salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>> wrote:

Hi everyone,

From the platform of SNIC (Swedish National Infrastructure for Computing), we are in the process of building a national level Cloud facility for research and academic activities in Sweden.

I can contribute our experiences and requirements from SNIC side.

Regards..
Salman.

PhD, Scientific Computing
Researcher, IT Department,
Uppsala University.
Senior Cloud Architect,
SNIC.
Cloud Application Expert,
UPPMAX.
Visiting Researcher,
Helsinki Institute of Physics (HIP).
salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>
http://www.it.uu.se/katalog/salto690

On 18 Sep 2015, at 11:56, Adam Huffman <adam.huffman at gmail.com<mailto:adam.huffman at gmail.com>> wrote:

I would be very keen to attend an Operators' meeting in Europe,
probably along with a lot of other UK academic cloud people.

Cheers,
Adam

On Thu, Sep 17, 2015 at 5:26 PM, Matt Van Winkle <mvanwink at rackspace.com<mailto:mvanwink at rackspace.com>> wrote:
We have some Operations folks in London.  Depending on the timing of this, I
might be able to get some of them there as well.  With the next full summit
being in North America, it makes a lot of sense to place the next Ops meet
up in a different global location.  There has been discussion of this before
to increase the chances of Operators being able to attend some portion of
the events throughout the year by distributing their locations.

Thanks!
VW

From: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>
Date: Thursday, September 17, 2015 11:05 AM
To: Matt Jarvis <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>>, Neil Jerram
<Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
<openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>

Subject: Re: [Openstack-operators] European Operators

We could probably find one or more of the CERN operations team to come along
too from the 3 OpenStack clouds we?ve got here.



Tim



From: Matt Jarvis [mailto:matt.jarvis at datacentred.co.uk]
Sent: 17 September 2015 15:09
To: Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
Cc: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] European Operators



Don't see why not. Let's see what the overall interest is first :)



On 17 September 2015 at 13:41, Neil Jerram <Neil.Jerram at metaswitch.com<mailto:Neil.Jerram at metaswitch.com>>
wrote:

Are Europe-based developers/vendors welcome too?  My project (Calico) is
always keen to understand more about operator interests and requirements, so
I'd be very happy to be there.

   Neil




On 17/09/15 13:17, Matt Jarvis wrote:

I'm thinking we'll let this thread run for a day or so and hopefully gather
a few more interested parties, then take the conversation off-list and see
what the consensus is from those who've expressed an interest about how we
might move this forward ?



On 17 September 2015 at 13:04, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:

Cool :)

When are you guys free?

On 17/09/15 17:42, Paulo Espada Pereira wrote:

Very good idea!
Count with me.



*Paulo Pereira*

Senior Systems Operations Manager, FlowCloud

Imagination Technologies Limited

t: +44 (0)1923 260511

www.imgtec.com<http://www.imgtec.com/> <http://www.imgtec.com/>


------------------------------------------------------------------------
*From:* matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de> [matthias.britsch at telekom.de<mailto:matthias.britsch at telekom.de>]
*Sent:* 17 September 2015 10:09
*To:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
*Subject:* Re: [Openstack-operators] European Operators

I would be interested as well.

Best regards,       Matthias

*Von:*Olivier Cant [mailto:olivier.cant at exxoss.com]
*Gesendet:* Donnerstag, 17. September 2015 10:09
*An:* openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>
*Betreff:* Re: [Openstack-operators] European Operators

Also very intrested.

Olivier

On 17/09/15S38 10:02, Salman Toor wrote:

   Hi,

   Why Not!

   I think its a great Idea. I want to join.

   Regards..

   Salman

   PhD, Scientific Computing
   Researcher, IT Department,
   Uppsala University.
   Cloud Application Expert,
   UPPMAX.
   Visiting Researcher,
   Helsinki Institute of Physics (HIP).
   salman.toor at it.uu.se<mailto:salman.toor at it.uu.se> <mailto:salman.toor at it.uu.se>
   http://www.it.uu.se/katalog/salto690

       On 17 Sep 2015, at 09:52, Matt Jarvis
       <matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
       <mailto:matt.jarvis at datacentred.co.uk>> wrote:

       Hi All

       Don't know how many European folks are on this list, but just
       wondering if there's any interest in a European Operators meet up
?

       Matt

       --

       Matt Jarvis

       Head of Cloud Computing
       DataCentred

       Office: (+44)0161 8703985
       Mobile: (+44)07983 725372

       Email: matt.jarvis at datacentred.co.uk<mailto:matt.jarvis at datacentred.co.uk>
       <mailto:matt.jarvis at datacentred.co.uk>

       Website: http://www.datacentred.co.uk<http://www.datacentred.co.uk/>
       <http://www.datacentred.co.uk/>


       DataCentred Limited registered in England and Wales no.
       05611763_______________________________________________
       OpenStack-operators mailing list
       OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
       <mailto:OpenStack-operators at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




   _______________________________________________

   OpenStack-operators mailing list

   OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
   <mailto:OpenStack-operators at lists.openstack.org>


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--

Exxoss <http://www.exxoss.com>

*Olivier Cant*, CEO |Gsm: +32(0)497/64.18.22
*Exxoss, SPRL <http://www.exxoss.com>*
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
+32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
Twitter <http://twitter.com/exxossIT>Facebook
<http://facebook.com/exxoss>Linked In
<https://www.linkedin.com/company/exxoss>




_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





--

Matt Jarvis

Head of Cloud Computing
DataCentred

Office: (+44)0161 8703985
Mobile: (+44)07983 725372

Email: matt.jarvis at datacentred.co.uk

Website: http://www.datacentred.co.uk


DataCentred Limited registered in England and Wales no. 05611763







--

Matt Jarvis

Head of Cloud Computing
DataCentred

Office: (+44)0161 8703985
Mobile: (+44)07983 725372

Email: matt.jarvis at datacentred.co.uk

Website: http://www.datacentred.co.uk


DataCentred Limited registered in England and Wales no. 05611763


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


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


--
Questo messaggio e' stato analizzato con Libra ESVA ed e' risultato non infetto.
Clicca qui per segnalarlo come spam.<http://esva01.enter.it/cgi-bin/learn-msg.cgi?id=2062D40060.ADC39>
Clicca qui per metterlo in blacklist<http://esva01.enter.it/cgi-bin/learn-msg.cgi?blacklist=1&id=2062D40060.ADC39> _______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/8dc7b49d/attachment.html>

From christian at berendt.io  Fri Sep 18 13:21:39 2015
From: christian at berendt.io (Christian Berendt)
Date: Fri, 18 Sep 2015 15:21:39 +0200
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FBDF77.4090909@openstack.org>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
 <55FBDF77.4090909@openstack.org>
Message-ID: <55FC0FE3.4020508@berendt.io>

On 09/18/2015 11:55 AM, Tom Fifield wrote:
> I'm not a "US folk", but I'd like to help organise, and probably wander
> over if you'll have me :) I've also got colleagues that are pretty good
> at this event planning logistics kind of thing that we can also ask for
> assistance. Maybe also cash :)

We are also interested in joining a European Ops meetup and I can help 
with the organization.

Christian.

-- 
Christian Berendt
Cloud Solution Architect
Mail: berendt at b1-systems.de

B1 Systems GmbH
Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


From matt.jarvis at datacentred.co.uk  Fri Sep 18 13:47:40 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Fri, 18 Sep 2015 14:47:40 +0100
Subject: [Openstack-operators] [eu] European Operators Meetup
Message-ID: <CACpXDz9zV56fwBwCG7wG3Jm0WbL6Oz-GF7FEQ=sz4Ry4krw-Ng@mail.gmail.com>

OK, let's try this with tags. I've created an initial etherpad
https://etherpad.openstack.org/p/european-ops-meetup-planning to start to
gather some information. This is a first pass and obviously not definitive,
so feel free to add sections or suggestions.

-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/fda19cb9/attachment.html>

From matt.jarvis at datacentred.co.uk  Fri Sep 18 13:48:52 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Fri, 18 Sep 2015 14:48:52 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FC0FE3.4020508@berendt.io>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
 <55FBDF77.4090909@openstack.org> <55FC0FE3.4020508@berendt.io>
Message-ID: <CACpXDz9WZ+GDC8GvG1B3_nw6n9T0fTnOtqRgeWaaAE9ic_XApw@mail.gmail.com>

I've just started another thread, tagged with [eu] which has a link to an
initial etherpad to start to gather some ideas and information. If everyone
who's interested can take a look and start adding some content, we can get
the wheels turning !

On 18 September 2015 at 14:21, Christian Berendt <christian at berendt.io>
wrote:

> On 09/18/2015 11:55 AM, Tom Fifield wrote:
>
>> I'm not a "US folk", but I'd like to help organise, and probably wander
>> over if you'll have me :) I've also got colleagues that are pretty good
>> at this event planning logistics kind of thing that we can also ask for
>> assistance. Maybe also cash :)
>>
>
> We are also interested in joining a European Ops meetup and I can help
> with the organization.
>
> Christian.
>
> --
> Christian Berendt
> Cloud Solution Architect
> Mail: berendt at b1-systems.de
>
> B1 Systems GmbH
> Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/f9ec2d91/attachment.html>

From klindgren at godaddy.com  Fri Sep 18 20:29:21 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Fri, 18 Sep 2015 20:29:21 +0000
Subject: [Openstack-operators] Cells V1 patches
Message-ID: <88EE3D36-5350-4D06-9316-286D1CCF448F@godaddy.com>

Hello all,

The LDT working group is currently trying to collect a list of patches that people are carrying to better support Cells V1.  We currently have a list of ~30 patches[1] that operators who are using cells are running to fix bugs or fix broken functionality under cells v1.  If you are running cells and have patches, please please please update the etherpad[1].  We realize that work is on going to move from cells v1 to cells v2.  However multiple child cells under v2 will not be supported until at least 2 release out (1+ years).

What we are trying to do is get a list of patches people have to fix issues/add functionality and try to get them either added upstream or added to a common repository.  The idea being that we want to make it easier for people who need to use Cells v1 until Cell v2 is fully supported.

[1] - https://etherpad.openstack.org/p/PAO-LDT-cells-patches
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/aa0bf4b1/attachment.html>

From klindgren at godaddy.com  Fri Sep 18 22:35:10 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Fri, 18 Sep 2015 22:35:10 +0000
Subject: [Openstack-operators] Operator Local Patches
Message-ID: <AC36B0CA-2D61-4538-9930-E0E452F13CD5@godaddy.com>

Hello Operators!

During the ops meetup in Palo Alto were we talking about sessions for Tokyo. A session that I purposed, that got a bunch of +1's,  was about local patches that operators were carrying.  From my experience this is done to either implement business logic,  fix assumptions in projects that do not apply to your implementation, implement business requirements that are not yet implemented in openstack, or fix scale related bugs.  What I would like to do is get a working group together to do the following:

1.) Document local patches that operators have (even those that are in gerrit right now waiting to be committed upstream)
2.) Figure out commonality in those patches
3.) Either upstream the common fixes to the appropriate projects or figure out if a hook can be added to allow people to run their code at that specific point
4.) ????
5.) Profit

To start this off, I have documented every patch, along with a description of what it does and why we did it (where needed), that GoDaddy is running [1].  What I am asking is that the operator community please update the etherpad with the patches that you are running, so that we have a good starting point for discussions in Tokyo and beyond.

[1] - https://etherpad.openstack.org/p/operator-local-patches
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/d5262cbf/attachment.html>

From jay at openstack.org  Fri Sep 18 22:41:05 2015
From: jay at openstack.org (Jay Fankhauser)
Date: Fri, 18 Sep 2015 17:41:05 -0500
Subject: [Openstack-operators] =?utf-8?q?OpenStack_Community_Weekly_Newsle?=
 =?utf-8?b?dHRlciAoU2VwdC4sIDEyIOKAkyAxOCk=?=
Message-ID: <C1E5C6C7-6C8D-460C-BA3F-7D4D0B0E3D16@openstack.org>

Running OpenStack? You have the power to influence the roadmap <https://www.openstack.org/surveys/landing?BackURL=/surveys/current>
Complete the User Survey by September 25

Call for Outreachy Mentors? <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074399.html>

If you are a  full-time contributor, please consider sharing your time, knowledge and experience to make our community more diverse and you?ll have the opportunity to meet new talents. Ask for further directions in OpenStack-opw on Freenode.

A starter guide to DefCore, OpenStack?s interoperability project <http://superuser.openstack.org/articles/a-starter-guide-to-defcore-openstack-s-interoperability-project>

Rob Hirschfeld, co-chair of the DefCore committee, shares more on DefCore, which defines capabilities, code and must-pass tests, creating the minimum standards for products labeled OpenStack

The Road to Tokyo 

Register now: full access registration prices increase on?9/29 at 11:59pm PT <https://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598>
Discounted registration for?nonprofit/government/students deadline is?9/25? <https://openstack.formstack.com/forms/openstack_summit_tokyo_discounted_registration>
Get your OpenStack Summit Tokyo visa in five steps: Deadline for Visa invitation requests is?10/1 <http://superuser.openstack.org/articles/get-your-openstack-summit-tokyo-visa-in-five-steps>
The schedule and mobile app for the OpenStack Summit in Tokyo are now available <https://www.openstack.org/summit/tokyo-2015/schedule/>
Reports from Previous Events 

None this week
Deadlines and Contributors Notifications 

Liberty Release Oct., 15, 2015 <https://wiki.openstack.org/wiki/Liberty_Release_Schedule>
Security Advisories and Notices 

None this week
Tips ?n Tricks 

By Nicole Martinelli <https://www.linkedin.com/in/nicolemartinelli>: Confused about the OpenStack release cycle? Check out this handy chart <http://superuser.openstack.org/articles/confused-about-the-openstack-release-cycle-check-out-this-handy-chart>
By Superuser: How to migrate from VMware and Hyper-V to OpenStack <http://superuser.openstack.org/articles/how-to-migrate-from-vmware-and-hyper-v-to-openstack>
By Madhu Kashyap: Bringing NFV into OpenStack with Tacker <http://superuser.openstack.org/articles/bringing-nfv-into-openstack-with-tacker>
By Nicholas Cammorato: Building an OpenStack lab from scratch with PackStack on AWS and Google Cloud ? Installing OpenStack via Packstack <https://www.ravellosystems.com/blog/openstack-packstack-installation-on-aws/>
By Miguel Grinberg <https://developer.rackspace.com/blog/authors/miguel-grinberg/>: Keystone-to-Keystone Federation with the OpenStack-Ansible Project <https://developer.rackspace.com/blog/keystone-to-keystone-federation-with-openstack-ansible>
Upcoming Events <https://www.openstack.org/community/events> 

Sep 21 ? 24, 2015?Storage Developer Conference?Santa Clara, CA, US <http://www.snia.org/events/storage-developer>
Sep 29?? 30, 2015 Cloud Storage in OpenStack <https://groups.openstack.org/groups/frederick-md/cloud-storage-openstack>
Oct 01, 2015?OpenStack Meetup Cluj?Cluj-Napoc, Cluj, RO <http://www.meetup.com/OpenStackRomania/events/222910344/>
Oct 01, 2015?South Bay OpenStack Meetup, Beginner track San Francisco, CA, US <http://www.meetup.com/openstack/events/221806052/>
Oct 01 ? 02, 2015?October OpenStack Meetup ? SDN and Containers?Chicago, IL, US <http://www.meetup.com/meetup-group-NjZdcegA/events/225081881/>
Oct 04 ? 08, 2015?Gartner SymposiumITxpo?Orlando, FL, US <http://www.gartner.com/events/na/orlando-symposium>
Oct 06, 2015?October Sydney Meetup <http://www.meetup.com/Australian-OpenStack-User-Group/events/220202327/>
Oct 07, 2015?Houston OpenStack Meetup?Houston, TX, US <http://www.meetup.com/openstackhoustonmeetup/events/224870393/?eventId=224870393&action=detail>
Oct 07 ? 08, 2015?OpenStack Liberty Release?Richardson, TX, US <http://www.meetup.com/OpenStack-DFW/events/225014699/>
Oct 07 ? 08, 2015?OpenStack 101?Houston, TX, US <http://www.meetup.com/openstackhoustonmeetup/events/224870393/>
Oct 10, 2015?OpenStack India Meetup, Pune?Pune, IN <http://www.meetup.com/Indian-OpenStack-User-Group/events/225039190/>
Oct 12, 2015?OpenStack Cinder deep dive?Stockholm, SE <http://www.meetup.com/OpenStack-User-Group-Nordics/events/225365322/>
Oct 13, 2015?Pub Gathering?Manchester, GB <http://www.meetup.com/Manchester-OpenStack-Meetup/events/224421141/>
Oct 15, 2015?OpenStack Howto part 7 ? Data Processing?Prague, CZ <http://www.meetup.com/OpenStack-Czech-User-Group-Meetup/events/222955596/>
Oct 15 ? 16, 2015?Coming event, stay tuned?Washington D.C., DC, US <http://www.meetup.com/OpenStackDC/events/224954116/>
Oct 16, 2015?OpenStack PDX Meetup <http://www.meetup.com/openstack-pdx/events/fsnsglytnbtb/>
Oct 16, 2015?SFBay OpenStack Hackathon #OSSFO <http://www.meetup.com/openstack/events/223988220/>What you need to know from the developer?s list
PTL Nominations Are Over, Lets Start Elections! <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074765.html>
Five projects don?t have candidates. According to OpenStack governance, the TC will appoint the new PTL [1].
  Barbican
  MagnetoDB
  Magnum
  Murano
  Security
Seven projects will have an election:
  Cinder
  Glance
  Ironic
  Keystone
  Mistral
  Neutron
  Oslo   
 There was confusion in UTC and how to submit nominations through Gerrit, but the TC will work with those candidates in Magnum, Barbican, Murano, Security. 
Doug Hellmann says MagnetoDB will be discussed for removal due to inactivity.? [1]
Proposed Priorities For Glance <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html>
From conversations at the Ops Midcycle meetup and email threads with regards to Glance issues, Doug Hellmann put together a list of proposed priorities for the Glance team:  Focus attention on DefCore:
DefCore goals: Ensure all OpenStack deployments are interoperable at REST level (users can write software for one OpenStack cloud and move to another without changes to the code).
Provide a well documented API with arguments that don?t change based on deployment choices.
Integration tests in Tempest that test Glance?s API directly, in addition to the the current tests that proxy through Nova and Cinder.
Once incorporated into DefCore, the APIs need to remain stable for an extended period of time, and follow deprecation timelines defined by complete V2 adoption in Nova and Cinder.
In Nova, some specs didn?t land in Liberty. Both teams need to work together.
In Cinder, the work is more complete, but needs to be reviewed that the API is used correctly.
Security audits and bug fixes
5 out of the 18 recent security reports were related to Glance [2]
Two ways to upload images to Glance V2:
1) POST image bits to Glance API server.

  a) Not widely deployed. Potential DOS vector.
2) Task API, to have Glance download it asynchronously.

  a) Not widely deployed.
  b) Assumes you know what task ?types? are supported by which cloud, and the expected arguments (i.e. JSON blob). (e.g. Glance docs give a url for a source, but Rackspace gives a Swift location as a source)
New Proposed ?default? network model <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html>
Monty hates floating IPs. 
Observed with 5 public clouds, requiring you to use a floating IP to get an outbound address. Others directly attach you to the public network.
Some allow you to create a private network and attach virtual machines to it, create a router with a gateway.
 Monty wants an easier way to have a virtual machine on the external facing network of a cloud. 
Users shouldn't have to learn about how to make that work with floating tips. This should be consistent behavior across public clouds. There is an effort set for Mitaka to work on Monty's request [3]. This will be done for 'nova boot' and work with multiple networks.
 If you have a more complicated network setup, this spec isn't for you.
 Base Feature Deprecation Policy <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html>
Thierry proposes a standard way to communicate and perform removal of user-visible behaviors and capabilities.
We sort of have something today, but not written of ?to remove a feature, you mark it deprecated for n releases, then remove it?.
Tag proposed [4].
We need to survey existing projects to see what their deprecation policy is.
Proposed options for deprecation period:
n+2 for features and capabilities, n+1 for config options
n+1 for everything
n+2 for everything
Ben Swartzlander thinks this discussion also needs to cover long term support (LTS).
Fungi thinks this is premature. Icehouse stable branch made it to 14 months before it was dropped due to not enough effort was given to keep it working.
It was agreed ?config options and features will have to be marked deprecated for a minimum of one stable release branch and a minimum of 3 months?.?
team:danger-not-diverse tag <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074264.html>
Josh Harlow is concerned that most projects start off small and not diverse, and this tag [5] would create negative connotations for those projects.
Thierry raises it?s important to see the intent of the tag, rather by it?s name.
The tag system is there to help our ecosystem navigate the big tent by providing bits of information.
Example of information: how risky is it to invest on a given project?
Some projects are dependent on a single company and can disappear in one day by the CEO?s decision.
For this reason, Thierry supports describing project teams that are *extremely* fragile.
As a result, the big tent is more inclusive. On the flip side, we need to inform our ecosystem that some project are less mature. Otherwise, you?re hiding this information.
[1] - http://lists.openstack.org/pipermail/openstack-dev/2015-September/074837.html? <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074837.html>
[2] - https://security.openstack.org/search.html?q=glance&check_keywords=yes&area=default <https://security.openstack.org/search.html?q=glance&check_keywords=yes&area=default>
[3] - https://blueprints.launchpad.net/neutron/+spec/get-me-a-network <https://blueprints.launchpad.net/neutron/+spec/get-me-a-network> 
[4] - https://review.openstack.org/#/c/207467/ <https://review.openstack.org/#/c/207467/>
[5] - https://review.openstack.org/#/c/218725/ <https://review.openstack.org/#/c/218725/>
?
Other News
Tracking the OpenStack revolution <http://superuser.openstack.org/articles/tracking-the-openstack-revolution>
 Python 3 Status in OpenStack Liberty <http://techs.enovance.com/7807/python-3-status-openstack-liberty>

The weekly newsletter is a way for the community to learn about all the various activities in the OpenStack world._______________________________________________
Community mailing list
Community at lists.openstack.org <mailto:Community at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/community <http://lists.openstack.org/cgi-bin/mailman/listinfo/community>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/07b82c41/attachment-0001.html>

From alawson at aqorn.com  Sat Sep 19 05:42:44 2015
From: alawson at aqorn.com (Adam Lawson)
Date: Fri, 18 Sep 2015 22:42:44 -0700
Subject: [Openstack-operators] [Swift] deploying behind apache?
Message-ID: <CAJfWK4920UdcFKWK3fpavMEEFntf4Qj-eaAHZDGnHy6FXseSMw@mail.gmail.com>

Hey everyone,

What are the advantages to deploying swift storage and/or proxy services
behind apache versus not? Are there performance improvements that come into
play at scale? Has this been addressed before and are there any conclusions
drawn around these considerations I can read up on?

/adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150918/84f5ee24/attachment.html>

From matt.jarvis at datacentred.co.uk  Sat Sep 19 08:07:12 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Sat, 19 Sep 2015 09:07:12 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <CACpXDz9WZ+GDC8GvG1B3_nw6n9T0fTnOtqRgeWaaAE9ic_XApw@mail.gmail.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se>
 <55FA751A.90908@exxoss.com>
 <427DF7C5C4833E4DA4628FEDBABBF479028C0D12093A@HE100041.emea1.cds.t-internal.com>
 <20FD4C40B882E34584FC3C5B98A1F07907DA63CC@hhmail02.hh.imgtec.org>
 <55FAAC66.4090004@openstack.org>
 <CACpXDz-XAJbm+btcC-XajDd4MkFnK8vdP1PjAS0ew2rx_UjrwQ@mail.gmail.com>
 <SN1PR02MB169532969373B37BA9C08545995A0@SN1PR02MB1695.namprd02.prod.outlook.com>
 <CACpXDz9j+8qBxbBVsrULW_Bmm5kMqPnVGUamAcPesJVeFdZMPA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A41BC46@CERNXCHG44.cern.ch>
 <D220534B.17AA00%vw@rackspace.com>
 <9A715470-ACA5-40D1-9284-9D2643F5A644@cloudbasesolutions.com>
 <CACpXDz-kaEg3BzX4-n12XH2Yd6EVi1B_wNLThTajfs-L=hwByQ@mail.gmail.com>
 <55FBDF77.4090909@openstack.org> <55FC0FE3.4020508@berendt.io>
 <CACpXDz9WZ+GDC8GvG1B3_nw6n9T0fTnOtqRgeWaaAE9ic_XApw@mail.gmail.com>
Message-ID: <CACpXDz_HmtjzNv_VaiqgpLEWA1uh-KS4Zd0k2XOM8b6NFDh9cw@mail.gmail.com>

There's still a few people who responded to this thread who haven't added
anything to the etherpad yet - it's at
https://etherpad.openstack.org/p/european-ops-meetup-planning if you missed
the new thread I started

On 18 September 2015 at 14:48, Matt Jarvis <matt.jarvis at datacentred.co.uk>
wrote:

> I've just started another thread, tagged with [eu] which has a link to an
> initial etherpad to start to gather some ideas and information. If everyone
> who's interested can take a look and start adding some content, we can get
> the wheels turning !
>
> On 18 September 2015 at 14:21, Christian Berendt <christian at berendt.io>
> wrote:
>
>> On 09/18/2015 11:55 AM, Tom Fifield wrote:
>>
>>> I'm not a "US folk", but I'd like to help organise, and probably wander
>>> over if you'll have me :) I've also got colleagues that are pretty good
>>> at this event planning logistics kind of thing that we can also ask for
>>> assistance. Maybe also cash :)
>>>
>>
>> We are also interested in joining a European Ops meetup and I can help
>> with the organization.
>>
>> Christian.
>>
>> --
>> Christian Berendt
>> Cloud Solution Architect
>> Mail: berendt at b1-systems.de
>>
>> B1 Systems GmbH
>> Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
>> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk
> Website: http://www.datacentred.co.uk
>



-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150919/5906e4be/attachment.html>

From filip.lenaerts at devoteam.com  Sat Sep 19 14:04:10 2015
From: filip.lenaerts at devoteam.com (Filip Lenaerts)
Date: Sat, 19 Sep 2015 16:04:10 +0200
Subject: [Openstack-operators] European Operators
In-Reply-To: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
Message-ID: <CAObc0kTHBqNRtrzpX+9Mb_goeu3VbRSka7_gx-2M3j4hF9di4A@mail.gmail.com>

+1

On 17 September 2015 at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk>
wrote:

> Hi All
>
> Don't know how many European folks are on this list, but just wondering if
> there's any interest in a European Operators meet up ?
>
> Matt
>
> --
> Matt Jarvis
> Head of Cloud Computing
> DataCentred
> Office: (+44)0161 8703985
> Mobile: (+44)07983 725372
> Email: matt.jarvis at datacentred.co.uk
> Website: http://www.datacentred.co.uk
>
> DataCentred Limited registered in England and Wales no. 05611763
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150919/8c331a8a/attachment.html>

From josephbajin at gmail.com  Sat Sep 19 15:13:59 2015
From: josephbajin at gmail.com (Joseph Bajin)
Date: Sat, 19 Sep 2015 11:13:59 -0400
Subject: [Openstack-operators] [Swift] deploying behind apache?
In-Reply-To: <CAJfWK4920UdcFKWK3fpavMEEFntf4Qj-eaAHZDGnHy6FXseSMw@mail.gmail.com>
References: <CAJfWK4920UdcFKWK3fpavMEEFntf4Qj-eaAHZDGnHy6FXseSMw@mail.gmail.com>
Message-ID: <CAGm6i3kM3HF7A1_ejVQrZgDJxj78p8E2aOCUeQVu+H0sQCcg=w@mail.gmail.com>

We don't deploy swift behind apache, but instead we are using NGINX in this
particular case.  The only reason we went with NGINX was it allowed us to
control turning up and down particular services which apache couldn't do.
One day we will move back to apache when we move swift into containers.

The reason we put it behind nginx/apache was for a few different reasons:

1. We needed SSL for all our connections.  The python implementation of SSL
doesn't handle a lot of connectivity and starts to have issues over time.
This has been discussed about other projects as well, so it's not just
related to swift.
2. We had to control our SSL ciphers. Using nginx/apache allows us to have
that control very easily.
3. Python Threading - Most projects are using evenlets and that is all done
in a single thread.  The thought was Web Servers do web serving type of
traffic very well, so hand over web serving to a web serving and allow
scaling as well as getting rid of the single eventlet thread issue.





On Sat, Sep 19, 2015 at 1:42 AM, Adam Lawson <alawson at aqorn.com> wrote:

> Hey everyone,
>
> What are the advantages to deploying swift storage and/or proxy services
> behind apache versus not? Are there performance improvements that come into
> play at scale? Has this been addressed before and are there any conclusions
> drawn around these considerations I can read up on?
>
> /adam
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150919/755baf22/attachment.html>

From me at not.mn  Sat Sep 19 16:05:31 2015
From: me at not.mn (John Dickinson)
Date: Sat, 19 Sep 2015 09:05:31 -0700
Subject: [Openstack-operators] [Swift] deploying behind apache?
In-Reply-To: <CAGm6i3kM3HF7A1_ejVQrZgDJxj78p8E2aOCUeQVu+H0sQCcg=w@mail.gmail.com>
References: <CAJfWK4920UdcFKWK3fpavMEEFntf4Qj-eaAHZDGnHy6FXseSMw@mail.gmail.com>
 <CAGm6i3kM3HF7A1_ejVQrZgDJxj78p8E2aOCUeQVu+H0sQCcg=w@mail.gmail.com>
Message-ID: <B2586AD8-1401-4981-A082-05BD7640E990@not.mn>



On 19 Sep 2015, at 8:13, Joseph Bajin wrote:

> We don't deploy swift behind apache, but instead we are using NGINX in this
> particular case.  The only reason we went with NGINX was it allowed us to
> control turning up and down particular services which apache couldn't do.
> One day we will move back to apache when we move swift into containers.
>
> The reason we put it behind nginx/apache was for a few different reasons:
>
> 1. We needed SSL for all our connections.  The python implementation of SSL
> doesn't handle a lot of connectivity and starts to have issues over time.
> This has been discussed about other projects as well, so it's not just
> related to swift.

Indeed. You must not terminate TLS inside the python/eventlet process. It just doesn't work. To demonstrate this, see https://github.com/notmyname/ssl_eventlet_slowloris



> 2. We had to control our SSL ciphers. Using nginx/apache allows us to have
> that control very easily.
> 3. Python Threading - Most projects are using evenlets and that is all done
> in a single thread.  The thought was Web Servers do web serving type of
> traffic very well, so hand over web serving to a web serving and allow
> scaling as well as getting rid of the single eventlet thread issue.
>

Be very careful, especially with nginx. In older versions of nginx, the server would spool all content locally so it could retry on failures[1]. However, when you're using something like Swift which has very large request bodies, this will slow down requests and even cause a DOS since multiple requests could use up all the storage (memory or disk) on the server. e.g. imagine 100 concurrent 5GB uploads. You don't want the server (nginx or otherwise) to spool that 500GB locally.

--John



[1] newer versions may have changed this, but be very careful with the config options

>
>
>
>
> On Sat, Sep 19, 2015 at 1:42 AM, Adam Lawson <alawson at aqorn.com> wrote:
>
>> Hey everyone,
>>
>> What are the advantages to deploying swift storage and/or proxy services
>> behind apache versus not? Are there performance improvements that come into
>> play at scale? Has this been addressed before and are there any conclusions
>> drawn around these considerations I can read up on?
>>
>> /adam
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150919/70c23a8e/attachment.pgp>

From tom at openstack.org  Mon Sep 21 03:36:23 2015
From: tom at openstack.org (Tom Fifield)
Date: Mon, 21 Sep 2015 11:36:23 +0800
Subject: [Openstack-operators] [tags] SDK support
Message-ID: <55FF7B37.7080308@openstack.org>

Hiya,

I did a review of the SDK support for our various service projects and 
decided to turn it into a tag.

For your review:

https://review.openstack.org/#/c/225539



Regards,


Tom


From boris at pavlovic.me  Mon Sep 21 05:08:33 2015
From: boris at pavlovic.me (Boris Pavlovic)
Date: Sun, 20 Sep 2015 22:08:33 -0700
Subject: [Openstack-operators]
	[openstack-dev][openstack-operators][tc][tags] Rally tags
Message-ID: <CAD85om0e5Fwc08xcmce1h-BC0i9i6AyZiUP6-6__J5qitg9Yzg@mail.gmail.com>

Hi stackers,

Rally project is becoming more and more used by Operators to check that
live OpenStack clouds perform well and that they are ready for production.

Results of PAO OPS meeting showed that there are interest in Rally related
tags for projects:
http://www.gossamer-threads.com/lists/openstack/operators/49466

3) "works in rally" - new tag suggestion
> There was general interest in asking the Rally team to consider making a
> "works in rally" tag, since the rally tests were deemed 'good'.


I have few ideas about the rally tags:

- covered-by-rally
   It means that there are official (inside the rally repo) plugins for
testing of particular project

- has-rally-gates
   It means that Rally is run against every patch proposed to the project

- certified-by-rally [wip]
   As well we are starting working on certification task:
https://review.openstack.org/#/c/225176/5
   which will be the standard way to check whatever cloud is ready for
production based on volume, performance & scale testing.


Thoughts?


Best regards,
Boris Pavlovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150920/7526350f/attachment.html>

From abhishek.talwar at tcs.com  Mon Sep 21 11:03:05 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Mon, 21 Sep 2015 16:33:05 +0530
Subject: [Openstack-operators]  [vcpu] [devstack] [kilo]
Message-ID: <OF21E3666A.0D4DC38F-ON65257EC7.003CB538-65257EC7.003CB53B@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/80a78287/attachment.html>

From salv.orlando at gmail.com  Mon Sep 21 13:06:50 2015
From: salv.orlando at gmail.com (Salvatore Orlando)
Date: Mon, 21 Sep 2015 14:06:50 +0100
Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by
	ICMP!!!!!!!
In-Reply-To: <3B1D2A13-ABD7-49F1-8E86-1C996F44C119@godaddy.com>
References: <4cb52501.8ae3.14fdbcd4e39.Coremail.applyhhj@163.com>
 <3B1D2A13-ABD7-49F1-8E86-1C996F44C119@godaddy.com>
Message-ID: <CAP0B2WNSv9bJgriP=5GAnTaWiuFOyXmGmy_mnmoz2oZm5Bk_zg@mail.gmail.com>

The comment from Kris is correct.
In the official openstack guide I believe it is stated to remove any
address from the interface attached to br-ex (sudo ip addr del <addr> dev
<dev>), not to assign it 0.0.0.0

If the guide says otherwise please open a bug against the relevant doc
project.

Salvatore



On 17 September 2015 at 16:08, Kris G. Lindgren <klindgren at godaddy.com>
wrote:

> For us on boot, we configure the systems init scripts to bring up br-ext
> and plug in the ethernet (or in our case bond) device into the external
> bridge.  You should look at your specific distro for guidence here.  Redhat
> based (RHEL/CentOS/Fedora) use:
> http://blog.oddbit.com/2014/05/20/fedora-and-ovs-bridge-interfac/ as a
> guide.
>
> We do not assign any ip address to the interface attached to the bridge.
> If you assigned 0.0.0.0 netmask 0.0.0.0 you basically assigned every ip
> address in ipv4 to your interface, so anything that arps on your network
> for an ip address, you server is going to respond say "hey that?s me".
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: applyhhj
> Date: Thursday, September 17, 2015 at 8:55 AM
> To: openstack-operators
> Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by
> ICMP!!!!!!!
>
> Hi,
>
> I followed The Guidance and tried to configure openvswitch(OVS) service. I
> first created a bridge br-ex and then added eth2 to the bridge. After that
> I set the IP of eth2 to 0.0.0.0 and then reboot the system. However br-ex
> was not up when system launched. So I turned on br-ex manually and then
> restart the network, but br-ex could not get ip from dhcp server. Thus I
> used ?dhclient br-ex? to manually acquire IP. Well till then everything
> worked fine, but in the evening the Network Node was continuously attacked
> by ICMP package. Iptraf showed the following messages:
>
>
>
> *x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on
> eth2
> *
>
> *x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to
> 166.111.61.xxx on eth2
>                                                     *
>
> *x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to
> 166.111.61.xx on
> eth2
> *
>
> *x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx
> on
> eth2
> *
>
> *x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on
> eth2
>                                                                                                               *
>
> *x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to
> 166.111.61.xxx on eth2
>                                             *
>
> *x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to
> 166.111.61.xx on
> eth2
> *
>
> *x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.x on
> eth2
> *
>
> *x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.63 on
> eth2
>                                                                                                       *
>
> *x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to
> 166.111.61.xx on
> eth2
>                                     *
>
> *x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to
> 166.111.61.xxx on
> eth2
> *
>
> *x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx
> on
> eth2
> *
>
> *x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.x on eth2*
>
>
>
> My ip is none of the above ones. The download speed in system monitor went
> up to 3m/s or even higher to 8m/s. I tried to use iptables and ebtable to
> filter icmp packages and also set icmp_echo_ignore_all to drop all icmp
> pacakges. But, unfortunately, nothing works. As long as I deleted eth2 from
> br-ex or brought down br-ex, the network went back normal.If you have any
> idea, please help me. I have been stuck here for several days. Thank you
> very much!!
>
>
>
> Regards!
>
> hjh
>
>
> 2015-09-17
> ------------------------------
> applyhhj
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/06d9e9c2/attachment.html>

From jesse.pretorius at gmail.com  Mon Sep 21 15:31:16 2015
From: jesse.pretorius at gmail.com (Jesse Pretorius)
Date: Mon, 21 Sep 2015 16:31:16 +0100
Subject: [Openstack-operators] [openstack-ansible] Mitaka Summit sessions
Message-ID: <CAGSrQvwNf6a563KrC=g22JM6uQnjzfe6Vs4H-QFQd65juX+wqg@mail.gmail.com>

Hi everyone,

As the Mitaka summit draws nearer, I'd like a broad view of what people
would like to discuss at the summit. This can include anyone's input!
Obviously our space and time will be limited, so any sessions that we don't
get to formally do at the summit we'll either try to do informally during
the summit (in a workgroup session or something like that), or we'll try to
engage at an alternative date (like a midcycle).

Some sessions have already been proposed - please feel free to add to the
list. Try to use the same format so that we know whether you're
facilitating or whether you want someone else to, what preparation
attendees would need, etc.

https://etherpad.openstack.org/p/openstack-ansible-mitaka-summit

It's probably a good idea to review the currently registered blueprints [0]
and specs [1] before adding any proposed sessions - just to make sure that
you're not covering something that's already on the go. For any current
blueprints/specs we're certainly open to more discussion, but it'd be great
to see that discussion happen in the spec reviews. :)

[0] https://blueprints.launchpad.net/openstack-ansible
[1]
https://review.openstack.org/#/q/project:openstack/openstack-ansible-specs+status:open,n,z

-- 
Jesse Pretorius
IRC: odyssey4me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/a0e5bfba/attachment.html>

From ignaziocassano at gmail.com  Mon Sep 21 16:02:34 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Mon, 21 Sep 2015 18:02:34 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
Message-ID: <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>

Hi all, I' would like to know which openstack community edition components
work with vmware.
I know there is a nova driver for vmware.
I' like to know if glance, heat, ceilometer etc etc work with vmware.
As far is neutron is concerned, in a scenario where there are kvm and
vmware nodes, must I have an nsx multihypervisor solution ?
Must I insall nsx componenents on kvm nodes (a modified ovs version  for
kvm) ?
On vmware must I install the vmware nsx or the multihypervisor version ?
Regards
Ignazio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/71955e62/attachment.html>

From emilien at redhat.com  Mon Sep 21 16:20:05 2015
From: emilien at redhat.com (Emilien Macchi)
Date: Mon, 21 Sep 2015 12:20:05 -0400
Subject: [Openstack-operators] [puppet] feedback request about
	puppet-keystone
Message-ID: <56002E35.2010807@redhat.com>

Hi,

Puppet OpenStack group would like to know your feedback about using
puppet-keystone module.

Please take two minutes and feel the form [1] that contains a few
questions. The answers will help us to define our roadmap for the next
cycle and make Keystone deployment stronger for our users.

The result of the forms should be visible online, otherwise I'll make
sure the results are 100% public and transparent.

Thank you for your time,

[1] http://goo.gl/forms/eiGWFkkXLZ
-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/ed82e2a2/attachment.pgp>

From federico.facca at create-net.org  Mon Sep 21 16:33:46 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Mon, 21 Sep 2015 18:33:46 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
Message-ID: <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>

Hi Ignazio,
I am not the greatest expert in my team on the topic, so there my be some
mistakes (anyone feel free to correct :)), read my reply inline

On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Hi all, I' would like to know which openstack community edition components
> work with vmware.
> I know there is a nova driver for vmware.
>

correct, basically it will act as a "proxy" toward vCenter


> I' like to know if glance, heat, ceilometer etc etc work with vmware.
>
AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't
tested, but any implementation may reflect the fact that OS services for
VMWare are proxies (i.e. it will see whatever is on the other side like a
huge compute or a huge cinder)

About glance you may have some limitations, since it supports so far
(unless anything changed in Liberty) a single backend. actually we had
issues in booting a vmware volume from an image (using swift as glance
backend - it should work with no issue using the vmware storage, but then I
guess you lose the multi hypervisor support).


As far is neutron is concerned, in a scenario where there are kvm and
> vmware nodes, must I have an nsx multihypervisor solution ?
>

I think you can use other drivers as well (actually we developed one for a
customer). Or nova-network.


> Must I insall nsx componenents on kvm nodes (a modified ovs version  for
> kvm) ?
>
we didn't go for NSX solution, but I guess so.

> On vmware must I install the vmware nsx or the multihypervisor version ?
>

yes multihpervisor one... I know there were rumors about an opens source
release, but I hadn't any update on that.


Regards,
Federico

> Regards
> Ignazio
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/994c1048/attachment.html>

From ignaziocassano at gmail.com  Mon Sep 21 17:02:36 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Mon, 21 Sep 2015 19:02:36 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
Message-ID: <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>

Many thanks Federico...
So the question is: why should I use openstack with vmware ?
Il giorno 21/set/2015 18:34, "Federico Michele Facca" <
federico.facca at create-net.org> ha scritto:

> Hi Ignazio,
> I am not the greatest expert in my team on the topic, so there my be some
> mistakes (anyone feel free to correct :)), read my reply inline
>
> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <ignaziocassano at gmail.com
> > wrote:
>
>> Hi all, I' would like to know which openstack community edition
>> components work with vmware.
>> I know there is a nova driver for vmware.
>>
>
> correct, basically it will act as a "proxy" toward vCenter
>
>
>> I' like to know if glance, heat, ceilometer etc etc work with vmware.
>>
> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't
> tested, but any implementation may reflect the fact that OS services for
> VMWare are proxies (i.e. it will see whatever is on the other side like a
> huge compute or a huge cinder)
>
> About glance you may have some limitations, since it supports so far
> (unless anything changed in Liberty) a single backend. actually we had
> issues in booting a vmware volume from an image (using swift as glance
> backend - it should work with no issue using the vmware storage, but then I
> guess you lose the multi hypervisor support).
>
>
> As far is neutron is concerned, in a scenario where there are kvm and
>> vmware nodes, must I have an nsx multihypervisor solution ?
>>
>
> I think you can use other drivers as well (actually we developed one for a
> customer). Or nova-network.
>
>
>> Must I insall nsx componenents on kvm nodes (a modified ovs version  for
>> kvm) ?
>>
> we didn't go for NSX solution, but I guess so.
>
>> On vmware must I install the vmware nsx or the multihypervisor version ?
>>
>
> yes multihpervisor one... I know there were rumors about an opens source
> release, but I hadn't any update on that.
>
>
> Regards,
> Federico
>
>> Regards
>> Ignazio
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/27e33aad/attachment.html>

From Tim.Bell at cern.ch  Mon Sep 21 17:15:02 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Mon, 21 Sep 2015 17:15:02 +0000
Subject: [Openstack-operators] Insert an entry into the instance action list
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A43E9E7@CERNXCHG41.cern.ch>

 

The instance action list is a very useful tool for our end users to see what
has gone on with their VMs. Working with people in teams means that
sometimes one person does not get to hear what another one has done and so
raises helpdesk cases like "one of the VMs was rebooted".

 

Are there functions where

 

-          Either an admin or a team member can insert a record into the
instance action list ?

-          When performing an operation such as 'nova reboot', is there a
message option to create more than just '-' in the message column  ?

 

$  nova instance-action-list timosdoc

+--------+------------------------------------------+---------+-------------
---------------+

| Action | Request_ID                               | Message | Start_Time
|

+--------+------------------------------------------+---------+-------------
---------------+

| create | req-fb6566f9-492a-4463-840d-577ed9b54861 | -       |
2015-07-29T11:19:36.000000 |

| reboot | req-9ec87fd0-788a-426b-bab3-01ad6dbe6dee | -       |
2015-09-09T13:41:36.000000 |

+--------+------------------------------------------+---------+-------------
---------------+

 

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/e31b7474/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/e31b7474/attachment.bin>

From josephbajin at gmail.com  Mon Sep 21 17:16:59 2015
From: josephbajin at gmail.com (Joseph Bajin)
Date: Mon, 21 Sep 2015 13:16:59 -0400
Subject: [Openstack-operators] [Tools/Monitoring] New Time submitted and
	approved
Message-ID: <CAGm6i3m4rNAGxjjtPqvXpUbAqeofaHNQU6YtTnt6616U=8K14Q@mail.gmail.com>

Everyone,

Based on the feedback I did receive, we have moved the Operators Tools and
Monitoring Working Group to a later time in the day to accommodate as many
different timezones as we could.

Meetings will be held at 3pm (15:00) EST on odd Wednesday's starting this
Wednesday 9/23/2015 in the IRC chatroom #openstack-meeting-4

I hope this gets more people involved as there always is great discussion
during the meet-ups about tools and monitoring.   Additionally, now that JJ
has gotten the osops repo moved over to the OpenStack project, this should
hopefully give people a better place to find tools and other work.


Look forward to seeing everyone there!

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/7d9fbf98/attachment.html>

From federico.facca at create-net.org  Mon Sep 21 17:17:52 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Mon, 21 Sep 2015 19:17:52 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
 <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
Message-ID: <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>

there is no a proper answer to your question (expecially if you don't
provide a bit of a context :) i.e.
what are you trying to achieve? what are your constraints?)

In general, I doubt you can do many of the things you can do with OpenStack
using vCenter, and probably also with vCloud... (and the other way around,
there are things you can do with vCloud, you cannot do today with
OpenStack) on the other hand, by pluging vCenter in OpenStack you can do
many things that only vCenter can't achieve :)



On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Many thanks Federico...
> So the question is: why should I use openstack with vmware ?
> Il giorno 21/set/2015 18:34, "Federico Michele Facca" <
> federico.facca at create-net.org> ha scritto:
>
>> Hi Ignazio,
>> I am not the greatest expert in my team on the topic, so there my be some
>> mistakes (anyone feel free to correct :)), read my reply inline
>>
>> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <
>> ignaziocassano at gmail.com> wrote:
>>
>>> Hi all, I' would like to know which openstack community edition
>>> components work with vmware.
>>> I know there is a nova driver for vmware.
>>>
>>
>> correct, basically it will act as a "proxy" toward vCenter
>>
>>
>>> I' like to know if glance, heat, ceilometer etc etc work with vmware.
>>>
>> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't
>> tested, but any implementation may reflect the fact that OS services for
>> VMWare are proxies (i.e. it will see whatever is on the other side like a
>> huge compute or a huge cinder)
>>
>> About glance you may have some limitations, since it supports so far
>> (unless anything changed in Liberty) a single backend. actually we had
>> issues in booting a vmware volume from an image (using swift as glance
>> backend - it should work with no issue using the vmware storage, but then I
>> guess you lose the multi hypervisor support).
>>
>>
>> As far is neutron is concerned, in a scenario where there are kvm and
>>> vmware nodes, must I have an nsx multihypervisor solution ?
>>>
>>
>> I think you can use other drivers as well (actually we developed one for
>> a customer). Or nova-network.
>>
>>
>>> Must I insall nsx componenents on kvm nodes (a modified ovs version  for
>>> kvm) ?
>>>
>> we didn't go for NSX solution, but I guess so.
>>
>>> On vmware must I install the vmware nsx or the multihypervisor version ?
>>>
>>
>> yes multihpervisor one... I know there were rumors about an opens source
>> release, but I hadn't any update on that.
>>
>>
>> Regards,
>> Federico
>>
>>> Regards
>>> Ignazio
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>>
>> --
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>>
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>>
>> --
>> Dr. Federico M. Facca
>>
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>>
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
>>
>


-- 
--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/5bd0252c/attachment.html>

From ignaziocassano at gmail.com  Mon Sep 21 17:44:41 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Mon, 21 Sep 2015 19:44:41 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
 <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
 <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>
Message-ID: <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>

We would like to provide cloud infrastracture  multi hypervosor with sdn,
multi tenancy, orchestration and self provisioning.
I think openstack with kvm is a good  start point but we have  hunderds
applications on vmware.
A good compromise could be kvm and vmware with openstack but I am not sure
it is a good idea because vmware seems to me limited in this scenario.
Il giorno 21/set/2015 19:18, "Federico Michele Facca" <
federico.facca at create-net.org> ha scritto:

> there is no a proper answer to your question (expecially if you don't
> provide a bit of a context :) i.e.
> what are you trying to achieve? what are your constraints?)
>
> In general, I doubt you can do many of the things you can do with
> OpenStack using vCenter, and probably also with vCloud... (and the other
> way around, there are things you can do with vCloud, you cannot do today
> with OpenStack) on the other hand, by pluging vCenter in OpenStack you can
> do many things that only vCenter can't achieve :)
>
>
>
> On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano <ignaziocassano at gmail.com
> > wrote:
>
>> Many thanks Federico...
>> So the question is: why should I use openstack with vmware ?
>> Il giorno 21/set/2015 18:34, "Federico Michele Facca" <
>> federico.facca at create-net.org> ha scritto:
>>
>>> Hi Ignazio,
>>> I am not the greatest expert in my team on the topic, so there my be
>>> some mistakes (anyone feel free to correct :)), read my reply inline
>>>
>>> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <
>>> ignaziocassano at gmail.com> wrote:
>>>
>>>> Hi all, I' would like to know which openstack community edition
>>>> components work with vmware.
>>>> I know there is a nova driver for vmware.
>>>>
>>>
>>> correct, basically it will act as a "proxy" toward vCenter
>>>
>>>
>>>> I' like to know if glance, heat, ceilometer etc etc work with vmware.
>>>>
>>> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't
>>> tested, but any implementation may reflect the fact that OS services for
>>> VMWare are proxies (i.e. it will see whatever is on the other side like a
>>> huge compute or a huge cinder)
>>>
>>> About glance you may have some limitations, since it supports so far
>>> (unless anything changed in Liberty) a single backend. actually we had
>>> issues in booting a vmware volume from an image (using swift as glance
>>> backend - it should work with no issue using the vmware storage, but then I
>>> guess you lose the multi hypervisor support).
>>>
>>>
>>> As far is neutron is concerned, in a scenario where there are kvm and
>>>> vmware nodes, must I have an nsx multihypervisor solution ?
>>>>
>>>
>>> I think you can use other drivers as well (actually we developed one for
>>> a customer). Or nova-network.
>>>
>>>
>>>> Must I insall nsx componenents on kvm nodes (a modified ovs version
>>>> for kvm) ?
>>>>
>>> we didn't go for NSX solution, but I guess so.
>>>
>>>> On vmware must I install the vmware nsx or the multihypervisor version ?
>>>>
>>>
>>> yes multihpervisor one... I know there were rumors about an opens source
>>> release, but I hadn't any update on that.
>>>
>>>
>>> Regards,
>>> Federico
>>>
>>>> Regards
>>>> Ignazio
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Future Internet is closer than you think!
>>> http://www.fiware.org
>>>
>>> Official Mirantis partner for OpenStack Training
>>> https://www.create-net.org/community/openstack-training
>>>
>>> --
>>> Dr. Federico M. Facca
>>>
>>> CREATE-NET
>>> Via alla Cascata 56/D
>>> 38123 Povo Trento (Italy)
>>>
>>> P  +39 0461 312471
>>> M +39 334 6049758
>>> E  federico.facca at create-net.org
>>> T @chicco785
>>> W  www.create-net.org
>>>
>>
>
>
> --
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/a5632d9b/attachment.html>

From jj at chef.io  Mon Sep 21 18:53:04 2015
From: jj at chef.io (JJ Asghar)
Date: Mon, 21 Sep 2015 13:53:04 -0500
Subject: [Openstack-operators] [Tools/Monitoring] New Time submitted and
 approved
In-Reply-To: <CAGm6i3m4rNAGxjjtPqvXpUbAqeofaHNQU6YtTnt6616U=8K14Q@mail.gmail.com>
References: <CAGm6i3m4rNAGxjjtPqvXpUbAqeofaHNQU6YtTnt6616U=8K14Q@mail.gmail.com>
Message-ID: <56005210.4020008@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On 9/21/15 12:16 PM, Joseph Bajin wrote:
>
> 
> Meetings will be held at 3pm (15:00) EST on odd Wednesday's starting
this Wednesday 9/23/2015 in the IRC chatroom #openstack-meeting-4
Awesome! This is great news. I'm adding it to my calendar and excited to
start attending.

We have etherpads[1] setup for our agendas over at OpenStack-Chef, if we
could set that up too it really does help with the flow of the meetings.

The format
"https://etherpad.openstack.org/p/openstack-chef-meeting-20150907" works
really well and we have a template[2] here too.

Thoughts?

[1]: http://bit.ly/os-chef-meeting-agendas
[2]: https://etherpad.openstack.org/p/openstack-chef-meeting-template

Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWAFIQAAoJEDZbxzMH0+jTIn8P/0rWcL9Dfu9nxxSrpS1m2PCN
CahMwRNNxCIH0oTQXdiFy7KxGTbzUZnf2CF5lS4R8t6Ayz+8YpnwlpesPQvbCG9b
pJzpxXoQ8BwWljNAEk2XvAbWS+tHQVaXcQlswuRE6Wn4f/Gmo0a8k99nvgyA2F99
C3ygDzjlrMyo/PZlsrgKAFLIzhbRQEBWOYop/o6yyLjoEQlc+2vjM430t2a/ityI
473B8Rf7y66vtjfgsvL1XdJIZvMMt7F21vogBK0AwCg6EPXgZqxHxwGTW6y5cABs
klVSA1hH3blyRwJqJA+dBs95yMY93wnOnoW4u62U5bqKkc3ff3ZfH91P9trmpRYE
Oc+HDrUHHzI6ssVo1+Z8qMujwNSfEmT8Rx3/2hK/nsNJYfcP0M+HNNYlHSBDGs6E
tnj1Ef4hCrXgCPBurADNeKXzWaBbXuUbTDkmZKPK4oqK2qz70JPRIy+peTbr6gnl
rWNRLel55KKfPakUIVhIrsMlJ4qgDHJzpcDhvY9Jsh3bwfdOl80WDfI61rTayPMq
74FvB/D5LMRkJUm/6CPpwAnrU1P9jQqwe/PZ39FeoZiRILsuPFWkAbPjQ3a2rZFD
nKaNp98b2wCQYk1WNdugvIxRV0UtBUTdVIBSOMKTK0PVtQe2Xdo79yZiEtj37hiR
Vf58tBqSEMgzeq1b0qrl
=3OzC
-----END PGP SIGNATURE-----



From ffacca at create-net.org  Mon Sep 21 19:29:08 2015
From: ffacca at create-net.org (Federico Michele Facca)
Date: Mon, 21 Sep 2015 21:29:08 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
 <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
 <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>
 <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>
Message-ID: <8AE31648-F022-4E57-A56D-8F8BC594129F@create-net.org>

I don't think not being able of creating VMware volumes from images is a big limit, moreover it may be that was some misconfiguration on our side, or some limitation will be removed in next versions.

All the things you list in requirements should be achievable. Then about importing current appliances in openstack, I think you my need some trick to do it without registering them as images and booting them as VMs.

iFede - Fede's mobile edition

> Il giorno 21 set 2015, alle ore 19:44, Ignazio Cassano <ignaziocassano at gmail.com> ha scritto:
> 
> We would like to provide cloud infrastracture  multi hypervosor with sdn, multi tenancy, orchestration and self provisioning.
> I think openstack with kvm is a good  start point but we have  hunderds applications on vmware.
> A good compromise could be kvm and vmware with openstack but I am not sure it is a good idea because vmware seems to me limited in this scenario.
> 
> Il giorno 21/set/2015 19:18, "Federico Michele Facca" <federico.facca at create-net.org> ha scritto:
>> there is no a proper answer to your question (expecially if you don't provide a bit of a context :) i.e. 
>> what are you trying to achieve? what are your constraints?)
>> 
>> In general, I doubt you can do many of the things you can do with OpenStack using vCenter, and probably also with vCloud... (and the other way around, there are things you can do with vCloud, you cannot do today with OpenStack) on the other hand, by pluging vCenter in OpenStack you can do many things that only vCenter can't achieve :)
>> 
>> 
>> 
>>> On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
>>> Many thanks Federico...
>>> So the question is: why should I use openstack with vmware ?
>>> Il giorno 21/set/2015 18:34, "Federico Michele Facca" <federico.facca at create-net.org> ha scritto:
>>>> Hi Ignazio,
>>>> I am not the greatest expert in my team on the topic, so there my be some mistakes (anyone feel free to correct :)), read my reply inline
>>>> 
>>>>> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
>>>>> Hi all, I' would like to know which openstack community edition components work with vmware.
>>>>> I know there is a nova driver for vmware.
>>>>> 
>>>> 
>>>> correct, basically it will act as a "proxy" toward vCenter
>>>>  
>>>>> I' like to know if glance, heat, ceilometer etc etc work with vmware.
>>>>> 
>>>> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't tested, but any implementation may reflect the fact that OS services for VMWare are proxies (i.e. it will see whatever is on the other side like a huge compute or a huge cinder)
>>>> 
>>>> About glance you may have some limitations, since it supports so far (unless anything changed in Liberty) a single backend. actually we had issues in booting a vmware volume from an image (using swift as glance backend - it should work with no issue using the vmware storage, but then I guess you lose the multi hypervisor support).
>>>> 
>>>> 
>>>>> As far is neutron is concerned, in a scenario where there are kvm and vmware nodes, must I have an nsx multihypervisor solution ?
>>>>> 
>>>> 
>>>> I think you can use other drivers as well (actually we developed one for a customer). Or nova-network.
>>>>  
>>>>> Must I insall nsx componenents on kvm nodes (a modified ovs version  for kvm) ?
>>>>> 
>>>> we didn't go for NSX solution, but I guess so.
>>>>> On vmware must I install the vmware nsx or the multihypervisor version ?
>>>>> 
>>>> 
>>>> yes multihpervisor one... I know there were rumors about an opens source release, but I hadn't any update on that.
>>>> 
>>>> 
>>>> Regards,
>>>> Federico
>>>>> Regards
>>>>> Ignazio
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> --
>>>> Future Internet is closer than you think!
>>>> http://www.fiware.org
>>>> 
>>>> Official Mirantis partner for OpenStack Training
>>>> https://www.create-net.org/community/openstack-training
>>>> 
>>>> -- 
>>>> Dr. Federico M. Facca
>>>> 
>>>> CREATE-NET
>>>> Via alla Cascata 56/D
>>>> 38123 Povo Trento (Italy)
>>>> 
>>>> P  +39 0461 312471
>>>> M +39 334 6049758
>>>> E  federico.facca at create-net.org
>>>> T @chicco785
>>>> W  www.create-net.org
>> 
>> 
>> 
>> -- 
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>> 
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>> 
>> -- 
>> Dr. Federico M. Facca
>> 
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>> 
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/a4c523a0/attachment-0001.html>

From emilien at redhat.com  Mon Sep 21 19:59:11 2015
From: emilien at redhat.com (Emilien Macchi)
Date: Mon, 21 Sep 2015 15:59:11 -0400
Subject: [Openstack-operators] [puppet] Tokyo Summit - dev + ops
Message-ID: <5600618F.2050504@redhat.com>

Hello,

The summit is in a few weeks, and we are still defining our agenda [1].
Some topics have already been written, but it would be good to get more
topic, we have some room resources allocated for that purpose.
Both devs & ops, feel free to create your topic by defining a
description, owner (you if you can), and approximate needed time.

Thanks for your help,

[1] https://etherpad.openstack.org/p/HND-puppet
-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150921/4bee8e20/attachment.pgp>

From mvoelker at vmware.com  Mon Sep 21 20:13:39 2015
From: mvoelker at vmware.com (Mark Voelker)
Date: Mon, 21 Sep 2015 20:13:39 +0000
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
 <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
 <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>
 <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>
Message-ID: <3055F958-6A41-41DA-BB9A-32BD9C957BDD@vmware.com>

Ignazio,

> I know there is a nova driver for vmware.
> I' like to know if glance, heat, ceilometer etc etc work with vmware.


There are VMware drivers for Nova, Neutron (NSX and DVS, though the latter supports far fewer features), Neutron LBaaS, Cinder, and Glance.  Heat and Ceilometer also work fine.  You can find configuration guides here:

http://docs.openstack.org/kilo/config-reference/content/vmware-vmdk-driver.html

http://docs.openstack.org/kilo/config-reference/content/vmware.html

http://docs.openstack.org/kilo/config-reference/content/vmware-glance-backend.html

http://docs.openstack.org/kilo/config-reference/content/networking-plugin-vmware.html

http://docs.openstack.org/kilo/config-reference/content/networking-plugin-nsx.html

> As far is neutron is concerned, in a scenario where there are kvm and vmware nodes, must I have an nsx multihypervisor solution ?
> Must I insall nsx componenents on kvm nodes (a modified ovs version  for kvm) ?
> On vmware must I install the vmware nsx or the multihypervisor version ?

Not necessarily.  A common tactic for dealing with differing hypervisors (or for that matter, different networking or perhaps even storage solutions) is to deploy them into two separate regions: one for KVM and one for ESX.  If you?re not familiar with the regions concept in OpenStack, have a look here:

http://docs.openstack.org/openstack-ops/content/scaling.html

Essentially since these are separate API endpoints, you can have very different capabilities in each without having to worry about mixing and matching solutions.  So essentially you might have one region with ESX hypervisors, NSX for vSphere networking, and vSAN (or any other VMDK storage) for storage.  In the other region you might have KVM hypervisors with OVS for networking and NFS for storage.  Be aware that users must target their API calls to one region or the other though (since they are separate endpoints), and logical networks typically won?t stretch between regions.  Regions are often thought of as a construct for geographically diverse datacenters, but also work well as a means of segregation within a single DC.

At the risk of being accused of advertising on a mailer alias (=p), since you appear to have an interest in the VMware hypervisor and network stack you may want to have a look at the VMware Integrated OpenStack distribution:

http://www.vmware.com/products/openstack/

Other distributions (including I believe Mirantis and HP) also offer support for VMware underpinnings:

http://docs.hpcloud.com/#commercial/GA1/1.1commercial.install-GA-esx.html
https://www.mirantis.com/partners/mirantis-technology-partners/mirantis-partners-vmware/

At Your Service,

Mark T. Voelker



> On Sep 21, 2015, at 1:44 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
> 
> We would like to provide cloud infrastracture  multi hypervosor with sdn, multi tenancy, orchestration and self provisioning.
> I think openstack with kvm is a good  start point but we have  hunderds applications on vmware.
> A good compromise could be kvm and vmware with openstack but I am not sure it is a good idea because vmware seems to me limited in this scenario.
> 
> Il giorno 21/set/2015 19:18, "Federico Michele Facca" <federico.facca at create-net.org> ha scritto:
> there is no a proper answer to your question (expecially if you don't provide a bit of a context :) i.e. 
> what are you trying to achieve? what are your constraints?)
> 
> In general, I doubt you can do many of the things you can do with OpenStack using vCenter, and probably also with vCloud... (and the other way around, there are things you can do with vCloud, you cannot do today with OpenStack) on the other hand, by pluging vCenter in OpenStack you can do many things that only vCenter can't achieve :)
> 
> 
> 
> On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
> Many thanks Federico...
> So the question is: why should I use openstack with vmware ?
> Il giorno 21/set/2015 18:34, "Federico Michele Facca" <federico.facca at create-net.org> ha scritto:
> Hi Ignazio,
> I am not the greatest expert in my team on the topic, so there my be some mistakes (anyone feel free to correct :)), read my reply inline
> 
> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
> Hi all, I' would like to know which openstack community edition components work with vmware.
> I know there is a nova driver for vmware.
> 
> 
> correct, basically it will act as a "proxy" toward vCenter
>  
> I' like to know if glance, heat, ceilometer etc etc work with vmware.
> 
> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't tested, but any implementation may reflect the fact that OS services for VMWare are proxies (i.e. it will see whatever is on the other side like a huge compute or a huge cinder)
> 
> About glance you may have some limitations, since it supports so far (unless anything changed in Liberty) a single backend. actually we had issues in booting a vmware volume from an image (using swift as glance backend - it should work with no issue using the vmware storage, but then I guess you lose the multi hypervisor support).
> 
> 
> As far is neutron is concerned, in a scenario where there are kvm and vmware nodes, must I have an nsx multihypervisor solution ?
> 
> 
> I think you can use other drivers as well (actually we developed one for a customer). Or nova-network.
>  
> Must I insall nsx componenents on kvm nodes (a modified ovs version  for kvm) ?
> 
> we didn't go for NSX solution, but I guess so.
> On vmware must I install the vmware nsx or the multihypervisor version ?
> 
> 
> yes multihpervisor one... I know there were rumors about an opens source release, but I hadn't any update on that.
> 
> 
> Regards,
> Federico
> Regards
> Ignazio
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> 
> 
> -- 
> --
> Future Internet is closer than you think!
> http://www.fiware.org
> 
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
> 
> -- 
> Dr. Federico M. Facca
> 
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
> 
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
> 
> 
> 
> -- 
> --
> Future Internet is closer than you think!
> http://www.fiware.org
> 
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
> 
> -- 
> Dr. Federico M. Facca
> 
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
> 
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


From ffacca at create-net.org  Mon Sep 21 20:42:14 2015
From: ffacca at create-net.org (Federico Michele Facca)
Date: Mon, 21 Sep 2015 22:42:14 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <3055F958-6A41-41DA-BB9A-32BD9C957BDD@vmware.com>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
 <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
 <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>
 <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>
 <3055F958-6A41-41DA-BB9A-32BD9C957BDD@vmware.com>
Message-ID: <92424B04-D4AC-492A-A805-83E302682CE0@create-net.org>

Mark is right, the multi region approach, surely simplifies a lot the complexity of your deployment. Unless it is a needed feature for you to see multi hypervisor resources in a single view. All the rest - even though with additional complications - including multi "region" heat templates, multi region lbaas etc (using vpn across the regions), should work out.

Again, it all depends on your requirements :)

iFede - Fede's mobile edition

> Il giorno 21 set 2015, alle ore 22:13, Mark Voelker <mvoelker at vmware.com> ha scritto:
> 
> Ignazio,
> 
>> I know there is a nova driver for vmware.
>> I' like to know if glance, heat, ceilometer etc etc work with vmware.
> 
> 
> There are VMware drivers for Nova, Neutron (NSX and DVS, though the latter supports far fewer features), Neutron LBaaS, Cinder, and Glance.  Heat and Ceilometer also work fine.  You can find configuration guides here:
> 
> http://docs.openstack.org/kilo/config-reference/content/vmware-vmdk-driver.html
> 
> http://docs.openstack.org/kilo/config-reference/content/vmware.html
> 
> http://docs.openstack.org/kilo/config-reference/content/vmware-glance-backend.html
> 
> http://docs.openstack.org/kilo/config-reference/content/networking-plugin-vmware.html
> 
> http://docs.openstack.org/kilo/config-reference/content/networking-plugin-nsx.html
> 
>> As far is neutron is concerned, in a scenario where there are kvm and vmware nodes, must I have an nsx multihypervisor solution ?
>> Must I insall nsx componenents on kvm nodes (a modified ovs version  for kvm) ?
>> On vmware must I install the vmware nsx or the multihypervisor version ?
> 
> Not necessarily.  A common tactic for dealing with differing hypervisors (or for that matter, different networking or perhaps even storage solutions) is to deploy them into two separate regions: one for KVM and one for ESX.  If you?re not familiar with the regions concept in OpenStack, have a look here:
> 
> http://docs.openstack.org/openstack-ops/content/scaling.html
> 
> Essentially since these are separate API endpoints, you can have very different capabilities in each without having to worry about mixing and matching solutions.  So essentially you might have one region with ESX hypervisors, NSX for vSphere networking, and vSAN (or any other VMDK storage) for storage.  In the other region you might have KVM hypervisors with OVS for networking and NFS for storage.  Be aware that users must target their API calls to one region or the other though (since they are separate endpoints), and logical networks typically won?t stretch between regions.  Regions are often thought of as a construct for geographically diverse datacenters, but also work well as a means of segregation within a single DC.
> 
> At the risk of being accused of advertising on a mailer alias (=p), since you appear to have an interest in the VMware hypervisor and network stack you may want to have a look at the VMware Integrated OpenStack distribution:
> 
> http://www.vmware.com/products/openstack/
> 
> Other distributions (including I believe Mirantis and HP) also offer support for VMware underpinnings:
> 
> http://docs.hpcloud.com/#commercial/GA1/1.1commercial.install-GA-esx.html
> https://www.mirantis.com/partners/mirantis-technology-partners/mirantis-partners-vmware/
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Sep 21, 2015, at 1:44 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
>> 
>> We would like to provide cloud infrastracture  multi hypervosor with sdn, multi tenancy, orchestration and self provisioning.
>> I think openstack with kvm is a good  start point but we have  hunderds applications on vmware.
>> A good compromise could be kvm and vmware with openstack but I am not sure it is a good idea because vmware seems to me limited in this scenario.
>> 
>> Il giorno 21/set/2015 19:18, "Federico Michele Facca" <federico.facca at create-net.org> ha scritto:
>> there is no a proper answer to your question (expecially if you don't provide a bit of a context :) i.e. 
>> what are you trying to achieve? what are your constraints?)
>> 
>> In general, I doubt you can do many of the things you can do with OpenStack using vCenter, and probably also with vCloud... (and the other way around, there are things you can do with vCloud, you cannot do today with OpenStack) on the other hand, by pluging vCenter in OpenStack you can do many things that only vCenter can't achieve :)
>> 
>> 
>> 
>> On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
>> Many thanks Federico...
>> So the question is: why should I use openstack with vmware ?
>> Il giorno 21/set/2015 18:34, "Federico Michele Facca" <federico.facca at create-net.org> ha scritto:
>> Hi Ignazio,
>> I am not the greatest expert in my team on the topic, so there my be some mistakes (anyone feel free to correct :)), read my reply inline
>> 
>> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <ignaziocassano at gmail.com> wrote:
>> Hi all, I' would like to know which openstack community edition components work with vmware.
>> I know there is a nova driver for vmware.
>> 
>> 
>> correct, basically it will act as a "proxy" toward vCenter
>> 
>> I' like to know if glance, heat, ceilometer etc etc work with vmware.
>> 
>> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't tested, but any implementation may reflect the fact that OS services for VMWare are proxies (i.e. it will see whatever is on the other side like a huge compute or a huge cinder)
>> 
>> About glance you may have some limitations, since it supports so far (unless anything changed in Liberty) a single backend. actually we had issues in booting a vmware volume from an image (using swift as glance backend - it should work with no issue using the vmware storage, but then I guess you lose the multi hypervisor support).
>> 
>> 
>> As far is neutron is concerned, in a scenario where there are kvm and vmware nodes, must I have an nsx multihypervisor solution ?
>> 
>> 
>> I think you can use other drivers as well (actually we developed one for a customer). Or nova-network.
>> 
>> Must I insall nsx componenents on kvm nodes (a modified ovs version  for kvm) ?
>> 
>> we didn't go for NSX solution, but I guess so.
>> On vmware must I install the vmware nsx or the multihypervisor version ?
>> 
>> 
>> yes multihpervisor one... I know there were rumors about an opens source release, but I hadn't any update on that.
>> 
>> 
>> Regards,
>> Federico
>> Regards
>> Ignazio
>> 
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> 
>> 
>> -- 
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>> 
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>> 
>> -- 
>> Dr. Federico M. Facca
>> 
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>> 
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
>> 
>> 
>> 
>> -- 
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>> 
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>> 
>> -- 
>> Dr. Federico M. Facca
>> 
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>> 
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 


From andrew at lascii.com  Mon Sep 21 21:40:57 2015
From: andrew at lascii.com (Andrew Laski)
Date: Mon, 21 Sep 2015 17:40:57 -0400
Subject: [Openstack-operators] Insert an entry into the instance action
 list
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A43E9E7@CERNXCHG41.cern.ch>
References: <5D7F9996EA547448BC6C54C8C5AAF4E5010A43E9E7@CERNXCHG41.cern.ch>
Message-ID: <20150921214057.GK3226@crypt>

On 09/21/15 at 05:15pm, Tim Bell wrote:
>
>
>The instance action list is a very useful tool for our end users to see what
>has gone on with their VMs. Working with people in teams means that
>sometimes one person does not get to hear what another one has done and so
>raises helpdesk cases like "one of the VMs was rebooted".
>
>
>
>Are there functions where
>
>
>
>-          Either an admin or a team member can insert a record into the
>instance action list ?

There is no such capability in Nova.  Since the instance action list is 
intended to provide an accounting of what API actions have been taken on 
an instance I'm curious what use case you have in mind for manual 
insertion of records?

>
>-          When performing an operation such as 'nova reboot', is there a
>message option to create more than just '-' in the message column  ?

As things are coded currently the message column will only be filled out 
in case of an error, in which case it should have the exception message.  
Messages could be added for success cases as well, but the column is not 
intended for users to leave notes.  That could be a feature request 
which would likely result in a new field being added for that purpose.

>
>
>
>$  nova instance-action-list timosdoc
>
>+--------+------------------------------------------+---------+-------------
>---------------+
>
>| Action | Request_ID                               | Message | Start_Time
>|
>
>+--------+------------------------------------------+---------+-------------
>---------------+
>
>| create | req-fb6566f9-492a-4463-840d-577ed9b54861 | -       |
>2015-07-29T11:19:36.000000 |
>
>| reboot | req-9ec87fd0-788a-426b-bab3-01ad6dbe6dee | -       |
>2015-09-09T13:41:36.000000 |
>
>+--------+------------------------------------------+---------+-------------
>---------------+
>
>
>
>Tim
>



>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From applyhhj at 163.com  Tue Sep 22 03:14:49 2015
From: applyhhj at 163.com (applyhhj)
Date: Tue, 22 Sep 2015 11:14:49 +0800
Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by
	ICMP!!!!!!!
In-Reply-To: <CAP0B2WNSv9bJgriP=5GAnTaWiuFOyXmGmy_mnmoz2oZm5Bk_zg@mail.gmail.com>
References: <4cb52501.8ae3.14fdbcd4e39.Coremail.applyhhj@163.com>
 <3B1D2A13-ABD7-49F1-8E86-1C996F44C119@godaddy.com><CAP0B2WNSv9bJgriP=5GAnTaWiuFOyXmGmy_mnmoz2oZm5Bk_zg@mail.gmail.com>
Message-ID: <81bb830.1aca7.14ff30bef40.Coremail.applyhhj@163.com>

Thank you. After some work, I figured out that I misunderstood the openstack network configuration and now everything is ok.

Regards
hjh

2015-09-22



applyhhj



????Salvatore Orlando <salv.orlando at gmail.com>
?????2015-09-21 21:06
???Re: [Openstack-operators] Please help!!!!Openvswitch attacked by ICMP!!!!!!!
????"Kris G. Lindgren"<klindgren at godaddy.com>
???"applyhhj"<applyhhj at 163.com>,"openstack-operators"<openstack-operators at lists.openstack.org>

The comment from Kris is correct.
In the official openstack guide I believe it is stated to remove any address from the interface attached to br-ex (sudo ip addr del <addr> dev <dev>), not to assign it 0.0.0.0


If the guide says otherwise please open a bug against the relevant doc project.


Salvatore






On 17 September 2015 at 16:08, Kris G. Lindgren <klindgren at godaddy.com> wrote:

For us on boot, we configure the systems init scripts to bring up br-ext and plug in the ethernet (or in our case bond) device into the external bridge.  You should look at your specific distro for guidence here.  Redhat based (RHEL/CentOS/Fedora) use: http://blog.oddbit.com/2014/05/20/fedora-and-ovs-bridge-interfac/ as a guide.


We do not assign any ip address to the interface attached to the bridge.  If you assigned 0.0.0.0 netmask 0.0.0.0 you basically assigned every ip address in ipv4 to your interface, so anything that arps on your network for an ip address, you server is going to respond say "hey that?s me".
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy


From: applyhhj
Date: Thursday, September 17, 2015 at 8:55 AM
To: openstack-operators
Subject: [Openstack-operators] Please help!!!!Openvswitch attacked by ICMP!!!!!!!



Hi,
I followed The Guidance and tried to configure openvswitch(OVS) service. I first created a bridge br-ex and then added eth2 to the bridge. After that I set the IP of eth2 to 0.0.0.0 and then reboot the system. However br-ex was not up when system launched. So I turned on br-ex manually and then restart the network, but br-ex could not get ip from dhcp server. Thus I used ?dhclient br-ex? to manually acquire IP. Well till then everything worked fine, but in the evening the Network Node was continuously attacked by ICMP package. Iptraf showed the following messages:

x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on eth2                                                                                                                      
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2                                                                                                
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2                                                                                                 
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx on eth2                                                                                                            
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.xx on eth2                                                                                                                      
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2                                                                                                
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2                                                                                                 
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.x on eth2                                                                                                            
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.63 on eth2                                                                                                                      
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xx on eth2                                                                                                
x ICMP dest unrch (host comm denied) (576 bytes) from 176.32.36.23 to 166.111.61.xxx on eth2                                                                                                 
x ICMP dest unrch (host) (100 bytes) from 59.66.96.226 to 166.111.61.xx on eth2                                                                                                            
x ICMP time excd (56 bytes) from 4.69.143.125 to 166.111.61.x on eth2

My ip is none of the above ones. The download speed in system monitor went up to 3m/s or even higher to 8m/s. I tried to use iptables and ebtable to filter icmp packages and also set icmp_echo_ignore_all to drop all icmp pacakges. But, unfortunately, nothing works. As long as I deleted eth2 from br-ex or brought down br-ex, the network went back normal.If you have any idea, please help me. I have been stuck here for several days. Thank you very much!!

Regards!
hjh


2015-09-17



applyhhj

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/5a988e9e/attachment.html>

From tom at openstack.org  Tue Sep 22 05:04:45 2015
From: tom at openstack.org (Tom Fifield)
Date: Tue, 22 Sep 2015 13:04:45 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <55F8E5E3.1030502@openstack.org>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org>
Message-ID: <5600E16D.7040400@openstack.org>

Hi all,

I've started wrangling things toward a draft agenda.

You can watch it live on Google Sheets at:

https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842

Comments and feedback welcome!

Regards,


Tom

On 16/09/15 11:45, Tom Fifield wrote:
> Last chance to provide your ideas for our design summit track.
>
> So far we are lacking:
> * Lightning talks
> * Working Groups
> * General Sessions
>
> Starting next week we're going to prepare the draft agenda for
> circulation and discussion. So, get in now. What would you like to
> discuss with fellow ops and developers?
>
>
> https://etherpad.openstack.org/p/TYO-ops-meetup
>
>
> Regards,
>
>
> Tom
>
> On 08/09/15 17:10, Tom Fifield wrote:
>> Ping!
>>
>> This is your chance to provide input on our design summit track for
>> Tokyo. Add your ideas on the etherpad below!
>>
>>
>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>> On 03/09/15 03:27, Tom Fifield wrote:
>>> Hi all,
>>>
>>> Thanks for those who made it to the recent meetup in Palo Alto. It was a
>>> fantastic couple of days, and many are excited to get started on talking
>>> about our ops track in the Tokyo design summit.
>>>
>>>
>>> Recall that this is in addition to the operations and other conference
>>> track's presentations. It's aimed at giving us a design-summit-style
>>> place to congregate, swap best practices, ideas and give feedback.
>>>
>>>
>>> As usual, we're working to act on the feedback from all past events to
>>> make this one better than ever. One that we continue to work on is the
>>> need to see action happen as a result of this event, so please - when
>>> you are suggesting sessions in the below etherpad please try and phrase
>>> them in a way that will probably result in things happening afterward.
>>>
>>>
>>> **********************************************************************
>>>
>>> Please propose session ideas on:
>>>
>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>
>>> ensuring each session suggestion will have a result.
>>>
>>> **********************************************************************
>>>
>>>
>>> The room allocations are still being worked out, but the current
>>> thinking is that we will interleave general sessions and working groups
>>> across Tuesday and Wednesday, to allow for attendance from ops in the
>>> cross-project sessions.
>>>
>>>
>>> More as it comes, and as always, further information about ops meetups
>>> and notes from the past can be found on the wiki @:
>>>
>>> https://wiki.openstack.org/wiki/Operations/Meetups
>>>
>>> Finally, don't forget to register ASAP!
>>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From ansh.prat at gmail.com  Tue Sep 22 05:59:49 2015
From: ansh.prat at gmail.com (Anshu Prateek)
Date: Tue, 22 Sep 2015 05:59:49 +0000
Subject: [Openstack-operators] [Openstack] Regarding Openstack
	installation on the AWS Instance.
In-Reply-To: <CAN6XbhvKu6YE1WmHjf1gFUSFfFcUL1nre4SREOfu3LmPq8i+Sg@mail.gmail.com>
References: <CAN6XbhvKu6YE1WmHjf1gFUSFfFcUL1nre4SREOfu3LmPq8i+Sg@mail.gmail.com>
Message-ID: <CAK3Kwn4vctxm0CvWCdVZXq0hL64Y+acEebQ+VGW2LNMKswE3hg@mail.gmail.com>

Getting Openstack working on AWS is not a standard installation.
AFAIK, presently only Ravello will help you to run N^2 (Nested-nested)
virtualization (i.e, openstack on AWS).

https://www.ravellosystems.com/blog/virtual-bare-metal-devstack-multi-node-ec2/

On Tue, 22 Sep 2015 at 10:38 Manikanta Harish Kumar Vanka <
harishkumar.vanka at mtuity.com> wrote:

> Hi,
>
>
> I'm trying to install openstack on the AWS Instance Centos 7.0. When I'm
> working on this, I could install and set the openstack succesfully. But I
> couldn't get the dashboard setup. I don't know why it is not redirecting to
> the openstack.
>
> Please click on "
> http://ec2-54-163-95-197.compute-1.amazonaws.com/dashboard"
>
> The error was "The requested URL /dashboard was not found on this server."
>
> Did I miss any step for the deployment, I followed the below documentation
> to set that.
> http://big5data.blogspot.in/2014/05/install-openstack-via-rdo.html
>
> Please help me out ASAP.
>
>
> --
> *Thanks & Regards,*
> *Harish Sharma.*
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-- 
regards
Anshu Prateek
+91.991.610.2967
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/b522e6ab/attachment.html>

From matt.jarvis at datacentred.co.uk  Tue Sep 22 08:15:50 2015
From: matt.jarvis at datacentred.co.uk (Matt Jarvis)
Date: Tue, 22 Sep 2015 09:15:50 +0100
Subject: [Openstack-operators] European Operators
In-Reply-To: <56010C99.1080708@anynines.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <56010C99.1080708@anynines.com>
Message-ID: <CACpXDz_OVa28VgOS+EXzND7KiLkaZu7xqkKJSGhUmww2ML039Q@mail.gmail.com>

Please add your organisations to the etherpad at
https://etherpad.openstack.org/p/european-ops-meetup-planning, and we also
need everyone's input to suggest sessions you would be interested in.

On 22 September 2015 at 09:08, Heiko Kr?mer <hkraemer at anynines.com> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1
> I'm also interested.
>
>
>
> On 17.09.2015 09:52, Matt Jarvis wrote:
> > Hi All
> >
> > Don't know how many European folks are on this list, but just
> wondering if there's any interest in a European Operators meet up ?
> >
> > Matt
> >
> > --
> > Matt Jarvis
> > Head of Cloud Computing
> > DataCentred
> > Office: (+44)0161 8703985
> > Mobile: (+44)07983 725372
> > Email: matt.jarvis at datacentred.co.uk
> <mailto:matt.jarvis at datacentred.co.uk>
> > Website: http://www.datacentred.co.uk
> >
> > DataCentred Limited registered in England and Wales no. 05611763
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> - --
> anynines.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJWAQyZAAoJELxFogM4ixOFL7sIAOF0zFs7ZljI0rcSaqqrBW/O
> ZQhgeq2liNmv1qcnIyn9+yCka0bvgNZLg7S60rW4l3cvKqiq8QHXUIVNAmBqIjAH
> UtCRE2rrJKNmNGJRN0Qg2aJCd3svEEwubnKz6bsC15FVxK7o3YS8TNWdXholxElh
> i2FvOu7KWPNTbAa/50PeuIqP9GSi7ac/0s6D7rvABS2Gh3QeKqatjKNVAqrXnxam
> x++vbD1pIkx60omQQgrE8hk+A6PzzRTcb/CoLdvG8lnu+PDAMLZ4iJZB4iQtvsaJ
> kkB8FNe79/qvgzYDXQUrAO2p+wVpehoC383LDOeY69TJ0Hx9xv9HUjCeaOX47Y8=
> =iJXj
> -----END PGP SIGNATURE-----
>
>


-- 
Matt Jarvis
Head of Cloud Computing
DataCentred
Office: (+44)0161 8703985
Mobile: (+44)07983 725372
Email: matt.jarvis at datacentred.co.uk
Website: http://www.datacentred.co.uk

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/64fc59bc/attachment.html>

From hkraemer at anynines.com  Tue Sep 22 08:16:31 2015
From: hkraemer at anynines.com (=?UTF-8?Q?Heiko_Kr=c3=a4mer?=)
Date: Tue, 22 Sep 2015 10:16:31 +0200
Subject: [Openstack-operators] European Operators
In-Reply-To: <55FA751A.90908@exxoss.com>
References: <CACpXDz9QZBrpmYqTC=TEU0BMinjvD4g-KMjd7OtiEoZqzT5Ntg@mail.gmail.com>
 <1E4FC5D5-9110-4366-A09A-07925F3A8CAB@it.uu.se> <55FA751A.90908@exxoss.com>
Message-ID: <56010E5F.1040708@anynines.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm also intrested.

Cheers,
Heiko

On 17.09.2015 10:08, Olivier Cant wrote:
> Also very intrested.
>
> Olivier
>
> On 17/09/15S38 10:02, Salman Toor wrote:
>> Hi,
>>
>> Why Not!
>>
>> I think its a great Idea. I want to join.
>>
>> Regards..
>> Salman
>>
>>
>> PhD, Scientific Computing
>> Researcher, IT Department,
>> Uppsala University.
>> Cloud Application Expert,
>> UPPMAX.
>> Visiting Researcher,
>> Helsinki Institute of Physics (HIP).
>> salman.toor at it.uu.se <mailto:salman.toor at it.uu.se>
>> http://www.it.uu.se/katalog/salto690
>>
>>> On 17 Sep 2015, at 09:52, Matt Jarvis <matt.jarvis at datacentred.co.uk
<mailto:matt.jarvis at datacentred.co.uk>> wrote:
>>>
>>> Hi All
>>>
>>> Don't know how many European folks are on this list, but just
wondering if there's any interest in a European Operators meet up ?
>>>
>>> Matt
>>>
>>> --
>>> Matt Jarvis
>>> Head of Cloud Computing
>>> DataCentred
>>> Office: (+44)0161 8703985
>>> Mobile: (+44)07983 725372
>>> Email: matt.jarvis at datacentred.co.uk
<mailto:matt.jarvis at datacentred.co.uk>
>>> Website: http://www.datacentred.co.uk <http://www.datacentred.co.uk/>
>>>
>>> DataCentred Limited registered in England and Wales no.
05611763_______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
<mailto:OpenStack-operators at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> --
>
>
> Exxoss <http://www.exxoss.com>
> *Olivier Cant*, CEO | Gsm: +32(0)497/64.18.22
> *Exxoss, SPRL <http://www.exxoss.com>*
> Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone:
+32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
> Twitter <http://twitter.com/exxossIT> Facebook
<http://facebook.com/exxoss> Linked In
<https://www.linkedin.com/company/exxoss>
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


- -- 
anynines.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWAQ5fAAoJELxFogM4ixOFBCIIAIQPN3StPjnqnun5CuP1dLqc
A+u8BvGFjbiEAj6Zsy7aUWGEGfyHwcEKCufEx6DInwgiU3KEeUSKV0fS4NvLiwkG
SvjOntxuCXVVVuLZOsCgMo9xNjv92U6K0SbkHZRfLlXNa8jv+i8SwnXEThfZTZ9W
jsD569OtRv8X2CdWcYmo/qMLFbFkuFGo/4KlSUOWyWP17/75L40YKmt7VgkZyC5N
V0Y4J8FefV0FkGw5xSMKv79w8m5ddKtUsK06YA6hLfYK5pbNusI2zXLvjC4zVsrJ
MNC3qWgHRT3SiITj/Ets/DRR75wKwv9KT2viTjetInKCKIJV7YB1jMG2H4fX1bE=
=H9Gv
-----END PGP SIGNATURE-----



From abhishek.talwar at tcs.com  Tue Sep 22 09:57:52 2015
From: abhishek.talwar at tcs.com (Abhishek Talwar)
Date: Tue, 22 Sep 2015 15:27:52 +0530
Subject: [Openstack-operators]  [vcpu] [devstack] [kilo]
Message-ID: <OF656E9DE5.5EA46EC2-ON65257EC8.0036BC98-65257EC8.0036BC9B@tcs.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/2a7a418e/attachment.html>

From hkraemer at anynines.com  Tue Sep 22 10:09:56 2015
From: hkraemer at anynines.com (=?UTF-8?Q?Heiko_Kr=c3=a4mer?=)
Date: Tue, 22 Sep 2015 12:09:56 +0200
Subject: [Openstack-operators] [vcpu] [devstack] [kilo]
In-Reply-To: <OF656E9DE5.5EA46EC2-ON65257EC8.0036BC98-65257EC8.0036BC9B@tcs.com>
References: <OF656E9DE5.5EA46EC2-ON65257EC8.0036BC98-65257EC8.0036BC9B@tcs.com>
Message-ID: <560128F4.8070908@anynines.com>

Hi,

your scheduler delivers all threads to the cores, so if you have some
running processes in your VM, all cores will be used.
A CPU core in your VM is representing by one process on the host system,
normally. That's depend on your hypervisor.

Another thing, you can set explicitly which core you will use on your
host system for your VM to isolate the processes and maps these to one core.

Hope that helps.

Cheers
Heiko

Am 22.09.2015 um 11:57 schrieb Abhishek Talwar:
> Hi Folks,
>
>
> I have a doubt regarding Vcpu that are assigned to an instance in
> OpenStack.
>
> When we say that we are assigning 5 Vcpus to an instance, does that
> mean that the instance will be using all those 5 vcpus together or it
> is on the load on it.
>
> So the question is are the Vcpus consecutively used or it is used one
> by one.
>
> Also if they are used one by one how can we get to know how many Vcpus
> is the VM currently using.
>
> Thanks and Regards
> Abhishek Talwar
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-- 
anynines.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/6c3ed2d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/6c3ed2d6/attachment.pgp>

From dbelova at mirantis.com  Tue Sep 22 13:01:20 2015
From: dbelova at mirantis.com (Dina Belova)
Date: Tue, 22 Sep 2015 16:01:20 +0300
Subject: [Openstack-operators] Fwd: [Large Deployments Team][Performance
 Team] New informal working group suggestion
In-Reply-To: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
References: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
Message-ID: <CACsCO2x7T_1qammu-cSi9j=apTTEeT4Zy7TwfiGT1-zptvk1UA@mail.gmail.com>

Hey, OpenStackers!

I'm writing to propose to organise new informal team to work specifically
on the OpenStack performance issues. This will be a sub team in already
existing Large Deployments Team, and I suppose it will be a good idea to
gather people interested in OpenStack performance in one room and identify
what issues are worrying contributors, what can be done and share results
of performance researches :)

So please volunteer to take part in this initiative. I hope it will be many
people interested and we'll be able to use cross-projects session slot
<http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and hold a
kick-off meeting.

I would like to apologise I'm writing to two mailing lists at the same
time, but I want to make sure that all possibly interested people will
notice the email.

Thanks and see you in Tokyo :)

Cheers,
Dina

-- 

Best regards,

Dina Belova

Senior Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/ee92f29f/attachment.html>

From mvanwink at rackspace.com  Tue Sep 22 13:46:01 2015
From: mvanwink at rackspace.com (Matt Van Winkle)
Date: Tue, 22 Sep 2015 13:46:01 +0000
Subject: [Openstack-operators] [Large Deployments Team][Performance
 Team] New informal working group suggestion
In-Reply-To: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
References: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
Message-ID: <D226C509.17B892%vw@rackspace.com>

Thanks, Dina!

For context to the rest of the LDT folks, Dina reached out to me about working on this under our umbrella for now.  It made sense until we understand if it's a large enough thing to live as its own working group because most of us have various performance concerns too.  So, like Public Clouds, we'll have to figure out how to integrate this sub group.

I suspect the time slot for Tokyo is already packed, so the work for the Performance subgroup may have to be informal or in other sessions, but I'll start working with Tom and the folks covering the session for me (since I won't be able to make it) on what we might be able to do.  I've also asked Dina to join the Oct meeting prior to the Summit so we can further discuss the sub team.

Thanks!
VW

From: Dina Belova <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>
Date: Tuesday, September 22, 2015 7:57 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [Large Deployments Team][Performance Team] New informal working group suggestion

Hey, OpenStackers!

I'm writing to propose to organise new informal team to work specifically on the OpenStack performance issues. This will be a sub team in already existing Large Deployments Team, and I suppose it will be a good idea to gather people interested in OpenStack performance in one room and identify what issues are worrying contributors, what can be done and share results of performance researches :)

So please volunteer to take part in this initiative. I hope it will be many people interested and we'll be able to use cross-projects session slot<http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and hold a kick-off meeting.

I would like to apologise I'm writing to two mailing lists at the same time, but I want to make sure that all possibly interested people will notice the email.

Thanks and see you in Tokyo :)

Cheers,
Dina

--

Best regards,

Dina Belova

Senior Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/9edf3d40/attachment.html>

From edgar.magana at workday.com  Tue Sep 22 14:34:09 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Tue, 22 Sep 2015 14:34:09 +0000
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <5600E16D.7040400@openstack.org>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
Message-ID: <A2DD06D2-8C48-4FD6-97E6-43B7FD6934DA@workday.com>

Tom,

In order to not mess up with your google doc, do you expect feedback directly on the doc or via email ML?

Edgar




On 9/21/15, 10:04 PM, "Tom Fifield" <tom at openstack.org> wrote:

>Hi all,
>
>I've started wrangling things toward a draft agenda.
>
>You can watch it live on Google Sheets at:
>
>https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>
>Comments and feedback welcome!
>
>Regards,
>
>
>Tom
>
>On 16/09/15 11:45, Tom Fifield wrote:
>> Last chance to provide your ideas for our design summit track.
>>
>> So far we are lacking:
>> * Lightning talks
>> * Working Groups
>> * General Sessions
>>
>> Starting next week we're going to prepare the draft agenda for
>> circulation and discussion. So, get in now. What would you like to
>> discuss with fellow ops and developers?
>>
>>
>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>> On 08/09/15 17:10, Tom Fifield wrote:
>>> Ping!
>>>
>>> This is your chance to provide input on our design summit track for
>>> Tokyo. Add your ideas on the etherpad below!
>>>
>>>
>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>
>>>
>>> On 03/09/15 03:27, Tom Fifield wrote:
>>>> Hi all,
>>>>
>>>> Thanks for those who made it to the recent meetup in Palo Alto. It was a
>>>> fantastic couple of days, and many are excited to get started on talking
>>>> about our ops track in the Tokyo design summit.
>>>>
>>>>
>>>> Recall that this is in addition to the operations and other conference
>>>> track's presentations. It's aimed at giving us a design-summit-style
>>>> place to congregate, swap best practices, ideas and give feedback.
>>>>
>>>>
>>>> As usual, we're working to act on the feedback from all past events to
>>>> make this one better than ever. One that we continue to work on is the
>>>> need to see action happen as a result of this event, so please - when
>>>> you are suggesting sessions in the below etherpad please try and phrase
>>>> them in a way that will probably result in things happening afterward.
>>>>
>>>>
>>>> **********************************************************************
>>>>
>>>> Please propose session ideas on:
>>>>
>>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>>
>>>> ensuring each session suggestion will have a result.
>>>>
>>>> **********************************************************************
>>>>
>>>>
>>>> The room allocations are still being worked out, but the current
>>>> thinking is that we will interleave general sessions and working groups
>>>> across Tuesday and Wednesday, to allow for attendance from ops in the
>>>> cross-project sessions.
>>>>
>>>>
>>>> More as it comes, and as always, further information about ops meetups
>>>> and notes from the past can be found on the wiki @:
>>>>
>>>> https://wiki.openstack.org/wiki/Operations/Meetups
>>>>
>>>> Finally, don't forget to register ASAP!
>>>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Tom
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From sean at coreitpro.com  Tue Sep 22 14:34:39 2015
From: sean at coreitpro.com (Sean M. Collins)
Date: Tue, 22 Sep 2015 14:34:39 +0000
Subject: [Openstack-operators] [openstack-dev] [Large Deployments
 Team][Performance Team] New informal working group suggestion
In-Reply-To: <D226C509.17B892%vw@rackspace.com>
References: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
 <D226C509.17B892%vw@rackspace.com>
Message-ID: <0000014ff57a5699-3c96f383-0d24-4d0d-9347-5dfbdd2e88f2-000000@email.amazonses.com>

To help kick off this topic, the Neutron team has been tracking some
performance profiling in this etherpad.

https://etherpad.openstack.org/p/router-scheduling-performance

-- 
Sean M. Collins


From tom at openstack.org  Tue Sep 22 14:42:40 2015
From: tom at openstack.org (Tom Fifield)
Date: Tue, 22 Sep 2015 22:42:40 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <A2DD06D2-8C48-4FD6-97E6-43B7FD6934DA@workday.com>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
 <A2DD06D2-8C48-4FD6-97E6-43B7FD6934DA@workday.com>
Message-ID: <560168E0.5090602@openstack.org>

ML :)

On 22/09/15 22:34, Edgar Magana wrote:
> Tom,
>
> In order to not mess up with your google doc, do you expect feedback directly on the doc or via email ML?
>
> Edgar
>
>
>
>
> On 9/21/15, 10:04 PM, "Tom Fifield" <tom at openstack.org> wrote:
>
>> Hi all,
>>
>> I've started wrangling things toward a draft agenda.
>>
>> You can watch it live on Google Sheets at:
>>
>> https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>>
>> Comments and feedback welcome!
>>
>> Regards,
>>
>>
>> Tom
>>
>> On 16/09/15 11:45, Tom Fifield wrote:
>>> Last chance to provide your ideas for our design summit track.
>>>
>>> So far we are lacking:
>>> * Lightning talks
>>> * Working Groups
>>> * General Sessions
>>>
>>> Starting next week we're going to prepare the draft agenda for
>>> circulation and discussion. So, get in now. What would you like to
>>> discuss with fellow ops and developers?
>>>
>>>
>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>> On 08/09/15 17:10, Tom Fifield wrote:
>>>> Ping!
>>>>
>>>> This is your chance to provide input on our design summit track for
>>>> Tokyo. Add your ideas on the etherpad below!
>>>>
>>>>
>>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>>
>>>>
>>>> On 03/09/15 03:27, Tom Fifield wrote:
>>>>> Hi all,
>>>>>
>>>>> Thanks for those who made it to the recent meetup in Palo Alto. It was a
>>>>> fantastic couple of days, and many are excited to get started on talking
>>>>> about our ops track in the Tokyo design summit.
>>>>>
>>>>>
>>>>> Recall that this is in addition to the operations and other conference
>>>>> track's presentations. It's aimed at giving us a design-summit-style
>>>>> place to congregate, swap best practices, ideas and give feedback.
>>>>>
>>>>>
>>>>> As usual, we're working to act on the feedback from all past events to
>>>>> make this one better than ever. One that we continue to work on is the
>>>>> need to see action happen as a result of this event, so please - when
>>>>> you are suggesting sessions in the below etherpad please try and phrase
>>>>> them in a way that will probably result in things happening afterward.
>>>>>
>>>>>
>>>>> **********************************************************************
>>>>>
>>>>> Please propose session ideas on:
>>>>>
>>>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>>>
>>>>> ensuring each session suggestion will have a result.
>>>>>
>>>>> **********************************************************************
>>>>>
>>>>>
>>>>> The room allocations are still being worked out, but the current
>>>>> thinking is that we will interleave general sessions and working groups
>>>>> across Tuesday and Wednesday, to allow for attendance from ops in the
>>>>> cross-project sessions.
>>>>>
>>>>>
>>>>> More as it comes, and as always, further information about ops meetups
>>>>> and notes from the past can be found on the wiki @:
>>>>>
>>>>> https://wiki.openstack.org/wiki/Operations/Meetups
>>>>>
>>>>> Finally, don't forget to register ASAP!
>>>>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From ignaziocassano at gmail.com  Tue Sep 22 16:15:26 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 22 Sep 2015 18:15:26 +0200
Subject: [Openstack-operators] openstack vmware
In-Reply-To: <92424B04-D4AC-492A-A805-83E302682CE0@create-net.org>
References: <CAB7j8cWuMhjbTwLUfkN0kcfSeAQn0Xx+=gU2e9dDWhBBQc9_dg@mail.gmail.com>
 <CAB7j8cWergV_=TP5AtLUU8kO8HQOGq7QVvAd-Oc-UU7jAougnA@mail.gmail.com>
 <CABfHRuv4QCGpKJ5GnQOA1NP1TrVEWo3_ChJJTu_pPCdqBS-qYA@mail.gmail.com>
 <CAB7j8cXMh9J2Hq+4HX6bGDDFfZqwUiqXEB-ZnKpYBbVDcqAOrQ@mail.gmail.com>
 <CABfHRutiQ20wcfp2zo1vP4qyz6gsvJjX4eSXF_bsbV5ZxSC86w@mail.gmail.com>
 <CAB7j8cXfEovWRHRdu02mbrDLDba7q1RLJGzPWpC+W9tRWD-0jg@mail.gmail.com>
 <3055F958-6A41-41DA-BB9A-32BD9C957BDD@vmware.com>
 <92424B04-D4AC-492A-A805-83E302682CE0@create-net.org>
Message-ID: <CAB7j8cWQXMwp6wg9qsD4A-tGT_dA4k5R0Nk8DNKYJaEnNg52xg@mail.gmail.com>

thanks all for your contribution on my request.
Ignazio
Il giorno 21/set/2015 22:42, "Federico Michele Facca" <ffacca at create-net.org>
ha scritto:

> Mark is right, the multi region approach, surely simplifies a lot the
> complexity of your deployment. Unless it is a needed feature for you to see
> multi hypervisor resources in a single view. All the rest - even though
> with additional complications - including multi "region" heat templates,
> multi region lbaas etc (using vpn across the regions), should work out.
>
> Again, it all depends on your requirements :)
>
> iFede - Fede's mobile edition
>
> > Il giorno 21 set 2015, alle ore 22:13, Mark Voelker <mvoelker at vmware.com>
> ha scritto:
> >
> > Ignazio,
> >
> >> I know there is a nova driver for vmware.
> >> I' like to know if glance, heat, ceilometer etc etc work with vmware.
> >
> >
> > There are VMware drivers for Nova, Neutron (NSX and DVS, though the
> latter supports far fewer features), Neutron LBaaS, Cinder, and Glance.
> Heat and Ceilometer also work fine.  You can find configuration guides here:
> >
> >
> http://docs.openstack.org/kilo/config-reference/content/vmware-vmdk-driver.html
> >
> > http://docs.openstack.org/kilo/config-reference/content/vmware.html
> >
> >
> http://docs.openstack.org/kilo/config-reference/content/vmware-glance-backend.html
> >
> >
> http://docs.openstack.org/kilo/config-reference/content/networking-plugin-vmware.html
> >
> >
> http://docs.openstack.org/kilo/config-reference/content/networking-plugin-nsx.html
> >
> >> As far is neutron is concerned, in a scenario where there are kvm and
> vmware nodes, must I have an nsx multihypervisor solution ?
> >> Must I insall nsx componenents on kvm nodes (a modified ovs version
> for kvm) ?
> >> On vmware must I install the vmware nsx or the multihypervisor version ?
> >
> > Not necessarily.  A common tactic for dealing with differing hypervisors
> (or for that matter, different networking or perhaps even storage
> solutions) is to deploy them into two separate regions: one for KVM and one
> for ESX.  If you?re not familiar with the regions concept in OpenStack,
> have a look here:
> >
> > http://docs.openstack.org/openstack-ops/content/scaling.html
> >
> > Essentially since these are separate API endpoints, you can have very
> different capabilities in each without having to worry about mixing and
> matching solutions.  So essentially you might have one region with ESX
> hypervisors, NSX for vSphere networking, and vSAN (or any other VMDK
> storage) for storage.  In the other region you might have KVM hypervisors
> with OVS for networking and NFS for storage.  Be aware that users must
> target their API calls to one region or the other though (since they are
> separate endpoints), and logical networks typically won?t stretch between
> regions.  Regions are often thought of as a construct for geographically
> diverse datacenters, but also work well as a means of segregation within a
> single DC.
> >
> > At the risk of being accused of advertising on a mailer alias (=p),
> since you appear to have an interest in the VMware hypervisor and network
> stack you may want to have a look at the VMware Integrated OpenStack
> distribution:
> >
> > http://www.vmware.com/products/openstack/
> >
> > Other distributions (including I believe Mirantis and HP) also offer
> support for VMware underpinnings:
> >
> >
> http://docs.hpcloud.com/#commercial/GA1/1.1commercial.install-GA-esx.html
> >
> https://www.mirantis.com/partners/mirantis-technology-partners/mirantis-partners-vmware/
> >
> > At Your Service,
> >
> > Mark T. Voelker
> >
> >
> >
> >> On Sep 21, 2015, at 1:44 PM, Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
> >>
> >> We would like to provide cloud infrastracture  multi hypervosor with
> sdn, multi tenancy, orchestration and self provisioning.
> >> I think openstack with kvm is a good  start point but we have  hunderds
> applications on vmware.
> >> A good compromise could be kvm and vmware with openstack but I am not
> sure it is a good idea because vmware seems to me limited in this scenario.
> >>
> >> Il giorno 21/set/2015 19:18, "Federico Michele Facca" <
> federico.facca at create-net.org> ha scritto:
> >> there is no a proper answer to your question (expecially if you don't
> provide a bit of a context :) i.e.
> >> what are you trying to achieve? what are your constraints?)
> >>
> >> In general, I doubt you can do many of the things you can do with
> OpenStack using vCenter, and probably also with vCloud... (and the other
> way around, there are things you can do with vCloud, you cannot do today
> with OpenStack) on the other hand, by pluging vCenter in OpenStack you can
> do many things that only vCenter can't achieve :)
> >>
> >>
> >>
> >> On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano <
> ignaziocassano at gmail.com> wrote:
> >> Many thanks Federico...
> >> So the question is: why should I use openstack with vmware ?
> >> Il giorno 21/set/2015 18:34, "Federico Michele Facca" <
> federico.facca at create-net.org> ha scritto:
> >> Hi Ignazio,
> >> I am not the greatest expert in my team on the topic, so there my be
> some mistakes (anyone feel free to correct :)), read my reply inline
> >>
> >> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano <
> ignaziocassano at gmail.com> wrote:
> >> Hi all, I' would like to know which openstack community edition
> components work with vmware.
> >> I know there is a nova driver for vmware.
> >>
> >>
> >> correct, basically it will act as a "proxy" toward vCenter
> >>
> >> I' like to know if glance, heat, ceilometer etc etc work with vmware.
> >>
> >> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't
> tested, but any implementation may reflect the fact that OS services for
> VMWare are proxies (i.e. it will see whatever is on the other side like a
> huge compute or a huge cinder)
> >>
> >> About glance you may have some limitations, since it supports so far
> (unless anything changed in Liberty) a single backend. actually we had
> issues in booting a vmware volume from an image (using swift as glance
> backend - it should work with no issue using the vmware storage, but then I
> guess you lose the multi hypervisor support).
> >>
> >>
> >> As far is neutron is concerned, in a scenario where there are kvm and
> vmware nodes, must I have an nsx multihypervisor solution ?
> >>
> >>
> >> I think you can use other drivers as well (actually we developed one
> for a customer). Or nova-network.
> >>
> >> Must I insall nsx componenents on kvm nodes (a modified ovs version
> for kvm) ?
> >>
> >> we didn't go for NSX solution, but I guess so.
> >> On vmware must I install the vmware nsx or the multihypervisor version ?
> >>
> >>
> >> yes multihpervisor one... I know there were rumors about an opens
> source release, but I hadn't any update on that.
> >>
> >>
> >> Regards,
> >> Federico
> >> Regards
> >> Ignazio
> >>
> >>
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >>
> >>
> >>
> >> --
> >> --
> >> Future Internet is closer than you think!
> >> http://www.fiware.org
> >>
> >> Official Mirantis partner for OpenStack Training
> >> https://www.create-net.org/community/openstack-training
> >>
> >> --
> >> Dr. Federico M. Facca
> >>
> >> CREATE-NET
> >> Via alla Cascata 56/D
> >> 38123 Povo Trento (Italy)
> >>
> >> P  +39 0461 312471
> >> M +39 334 6049758
> >> E  federico.facca at create-net.org
> >> T @chicco785
> >> W  www.create-net.org
> >>
> >>
> >>
> >> --
> >> --
> >> Future Internet is closer than you think!
> >> http://www.fiware.org
> >>
> >> Official Mirantis partner for OpenStack Training
> >> https://www.create-net.org/community/openstack-training
> >>
> >> --
> >> Dr. Federico M. Facca
> >>
> >> CREATE-NET
> >> Via alla Cascata 56/D
> >> 38123 Povo Trento (Italy)
> >>
> >> P  +39 0461 312471
> >> M +39 334 6049758
> >> E  federico.facca at create-net.org
> >> T @chicco785
> >> W  www.create-net.org
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/cb95cda0/attachment.html>

From matt at mattfischer.com  Tue Sep 22 16:32:54 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Tue, 22 Sep 2015 10:32:54 -0600
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <5600E16D.7040400@openstack.org>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
Message-ID: <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>

Tom,


Can you make the columns a bit wider? I don't seem to have permissions to
do so and I cant read everything. I've resorted to copying and pasting
stuff into another window so I can read it.

On Mon, Sep 21, 2015 at 11:04 PM, Tom Fifield <tom at openstack.org> wrote:

> Hi all,
>
> I've started wrangling things toward a draft agenda.
>
> You can watch it live on Google Sheets at:
>
>
> https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>
> Comments and feedback welcome!
>
> Regards,
>
>
> Tom
>
> On 16/09/15 11:45, Tom Fifield wrote:
>
>> Last chance to provide your ideas for our design summit track.
>>
>> So far we are lacking:
>> * Lightning talks
>> * Working Groups
>> * General Sessions
>>
>> Starting next week we're going to prepare the draft agenda for
>> circulation and discussion. So, get in now. What would you like to
>> discuss with fellow ops and developers?
>>
>>
>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>> On 08/09/15 17:10, Tom Fifield wrote:
>>
>>> Ping!
>>>
>>> This is your chance to provide input on our design summit track for
>>> Tokyo. Add your ideas on the etherpad below!
>>>
>>>
>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>
>>>
>>> On 03/09/15 03:27, Tom Fifield wrote:
>>>
>>>> Hi all,
>>>>
>>>> Thanks for those who made it to the recent meetup in Palo Alto. It was a
>>>> fantastic couple of days, and many are excited to get started on talking
>>>> about our ops track in the Tokyo design summit.
>>>>
>>>>
>>>> Recall that this is in addition to the operations and other conference
>>>> track's presentations. It's aimed at giving us a design-summit-style
>>>> place to congregate, swap best practices, ideas and give feedback.
>>>>
>>>>
>>>> As usual, we're working to act on the feedback from all past events to
>>>> make this one better than ever. One that we continue to work on is the
>>>> need to see action happen as a result of this event, so please - when
>>>> you are suggesting sessions in the below etherpad please try and phrase
>>>> them in a way that will probably result in things happening afterward.
>>>>
>>>>
>>>> **********************************************************************
>>>>
>>>> Please propose session ideas on:
>>>>
>>>> https://etherpad.openstack.org/p/TYO-ops-meetup
>>>>
>>>> ensuring each session suggestion will have a result.
>>>>
>>>> **********************************************************************
>>>>
>>>>
>>>> The room allocations are still being worked out, but the current
>>>> thinking is that we will interleave general sessions and working groups
>>>> across Tuesday and Wednesday, to allow for attendance from ops in the
>>>> cross-project sessions.
>>>>
>>>>
>>>> More as it comes, and as always, further information about ops meetups
>>>> and notes from the past can be found on the wiki @:
>>>>
>>>> https://wiki.openstack.org/wiki/Operations/Meetups
>>>>
>>>> Finally, don't forget to register ASAP!
>>>>
>>>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Tom
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/0a012354/attachment.html>

From klindgren at godaddy.com  Tue Sep 22 22:21:57 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Tue, 22 Sep 2015 22:21:57 +0000
Subject: [Openstack-operators] Operator Local Patches
In-Reply-To: <AC36B0CA-2D61-4538-9930-E0E452F13CD5@godaddy.com>
References: <AC36B0CA-2D61-4538-9930-E0E452F13CD5@godaddy.com>
Message-ID: <46F2FE26-945C-434F-894D-7BC5FC1C49B2@godaddy.com>

Hello all,

Friendly reminder: If you have local patches and haven't yet done so, please contribute to the etherpad at: https://etherpad.openstack.org/p/operator-local-patches

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Friday, September 18, 2015 at 4:35 PM
To: openstack-operators
Cc: Tom Fifield
Subject: Operator Local Patches

Hello Operators!

During the ops meetup in Palo Alto were we talking about sessions for Tokyo. A session that I purposed, that got a bunch of +1's,  was about local patches that operators were carrying.  From my experience this is done to either implement business logic,  fix assumptions in projects that do not apply to your implementation, implement business requirements that are not yet implemented in openstack, or fix scale related bugs.  What I would like to do is get a working group together to do the following:

1.) Document local patches that operators have (even those that are in gerrit right now waiting to be committed upstream)
2.) Figure out commonality in those patches
3.) Either upstream the common fixes to the appropriate projects or figure out if a hook can be added to allow people to run their code at that specific point
4.) ????
5.) Profit

To start this off, I have documented every patch, along with a description of what it does and why we did it (where needed), that GoDaddy is running [1].  What I am asking is that the operator community please update the etherpad with the patches that you are running, so that we have a good starting point for discussions in Tokyo and beyond.

[1] - https://etherpad.openstack.org/p/operator-local-patches
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/79b3090a/attachment.html>

From tom at openstack.org  Wed Sep 23 01:22:13 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 23 Sep 2015 09:22:13 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
 <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>
Message-ID: <5601FEC5.8070800@openstack.org>

Sorry about that - judicious column widening and wrapping applied!

On 23/09/15 00:32, Matt Fischer wrote:
> Tom,
>
>
> Can you make the columns a bit wider? I don't seem to have permissions
> to do so and I cant read everything. I've resorted to copying and
> pasting stuff into another window so I can read it.
>
> On Mon, Sep 21, 2015 at 11:04 PM, Tom Fifield <tom at openstack.org
> <mailto:tom at openstack.org>> wrote:
>
>     Hi all,
>
>     I've started wrangling things toward a draft agenda.
>
>     You can watch it live on Google Sheets at:
>
>     https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>
>     Comments and feedback welcome!
>
>     Regards,
>
>
>     Tom
>
>     On 16/09/15 11:45, Tom Fifield wrote:
>
>         Last chance to provide your ideas for our design summit track.
>
>         So far we are lacking:
>         * Lightning talks
>         * Working Groups
>         * General Sessions
>
>         Starting next week we're going to prepare the draft agenda for
>         circulation and discussion. So, get in now. What would you like to
>         discuss with fellow ops and developers?
>
>
>         https://etherpad.openstack.org/p/TYO-ops-meetup
>
>
>         Regards,
>
>
>         Tom
>
>         On 08/09/15 17:10, Tom Fifield wrote:
>
>             Ping!
>
>             This is your chance to provide input on our design summit
>             track for
>             Tokyo. Add your ideas on the etherpad below!
>
>
>             https://etherpad.openstack.org/p/TYO-ops-meetup
>
>
>             On 03/09/15 03:27, Tom Fifield wrote:
>
>                 Hi all,
>
>                 Thanks for those who made it to the recent meetup in
>                 Palo Alto. It was a
>                 fantastic couple of days, and many are excited to get
>                 started on talking
>                 about our ops track in the Tokyo design summit.
>
>
>                 Recall that this is in addition to the operations and
>                 other conference
>                 track's presentations. It's aimed at giving us a
>                 design-summit-style
>                 place to congregate, swap best practices, ideas and give
>                 feedback.
>
>
>                 As usual, we're working to act on the feedback from all
>                 past events to
>                 make this one better than ever. One that we continue to
>                 work on is the
>                 need to see action happen as a result of this event, so
>                 please - when
>                 you are suggesting sessions in the below etherpad please
>                 try and phrase
>                 them in a way that will probably result in things
>                 happening afterward.
>
>
>                 **********************************************************************
>
>                 Please propose session ideas on:
>
>                 https://etherpad.openstack.org/p/TYO-ops-meetup
>
>                 ensuring each session suggestion will have a result.
>
>                 **********************************************************************
>
>
>                 The room allocations are still being worked out, but the
>                 current
>                 thinking is that we will interleave general sessions and
>                 working groups
>                 across Tuesday and Wednesday, to allow for attendance
>                 from ops in the
>                 cross-project sessions.
>
>
>                 More as it comes, and as always, further information
>                 about ops meetups
>                 and notes from the past can be found on the wiki @:
>
>                 https://wiki.openstack.org/wiki/Operations/Meetups
>
>                 Finally, don't forget to register ASAP!
>                 http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>
>
>
>
>                 Regards,
>
>
>                 Tom
>
>                 _______________________________________________
>                 OpenStack-operators mailing list
>                 OpenStack-operators at lists.openstack.org
>                 <mailto:OpenStack-operators at lists.openstack.org>
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>             _______________________________________________
>             OpenStack-operators mailing list
>             OpenStack-operators at lists.openstack.org
>             <mailto:OpenStack-operators at lists.openstack.org>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>         _______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>



From tom at openstack.org  Wed Sep 23 01:28:57 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 23 Sep 2015 09:28:57 +0800
Subject: [Openstack-operators] User Survey - Deadline Sept 25th
In-Reply-To: <55F8E793.1080204@openstack.org>
References: <55F8E4AE.7060607@openstack.org> <55F8E793.1080204@openstack.org>
Message-ID: <56020059.2040304@openstack.org>

Take the Survey: http://www.openstack.org/user-survey

It's due on Friday!

On 16/09/15 11:52, Tom Fifield wrote:
> Copy and Paste Error Strikes Again!
>
> The deadline is (as the subject says):  ***September 25 at 23:59 UTC***.
> That is next Friday - get on it :)
>
> http://www.openstack.org/user-survey
>
>
> Regards,
>
> Tom
>
> On 16/09/15 11:40, Tom Fifield wrote:
>> Hi all,
>>
>> If you run OpenStack, build apps on it, or have customers with OpenStack
>> deployments, please take a few minutes to respond to the latest User
>> Survey or pass it along to your friends.
>>
>> Since 2013, the user survey has provided significant insight into what
>> people are deploying and how they're using OpenStack. You can see the
>> most recent results in these SuperUser Articles: [1][2][3].
>>
>> Please follow the link and instructions below to complete the User
>> Survey by ***Sep 25, 2015 at 23:00 UTC***. If you already completed the
>> survey, there's no need to start over. You can simply log back in to
>> update your Deployment Profile, as well as take the opportunity to
>> provide additional input. You need to do this to keep your past survey
>> responses active, but we hope you'll do it because we've made the survey
>> shorter and with more interesting questions ;)
>>
>>
>>
>> Take the Survey ( http://www.openstack.org/user-survey )
>>
>>
>> All of the information you provide is confidential to the Foundation and
>> User Committee and will be aggregated anonymously unless you clearly
>> indicate we can publish your organization?s profile.
>>
>> Remember you can hear directly from users and see the aggregate survey
>> findings by attending the next OpenStack Summit, October 27-30 in Tokyo
>> (http://www.openstack.org/summit).
>>
>> Thank you again for your support.
>>
>>
>> -Tom
>>
>>
>> [1]
>> http://superuser.openstack.org/articles/user-survey-identifies-leading-industries-and-business-drivers-for-openstack-adoption
>>
>>
>> [2]
>> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
>>
>>
>> [3]
>> http://superuser.openstack.org/articles/openstack-application-developers-share-insights
>>
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From joe at topjian.net  Wed Sep 23 04:02:48 2015
From: joe at topjian.net (Joe Topjian)
Date: Tue, 22 Sep 2015 22:02:48 -0600
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <5601FEC5.8070800@openstack.org>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
 <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>
 <5601FEC5.8070800@openstack.org>
Message-ID: <CA+y7hvg0KgiYqXuGYy0cX6WKeTiUV_cDKHPDN56Dn33CKNDmaA@mail.gmail.com>

Hi Tom,

As luck would have it, the sole session I'm doing in the Main Conference
clashes with the current time slot for Hypervisor Tuning. I see that Tim is
also listed as a moderator for that session, so I'm more than happy to let
him run it. However, if it's not asking much, I'd really like to be able to
attend that one, moderator or not. :)

Thanks,
Joe

On Tue, Sep 22, 2015 at 7:22 PM, Tom Fifield <tom at openstack.org> wrote:

> Sorry about that - judicious column widening and wrapping applied!
>
> On 23/09/15 00:32, Matt Fischer wrote:
>
>> Tom,
>>
>>
>> Can you make the columns a bit wider? I don't seem to have permissions
>> to do so and I cant read everything. I've resorted to copying and
>> pasting stuff into another window so I can read it.
>>
>> On Mon, Sep 21, 2015 at 11:04 PM, Tom Fifield <tom at openstack.org
>> <mailto:tom at openstack.org>> wrote:
>>
>>     Hi all,
>>
>>     I've started wrangling things toward a draft agenda.
>>
>>     You can watch it live on Google Sheets at:
>>
>>
>> https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>>
>>     Comments and feedback welcome!
>>
>>     Regards,
>>
>>
>>     Tom
>>
>>     On 16/09/15 11:45, Tom Fifield wrote:
>>
>>         Last chance to provide your ideas for our design summit track.
>>
>>         So far we are lacking:
>>         * Lightning talks
>>         * Working Groups
>>         * General Sessions
>>
>>         Starting next week we're going to prepare the draft agenda for
>>         circulation and discussion. So, get in now. What would you like to
>>         discuss with fellow ops and developers?
>>
>>
>>         https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>>         Regards,
>>
>>
>>         Tom
>>
>>         On 08/09/15 17:10, Tom Fifield wrote:
>>
>>             Ping!
>>
>>             This is your chance to provide input on our design summit
>>             track for
>>             Tokyo. Add your ideas on the etherpad below!
>>
>>
>>             https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>>             On 03/09/15 03:27, Tom Fifield wrote:
>>
>>                 Hi all,
>>
>>                 Thanks for those who made it to the recent meetup in
>>                 Palo Alto. It was a
>>                 fantastic couple of days, and many are excited to get
>>                 started on talking
>>                 about our ops track in the Tokyo design summit.
>>
>>
>>                 Recall that this is in addition to the operations and
>>                 other conference
>>                 track's presentations. It's aimed at giving us a
>>                 design-summit-style
>>                 place to congregate, swap best practices, ideas and give
>>                 feedback.
>>
>>
>>                 As usual, we're working to act on the feedback from all
>>                 past events to
>>                 make this one better than ever. One that we continue to
>>                 work on is the
>>                 need to see action happen as a result of this event, so
>>                 please - when
>>                 you are suggesting sessions in the below etherpad please
>>                 try and phrase
>>                 them in a way that will probably result in things
>>                 happening afterward.
>>
>>
>>
>> **********************************************************************
>>
>>                 Please propose session ideas on:
>>
>>                 https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>                 ensuring each session suggestion will have a result.
>>
>>
>> **********************************************************************
>>
>>
>>                 The room allocations are still being worked out, but the
>>                 current
>>                 thinking is that we will interleave general sessions and
>>                 working groups
>>                 across Tuesday and Wednesday, to allow for attendance
>>                 from ops in the
>>                 cross-project sessions.
>>
>>
>>                 More as it comes, and as always, further information
>>                 about ops meetups
>>                 and notes from the past can be found on the wiki @:
>>
>>                 https://wiki.openstack.org/wiki/Operations/Meetups
>>
>>                 Finally, don't forget to register ASAP!
>>
>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>
>>
>>
>>
>>                 Regards,
>>
>>
>>                 Tom
>>
>>                 _______________________________________________
>>                 OpenStack-operators mailing list
>>                 OpenStack-operators at lists.openstack.org
>>                 <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>             _______________________________________________
>>             OpenStack-operators mailing list
>>             OpenStack-operators at lists.openstack.org
>>             <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>         _______________________________________________
>>         OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>     _______________________________________________
>>     OpenStack-operators mailing list
>>     OpenStack-operators at lists.openstack.org
>>     <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/38cb4eda/attachment.html>

From siv.devops at gmail.com  Wed Sep 23 05:34:33 2015
From: siv.devops at gmail.com (pra devOPS)
Date: Tue, 22 Sep 2015 22:34:33 -0700
Subject: [Openstack-operators] adding a compute node
Message-ID: <CANvYX9VhcpgAOmSatncvTCz4Kr4XQ1PV-UVbT6-Yx7C+Z81BKA@mail.gmail.com>

Hi I have already openstack setup up and running withe 1 controller,1
network and 1 compute node.

with qemu hypervisor.

Now i wanted to add a kvm hypervisor, I have installed the kvm,novacompute
openvswitch,and nuetron agent in the compute node.

Created the br-int bridge in the compute node.

started the compute,nuetron agent and the ovs in the compute node, I am
able to see the compute's neutron agent in the network node.

When I boot a instance on the newly added compute it says spawning for ever
, The iptables are off on the compute.


any reasons or Do any body has steps to add a compute to the existing setup?


Thanks,
Dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150922/87b96f89/attachment.html>

From Tim.Bell at cern.ch  Wed Sep 23 06:25:33 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Wed, 23 Sep 2015 06:25:33 +0000
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <CA+y7hvg0KgiYqXuGYy0cX6WKeTiUV_cDKHPDN56Dn33CKNDmaA@mail.gmail.com>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
 <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>
 <5601FEC5.8070800@openstack.org>
 <CA+y7hvg0KgiYqXuGYy0cX6WKeTiUV_cDKHPDN56Dn33CKNDmaA@mail.gmail.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A45F5E3@CERNXCHG41.cern.ch>

I?d like Joe there too :) Can we re-schedule that one ?

 

Tim

 

From: Joe Topjian [mailto:joe at topjian.net] 
Sent: 23 September 2015 06:03
To: Tom Fifield <tom at openstack.org>
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks - Draft Agenda

 

Hi Tom,

 

As luck would have it, the sole session I'm doing in the Main Conference clashes with the current time slot for Hypervisor Tuning. I see that Tim is also listed as a moderator for that session, so I'm more than happy to let him run it. However, if it's not asking much, I'd really like to be able to attend that one, moderator or not. :)

 

Thanks,

Joe

 

On Tue, Sep 22, 2015 at 7:22 PM, Tom Fifield <tom at openstack.org <mailto:tom at openstack.org> > wrote:

Sorry about that - judicious column widening and wrapping applied!

On 23/09/15 00:32, Matt Fischer wrote:

Tom,


Can you make the columns a bit wider? I don't seem to have permissions
to do so and I cant read everything. I've resorted to copying and
pasting stuff into another window so I can read it.

On Mon, Sep 21, 2015 at 11:04 PM, Tom Fifield <tom at openstack.org <mailto:tom at openstack.org> 

<mailto:tom at openstack.org <mailto:tom at openstack.org> >> wrote:

    Hi all,

    I've started wrangling things toward a draft agenda.

    You can watch it live on Google Sheets at:

    https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842

    Comments and feedback welcome!

    Regards,


    Tom

    On 16/09/15 11:45, Tom Fifield wrote:

        Last chance to provide your ideas for our design summit track.

        So far we are lacking:
        * Lightning talks
        * Working Groups
        * General Sessions

        Starting next week we're going to prepare the draft agenda for
        circulation and discussion. So, get in now. What would you like to
        discuss with fellow ops and developers?


        https://etherpad.openstack.org/p/TYO-ops-meetup


        Regards,


        Tom

        On 08/09/15 17:10, Tom Fifield wrote:

            Ping!

            This is your chance to provide input on our design summit
            track for
            Tokyo. Add your ideas on the etherpad below!


            https://etherpad.openstack.org/p/TYO-ops-meetup


            On 03/09/15 03:27, Tom Fifield wrote:

                Hi all,

                Thanks for those who made it to the recent meetup in
                Palo Alto. It was a
                fantastic couple of days, and many are excited to get
                started on talking
                about our ops track in the Tokyo design summit.


                Recall that this is in addition to the operations and
                other conference
                track's presentations. It's aimed at giving us a
                design-summit-style
                place to congregate, swap best practices, ideas and give
                feedback.


                As usual, we're working to act on the feedback from all
                past events to
                make this one better than ever. One that we continue to
                work on is the
                need to see action happen as a result of this event, so
                please - when
                you are suggesting sessions in the below etherpad please
                try and phrase
                them in a way that will probably result in things
                happening afterward.


                **********************************************************************

                Please propose session ideas on:

                https://etherpad.openstack.org/p/TYO-ops-meetup

                ensuring each session suggestion will have a result.

                **********************************************************************


                The room allocations are still being worked out, but the
                current
                thinking is that we will interleave general sessions and
                working groups
                across Tuesday and Wednesday, to allow for attendance
                from ops in the
                cross-project sessions.


                More as it comes, and as always, further information
                about ops meetups
                and notes from the past can be found on the wiki @:

                https://wiki.openstack.org/wiki/Operations/Meetups

                Finally, don't forget to register ASAP!
                http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598




                Regards,


                Tom

                _______________________________________________
                OpenStack-operators mailing list
                OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 

                <mailto:OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> >
                http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



            _______________________________________________
            OpenStack-operators mailing list
            OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
            <mailto:OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> >
            http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



        _______________________________________________
        OpenStack-operators mailing list
        OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
        <mailto:OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> >
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



    _______________________________________________
    OpenStack-operators mailing list
    OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
    <mailto:OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> >
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/d33a4fa7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/d33a4fa7/attachment-0001.bin>

From hitgwt at 163.com  Wed Sep 23 06:37:22 2015
From: hitgwt at 163.com (=?GBK?B?uPDOxMzD?=)
Date: Wed, 23 Sep 2015 14:37:22 +0800 (CST)
Subject: [Openstack-operators] adding a compute node
In-Reply-To: <CANvYX9VhcpgAOmSatncvTCz4Kr4XQ1PV-UVbT6-Yx7C+Z81BKA@mail.gmail.com>
References: <CANvYX9VhcpgAOmSatncvTCz4Kr4XQ1PV-UVbT6-Yx7C+Z81BKA@mail.gmail.com>
Message-ID: <2ee05c22.b430.14ff8ebbb8e.Coremail.hitgwt@163.com>



If your compute node is a virtual machine,such as kvm,you can just clone the compute node, and then boot it, an change some configuritions,such as ip address,hostname,hosts file, nova.conf  neutron.conf ,etc.
If your compute node is a physical machine,just add a new compute node ,and do all operations like the first one.





At 2015-09-23 13:34:33, "pra devOPS" <siv.devops at gmail.com> wrote:

Hi I have already openstack setup up and running withe 1 controller,1 network and 1 compute node.


with qemu hypervisor.


Now i wanted to add a kvm hypervisor, I have installed the kvm,novacompute openvswitch,and nuetron agent in the compute node.


Created the br-int bridge in the compute node.


started the compute,nuetron agent and the ovs in the compute node, I am able to see the compute's neutron agent in the network node.


When I boot a instance on the newly added compute it says spawning for ever , The iptables are off on the compute.




any reasons or Do any body has steps to add a compute to the existing setup?




Thanks,
Dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/6dfe0e25/attachment.html>

From tom at openstack.org  Wed Sep 23 07:33:25 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 23 Sep 2015 15:33:25 +0800
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A45F5E3@CERNXCHG41.cern.ch>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
 <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>
 <5601FEC5.8070800@openstack.org>
 <CA+y7hvg0KgiYqXuGYy0cX6WKeTiUV_cDKHPDN56Dn33CKNDmaA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A45F5E3@CERNXCHG41.cern.ch>
Message-ID: <560255C5.1040104@openstack.org>

Moved it to a day earlier.


Regards,


Tom

On 23/09/15 14:25, Tim Bell wrote:
> I???d like Joe there too JCan we re-schedule that one ?
>
> Tim
>
> *From:*Joe Topjian [mailto:joe at topjian.net]
> *Sent:* 23 September 2015 06:03
> *To:* Tom Fifield <tom at openstack.org>
> *Cc:* openstack-operators at lists.openstack.org
> *Subject:* Re: [Openstack-operators] Tokyo Summit Ops Design Summit
> Tracks - Draft Agenda
>
> Hi Tom,
>
> As luck would have it, the sole session I'm doing in the Main Conference
> clashes with the current time slot for Hypervisor Tuning. I see that Tim
> is also listed as a moderator for that session, so I'm more than happy
> to let him run it. However, if it's not asking much, I'd really like to
> be able to attend that one, moderator or not. :)
>
> Thanks,
>
> Joe
>
> On Tue, Sep 22, 2015 at 7:22 PM, Tom Fifield <tom at openstack.org
> <mailto:tom at openstack.org>> wrote:
>
>     Sorry about that - judicious column widening and wrapping applied!
>
>     On 23/09/15 00:32, Matt Fischer wrote:
>
>         Tom,
>
>
>         Can you make the columns a bit wider? I don't seem to have
>         permissions
>         to do so and I cant read everything. I've resorted to copying and
>         pasting stuff into another window so I can read it.
>
>         On Mon, Sep 21, 2015 at 11:04 PM, Tom Fifield <tom at openstack.org
>         <mailto:tom at openstack.org>
>
>         <mailto:tom at openstack.org <mailto:tom at openstack.org>>> wrote:
>
>              Hi all,
>
>              I've started wrangling things toward a draft agenda.
>
>              You can watch it live on Google Sheets at:
>
>         https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>
>              Comments and feedback welcome!
>
>              Regards,
>
>
>              Tom
>
>              On 16/09/15 11:45, Tom Fifield wrote:
>
>                  Last chance to provide your ideas for our design summit
>         track.
>
>                  So far we are lacking:
>                  * Lightning talks
>                  * Working Groups
>                  * General Sessions
>
>                  Starting next week we're going to prepare the draft
>         agenda for
>                  circulation and discussion. So, get in now. What would
>         you like to
>                  discuss with fellow ops and developers?
>
>
>         https://etherpad.openstack.org/p/TYO-ops-meetup
>
>
>                  Regards,
>
>
>                  Tom
>
>                  On 08/09/15 17:10, Tom Fifield wrote:
>
>                      Ping!
>
>                      This is your chance to provide input on our design
>         summit
>                      track for
>                      Tokyo. Add your ideas on the etherpad below!
>
>
>         https://etherpad.openstack.org/p/TYO-ops-meetup
>
>
>                      On 03/09/15 03:27, Tom Fifield wrote:
>
>                          Hi all,
>
>                          Thanks for those who made it to the recent
>         meetup in
>                          Palo Alto. It was a
>                          fantastic couple of days, and many are excited
>         to get
>                          started on talking
>                          about our ops track in the Tokyo design summit.
>
>
>                          Recall that this is in addition to the
>         operations and
>                          other conference
>                          track's presentations. It's aimed at giving us a
>                          design-summit-style
>                          place to congregate, swap best practices, ideas
>         and give
>                          feedback.
>
>
>                          As usual, we're working to act on the feedback
>         from all
>                          past events to
>                          make this one better than ever. One that we
>         continue to
>                          work on is the
>                          need to see action happen as a result of this
>         event, so
>                          please - when
>                          you are suggesting sessions in the below
>         etherpad please
>                          try and phrase
>                          them in a way that will probably result in things
>                          happening afterward.
>
>
>
>         **********************************************************************
>
>                          Please propose session ideas on:
>
>         https://etherpad.openstack.org/p/TYO-ops-meetup
>
>                          ensuring each session suggestion will have a
>         result.
>
>
>         **********************************************************************
>
>
>                          The room allocations are still being worked
>         out, but the
>                          current
>                          thinking is that we will interleave general
>         sessions and
>                          working groups
>                          across Tuesday and Wednesday, to allow for
>         attendance
>                          from ops in the
>                          cross-project sessions.
>
>
>                          More as it comes, and as always, further
>         information
>                          about ops meetups
>                          and notes from the past can be found on the wiki @:
>
>         https://wiki.openstack.org/wiki/Operations/Meetups
>
>                          Finally, don't forget to register ASAP!
>         http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>
>
>
>
>                          Regards,
>
>
>                          Tom
>
>                          _______________________________________________
>                          OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>
>                          <mailto:OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>                      _______________________________________________
>                      OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>                      <mailto:OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>                  _______________________________________________
>                  OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>                  <mailto:OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>              _______________________________________________
>              OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>              <mailto:OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



From joe at topjian.net  Wed Sep 23 14:58:34 2015
From: joe at topjian.net (Joe Topjian)
Date: Wed, 23 Sep 2015 08:58:34 -0600
Subject: [Openstack-operators] Tokyo Summit Ops Design Summit Tracks -
 Draft Agenda
In-Reply-To: <560255C5.1040104@openstack.org>
References: <55E74D8F.9020203@openstack.org> <55EEA610.30802@openstack.org>
 <55F8E5E3.1030502@openstack.org> <5600E16D.7040400@openstack.org>
 <CAHr1CO_HpqQdNqwOjzR6QO9Ygm0Lrd6jkTLR5TYZX3Fi1x14bQ@mail.gmail.com>
 <5601FEC5.8070800@openstack.org>
 <CA+y7hvg0KgiYqXuGYy0cX6WKeTiUV_cDKHPDN56Dn33CKNDmaA@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A45F5E3@CERNXCHG41.cern.ch>
 <560255C5.1040104@openstack.org>
Message-ID: <CA+y7hviK-t8tMiB1c-fc_nGJAXzn=MscN0EjTUhNqVsn7DYXcw@mail.gmail.com>

Thanks, guys!

On Wed, Sep 23, 2015 at 1:33 AM, Tom Fifield <tom at openstack.org> wrote:

> Moved it to a day earlier.
>
>
> Regards,
>
>
> Tom
>
> On 23/09/15 14:25, Tim Bell wrote:
>
>> I???d like Joe there too JCan we re-schedule that one ?
>>
>> Tim
>>
>> *From:*Joe Topjian [mailto:joe at topjian.net]
>> *Sent:* 23 September 2015 06:03
>> *To:* Tom Fifield <tom at openstack.org>
>> *Cc:* openstack-operators at lists.openstack.org
>> *Subject:* Re: [Openstack-operators] Tokyo Summit Ops Design Summit
>> Tracks - Draft Agenda
>>
>> Hi Tom,
>>
>> As luck would have it, the sole session I'm doing in the Main Conference
>> clashes with the current time slot for Hypervisor Tuning. I see that Tim
>> is also listed as a moderator for that session, so I'm more than happy
>> to let him run it. However, if it's not asking much, I'd really like to
>> be able to attend that one, moderator or not. :)
>>
>> Thanks,
>>
>> Joe
>>
>> On Tue, Sep 22, 2015 at 7:22 PM, Tom Fifield <tom at openstack.org
>> <mailto:tom at openstack.org>> wrote:
>>
>>     Sorry about that - judicious column widening and wrapping applied!
>>
>>     On 23/09/15 00:32, Matt Fischer wrote:
>>
>>         Tom,
>>
>>
>>         Can you make the columns a bit wider? I don't seem to have
>>         permissions
>>         to do so and I cant read everything. I've resorted to copying and
>>         pasting stuff into another window so I can read it.
>>
>>         On Mon, Sep 21, 2015 at 11:04 PM, Tom Fifield <tom at openstack.org
>>         <mailto:tom at openstack.org>
>>
>>         <mailto:tom at openstack.org <mailto:tom at openstack.org>>> wrote:
>>
>>              Hi all,
>>
>>              I've started wrangling things toward a draft agenda.
>>
>>              You can watch it live on Google Sheets at:
>>
>>
>> https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=1480678842
>>
>>              Comments and feedback welcome!
>>
>>              Regards,
>>
>>
>>              Tom
>>
>>              On 16/09/15 11:45, Tom Fifield wrote:
>>
>>                  Last chance to provide your ideas for our design summit
>>         track.
>>
>>                  So far we are lacking:
>>                  * Lightning talks
>>                  * Working Groups
>>                  * General Sessions
>>
>>                  Starting next week we're going to prepare the draft
>>         agenda for
>>                  circulation and discussion. So, get in now. What would
>>         you like to
>>                  discuss with fellow ops and developers?
>>
>>
>>         https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>>                  Regards,
>>
>>
>>                  Tom
>>
>>                  On 08/09/15 17:10, Tom Fifield wrote:
>>
>>                      Ping!
>>
>>                      This is your chance to provide input on our design
>>         summit
>>                      track for
>>                      Tokyo. Add your ideas on the etherpad below!
>>
>>
>>         https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>
>>                      On 03/09/15 03:27, Tom Fifield wrote:
>>
>>                          Hi all,
>>
>>                          Thanks for those who made it to the recent
>>         meetup in
>>                          Palo Alto. It was a
>>                          fantastic couple of days, and many are excited
>>         to get
>>                          started on talking
>>                          about our ops track in the Tokyo design summit.
>>
>>
>>                          Recall that this is in addition to the
>>         operations and
>>                          other conference
>>                          track's presentations. It's aimed at giving us a
>>                          design-summit-style
>>                          place to congregate, swap best practices, ideas
>>         and give
>>                          feedback.
>>
>>
>>                          As usual, we're working to act on the feedback
>>         from all
>>                          past events to
>>                          make this one better than ever. One that we
>>         continue to
>>                          work on is the
>>                          need to see action happen as a result of this
>>         event, so
>>                          please - when
>>                          you are suggesting sessions in the below
>>         etherpad please
>>                          try and phrase
>>                          them in a way that will probably result in things
>>                          happening afterward.
>>
>>
>>
>>
>> **********************************************************************
>>
>>                          Please propose session ideas on:
>>
>>         https://etherpad.openstack.org/p/TYO-ops-meetup
>>
>>                          ensuring each session suggestion will have a
>>         result.
>>
>>
>>
>> **********************************************************************
>>
>>
>>                          The room allocations are still being worked
>>         out, but the
>>                          current
>>                          thinking is that we will interleave general
>>         sessions and
>>                          working groups
>>                          across Tuesday and Wednesday, to allow for
>>         attendance
>>                          from ops in the
>>                          cross-project sessions.
>>
>>
>>                          More as it comes, and as always, further
>>         information
>>                          about ops meetups
>>                          and notes from the past can be found on the wiki
>> @:
>>
>>         https://wiki.openstack.org/wiki/Operations/Meetups
>>
>>                          Finally, don't forget to register ASAP!
>>
>> http://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598
>>
>>
>>
>>
>>                          Regards,
>>
>>
>>                          Tom
>>
>>                          _______________________________________________
>>                          OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>
>>                          <mailto:OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>                      _______________________________________________
>>                      OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>                      <mailto:OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>                  _______________________________________________
>>                  OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>                  <mailto:OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>              _______________________________________________
>>              OpenStack-operators mailing list
>>         OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>
>>              <mailto:OpenStack-operators at lists.openstack.org
>>         <mailto:OpenStack-operators at lists.openstack.org>>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>     _______________________________________________
>>     OpenStack-operators mailing list
>>     OpenStack-operators at lists.openstack.org
>>     <mailto:OpenStack-operators at lists.openstack.org>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/32393518/attachment.html>

From klindgren at godaddy.com  Wed Sep 23 18:32:36 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Wed, 23 Sep 2015 18:32:36 +0000
Subject: [Openstack-operators] [Large Deployments Team][Performance
 Team] New informal working group suggestion
Message-ID: <D75DC775-5E3E-44E9-BC86-EB724DE253F5@godaddy.com>

Dina,

Do we have a place to put things (etherpad) that we are seeing performance issues with?  I know we are seeing issues with CPU load under nova-conductor as well as some stuff with the neutron API timing out (seems like it never responds to the request (no log entry on the neutron side).

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Matt Van Winkle
Date: Tuesday, September 22, 2015 at 7:46 AM
To: Dina Belova, OpenStack Development Mailing List, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
Subject: Re: [Openstack-operators] [Large Deployments Team][Performance Team] New informal working group suggestion

Thanks, Dina!

For context to the rest of the LDT folks, Dina reached out to me about working on this under our umbrella for now.  It made sense until we understand if it's a large enough thing to live as its own working group because most of us have various performance concerns too.  So, like Public Clouds, we'll have to figure out how to integrate this sub group.

I suspect the time slot for Tokyo is already packed, so the work for the Performance subgroup may have to be informal or in other sessions, but I'll start working with Tom and the folks covering the session for me (since I won't be able to make it) on what we might be able to do.  I've also asked Dina to join the Oct meeting prior to the Summit so we can further discuss the sub team.

Thanks!
VW

From: Dina Belova <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>
Date: Tuesday, September 22, 2015 7:57 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [Large Deployments Team][Performance Team] New informal working group suggestion

Hey, OpenStackers!

I'm writing to propose to organise new informal team to work specifically on the OpenStack performance issues. This will be a sub team in already existing Large Deployments Team, and I suppose it will be a good idea to gather people interested in OpenStack performance in one room and identify what issues are worrying contributors, what can be done and share results of performance researches :)

So please volunteer to take part in this initiative. I hope it will be many people interested and we'll be able to use cross-projects session slot<http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and hold a kick-off meeting.

I would like to apologise I'm writing to two mailing lists at the same time, but I want to make sure that all possibly interested people will notice the email.

Thanks and see you in Tokyo :)

Cheers,
Dina

--

Best regards,

Dina Belova

Senior Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/471b3b22/attachment.html>

From dbelova at mirantis.com  Wed Sep 23 19:42:34 2015
From: dbelova at mirantis.com (Dina Belova)
Date: Wed, 23 Sep 2015 22:42:34 +0300
Subject: [Openstack-operators] [Large Deployments Team][Performance
 Team] New informal working group suggestion
In-Reply-To: <D75DC775-5E3E-44E9-BC86-EB724DE253F5@godaddy.com>
References: <D75DC775-5E3E-44E9-BC86-EB724DE253F5@godaddy.com>
Message-ID: <CACsCO2zJiUoNYCDWwn5V52dBmXjVq9k9uQNxXz2CrG_F5-e8Lg@mail.gmail.com>

Kris,

I've created a ether pad - we can fill it with data before the summit and
discuss them in Tokyo.
https://etherpad.openstack.org/p/openstack-performance-issues

Cheers,
Dina

On Wed, Sep 23, 2015 at 9:32 PM, Kris G. Lindgren <klindgren at godaddy.com>
wrote:

> Dina,
>
> Do we have a place to put things (etherpad) that we are seeing performance
> issues with?  I know we are seeing issues with CPU load under
> nova-conductor as well as some stuff with the neutron API timing out (seems
> like it never responds to the request (no log entry on the neutron side).
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Matt Van Winkle
> Date: Tuesday, September 22, 2015 at 7:46 AM
> To: Dina Belova, OpenStack Development Mailing List, "
> openstack-operators at lists.openstack.org"
> Subject: Re: [Openstack-operators] [Large Deployments Team][Performance
> Team] New informal working group suggestion
>
> Thanks, Dina!
>
> For context to the rest of the LDT folks, Dina reached out to me about
> working on this under our umbrella for now.  It made sense until we
> understand if it's a large enough thing to live as its own working group
> because most of us have various performance concerns too.  So, like Public
> Clouds, we'll have to figure out how to integrate this sub group.
>
> I suspect the time slot for Tokyo is already packed, so the work for the
> Performance subgroup may have to be informal or in other sessions, but I'll
> start working with Tom and the folks covering the session for me (since I
> won't be able to make it) on what we might be able to do.  I've also asked
> Dina to join the Oct meeting prior to the Summit so we can further discuss
> the sub team.
>
> Thanks!
> VW
>
> From: Dina Belova <dbelova at mirantis.com>
> Date: Tuesday, September 22, 2015 7:57 AM
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>,
> "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: [Large Deployments Team][Performance Team] New informal working
> group suggestion
>
> Hey, OpenStackers!
>
> I'm writing to propose to organise new informal team to work specifically
> on the OpenStack performance issues. This will be a sub team in already
> existing Large Deployments Team, and I suppose it will be a good idea to
> gather people interested in OpenStack performance in one room and identify
> what issues are worrying contributors, what can be done and share results
> of performance researches :)
>
> So please volunteer to take part in this initiative. I hope it will be
> many people interested and we'll be able to use cross-projects session
> slot <http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and
> hold a kick-off meeting.
>
> I would like to apologise I'm writing to two mailing lists at the same
> time, but I want to make sure that all possibly interested people will
> notice the email.
>
> Thanks and see you in Tokyo :)
>
> Cheers,
> Dina
>
> --
>
> Best regards,
>
> Dina Belova
>
> Senior Software Engineer
>
> Mirantis Inc.
>
>


-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/a7180a45/attachment.html>

From josephbajin at gmail.com  Wed Sep 23 20:40:58 2015
From: josephbajin at gmail.com (Joseph Bajin)
Date: Wed, 23 Sep 2015 16:40:58 -0400
Subject: [Openstack-operators] [Tools/Monitoring] Meeting Notes from
 Operators Tools and Monitoring Working Group
Message-ID: <CAGm6i3kqtemB6YJy0DfTSeaos8wEDrW1K9bBnA_Apg48GbgzvQ@mail.gmail.com>

Operators,

The Operators Tools and Monitoring Working Group met at its new time 1900
UTC today.

Meeting notes can be found here:
    * https://etherpad.openstack.org/p/ops-tools-monitoring-agenda-20150923

We also have a wiki page that we are updating which can be found here:
     * https://wiki.openstack.org/wiki/Operators_Tools_and_Monitoring

I had some great help today getting some organization from some experienced
operators/contributors, so I wanted to say thanks to those guys.

Hope to see more of you at our next meeting which is:  Wednesday - October
7th @ 1900 hrs (3pm Eastern/12pm pacific)

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/99a3b60f/attachment.html>

From mriedem at linux.vnet.ibm.com  Wed Sep 23 20:49:49 2015
From: mriedem at linux.vnet.ibm.com (Matt Riedemann)
Date: Wed, 23 Sep 2015 15:49:49 -0500
Subject: [Openstack-operators] Potential deprecation of
	cinder.cross_az_attach option in nova
Message-ID: <5603106D.5000008@linux.vnet.ibm.com>

I wanted to bring this to the attention of the operators mailing list in 
case someone is relying on the cinder.cross_az_attach.

There is a -dev thread here [1] that started this discussion.  That led 
to a change proposed to deprecate the cinder.cross_az_attach option in 
nova [2].

This is for deprecation in mitaka and removal in N.  If this affects 
you, please speak up in the mailing list or in the review.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html
[2] https://review.openstack.org/#/c/226977/

-- 

Thanks,

Matt Riedemann



From edgar.magana at workday.com  Wed Sep 23 20:51:09 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Wed, 23 Sep 2015 20:51:09 +0000
Subject: [Openstack-operators] [Tools/Monitoring] Meeting Notes from
 Operators Tools and Monitoring Working Group
In-Reply-To: <CAGm6i3kqtemB6YJy0DfTSeaos8wEDrW1K9bBnA_Apg48GbgzvQ@mail.gmail.com>
References: <CAGm6i3kqtemB6YJy0DfTSeaos8wEDrW1K9bBnA_Apg48GbgzvQ@mail.gmail.com>
Message-ID: <8ADFC687-C6E0-4032-A902-671DD1A39F9D@workday.com>

My apologies but I could not attend it this time. I will add it to my calendar for future ones.

Thanks,

Edgar

From: Joseph Bajin
Date: Wednesday, September 23, 2015 at 1:40 PM
To: OpenStack Operators
Subject: [Openstack-operators] [Tools/Monitoring] Meeting Notes from Operators Tools and Monitoring Working Group

Operators,

The Operators Tools and Monitoring Working Group met at its new time 1900 UTC today.

Meeting notes can be found here:
    * https://etherpad.openstack.org/p/ops-tools-monitoring-agenda-20150923

We also have a wiki page that we are updating which can be found here:
     * https://wiki.openstack.org/wiki/Operators_Tools_and_Monitoring

I had some great help today getting some organization from some experienced operators/contributors, so I wanted to say thanks to those guys.

Hope to see more of you at our next meeting which is:  Wednesday - October 7th @ 1900 hrs (3pm Eastern/12pm pacific)

--Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150923/2fd4319a/attachment.html>

From sorrison at gmail.com  Wed Sep 23 23:27:30 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Thu, 24 Sep 2015 09:27:30 +1000
Subject: [Openstack-operators] Potential deprecation of
	cinder.cross_az_attach option in nova
In-Reply-To: <5603106D.5000008@linux.vnet.ibm.com>
References: <5603106D.5000008@linux.vnet.ibm.com>
Message-ID: <050F747A-A466-48BE-B5A1-AA4E1AB38BBD@gmail.com>

We very much rely on this and I see this is already merged! Great another patch I have to manage locally.

I don?t understand what the confusion is. We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone.

We don?t want people attaching a volume from one zone to another as the network won?t allow that as the zones are in different network domains and different data centres.

I will reply in the mailing list post on the dev channel but it seems it?s too late.

Sam



> On 24 Sep 2015, at 6:49 am, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> 
> I wanted to bring this to the attention of the operators mailing list in case someone is relying on the cinder.cross_az_attach.
> 
> There is a -dev thread here [1] that started this discussion.  That led to a change proposed to deprecate the cinder.cross_az_attach option in nova [2].
> 
> This is for deprecation in mitaka and removal in N.  If this affects you, please speak up in the mailing list or in the review.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html
> [2] https://review.openstack.org/#/c/226977/
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From hitgwt at 163.com  Thu Sep 24 03:10:56 2015
From: hitgwt at 163.com (=?GBK?B?uPDOxMzD?=)
Date: Thu, 24 Sep 2015 11:10:56 +0800 (CST)
Subject: [Openstack-operators] nova-docker
Message-ID: <30a8e932.7c92.14ffd55197e.Coremail.hitgwt@163.com>

How to install nova-docker? Can anyone help me? Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/5529772e/attachment.html>

From ansh.prat at gmail.com  Thu Sep 24 04:11:52 2015
From: ansh.prat at gmail.com (Anshu Prateek)
Date: Thu, 24 Sep 2015 04:11:52 +0000
Subject: [Openstack-operators] nova-docker
In-Reply-To: <30a8e932.7c92.14ffd55197e.Coremail.hitgwt@163.com>
References: <30a8e932.7c92.14ffd55197e.Coremail.hitgwt@163.com>
Message-ID: <CAK3Kwn6-kXkhMbMevYRnwwz2gsycgSv=_qO=vXH0BVDWkXZUag@mail.gmail.com>

Hi,

Have you checked
https://wiki.openstack.org/wiki/Docker#Configure_an_existing_OpenStack_installation_to_enable_Docker
?

regards
Anshu Prateek

On Thu, 24 Sep 2015 at 08:42 ??? <hitgwt at 163.com> wrote:

> How to install nova-docker? Can anyone help me? Thanks
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-- 
regards
Anshu Prateek
+91.991.610.2967
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/fe9da48c/attachment.html>

From openstack at mikebeauty.com  Thu Sep 24 09:01:24 2015
From: openstack at mikebeauty.com (Miko Bello)
Date: Thu, 24 Sep 2015 11:01:24 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
Message-ID: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>




Hi Folks,i would like to know if anybody has tried to implement a neutron solution with vsphere without using NSX-like solutions.
I mean, my lab environment is composed of :


?- 1 network node ( neutron )
?- 1 controller node
?- 2 compute node ( kvm)
?- 1?compute node linked to a cluster vsphere 6.0
?
i tried, without success ;( to deploy an instance on vsphere node with a network configuration of type VLAN; (?obviously, in this configuration,i have not the ambition of a ovs solution type :)  )
so my questions are: it's' possible to implement a network neutron solution of type VLAN ? if yes how can i do?
Thanks in advantage.
Miko Bello


 













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/682fc262/attachment.html>

From federico.facca at create-net.org  Thu Sep 24 09:20:10 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Thu, 24 Sep 2015 11:20:10 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
Message-ID: <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>

Hi Miko,
it is possible to develop a neutron extension for achieveing your goal.
Indeed for a customer we developed a ML2 driver that creates the needed
portgroups and connect them to the right vlan in vCenter and hence when
VMware VMs are created connect them to the create portgroups. The solution
in this case is very simple, i.e. all the traffic goes through the
controller nodes (no dvr, for example using the vmware proxy compute).
Unfortunately, I don't think we can share the code (the customer retained
the IPR on it) :(

my suggestion is:
- have a look on how to create a ML2 plugin
- understand vCenter APIs

Br,
Federico

--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org

On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <openstack at mikebeauty.com>
wrote:

> Hi Folks,
> i would like to know if anybody has tried to implement a neutron solution
> with vsphere without using NSX-like solutions.
> I mean, my lab environment is composed of :
>
>  - 1 network node ( neutron )
>  - 1 controller node
>  - 2 compute node ( kvm)
>  - 1 compute node linked to a cluster vsphere 6.0
>
> i tried, without success ;( to deploy an instance on vsphere node with a
> network configuration of type VLAN; ( obviously, in this configuration,i
> have not the ambition of a ovs solution type :) )
> so my questions are: it's' possible to implement a network neutron
> solution of type VLAN ? if yes how can i do?
> Thanks in advantage.
> Miko Bello
>
>
>
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/e589be49/attachment.html>

From federico.facca at create-net.org  Thu Sep 24 09:25:54 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Thu, 24 Sep 2015 11:25:54 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
Message-ID: <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>

you may have a look also at this project which uses a vm inside vcenter:

https://wiki.openstack.org/wiki/Neutron/Networking-vSphere

Br,
Federico

--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org

On Thu, Sep 24, 2015 at 11:20 AM, Federico Michele Facca <
federico.facca at create-net.org> wrote:

> Hi Miko,
> it is possible to develop a neutron extension for achieveing your goal.
> Indeed for a customer we developed a ML2 driver that creates the needed
> portgroups and connect them to the right vlan in vCenter and hence when
> VMware VMs are created connect them to the create portgroups. The solution
> in this case is very simple, i.e. all the traffic goes through the
> controller nodes (no dvr, for example using the vmware proxy compute).
> Unfortunately, I don't think we can share the code (the customer retained
> the IPR on it) :(
>
> my suggestion is:
> - have a look on how to create a ML2 plugin
> - understand vCenter APIs
>
> Br,
> Federico
>
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
>
> On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <openstack at mikebeauty.com>
> wrote:
>
>> Hi Folks,
>> i would like to know if anybody has tried to implement a neutron solution
>> with vsphere without using NSX-like solutions.
>> I mean, my lab environment is composed of :
>>
>>  - 1 network node ( neutron )
>>  - 1 controller node
>>  - 2 compute node ( kvm)
>>  - 1 compute node linked to a cluster vsphere 6.0
>>
>> i tried, without success ;( to deploy an instance on vsphere node with a
>> network configuration of type VLAN; ( obviously, in this configuration,i
>> have not the ambition of a ovs solution type :) )
>> so my questions are: it's' possible to implement a network neutron
>> solution of type VLAN ? if yes how can i do?
>> Thanks in advantage.
>> Miko Bello
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/230b1a11/attachment.html>

From ignaziocassano at gmail.com  Thu Sep 24 09:40:14 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Thu, 24 Sep 2015 11:40:14 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
 <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>
Message-ID: <CAB7j8cWtaYxK4rYJv6Wt75HuRWz6_LMdTSehMzYihm1WtbAGeg@mail.gmail.com>

Hi Federico, the link you suggested  is very interesting but I did not find
a link to download the vm appliance for vmware.
Regards
Ignazio

2015-09-24 11:25 GMT+02:00 Federico Michele Facca <
federico.facca at create-net.org>:

> you may have a look also at this project which uses a vm inside vcenter:
>
> https://wiki.openstack.org/wiki/Neutron/Networking-vSphere
>
> Br,
> Federico
>
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
>
> On Thu, Sep 24, 2015 at 11:20 AM, Federico Michele Facca <
> federico.facca at create-net.org> wrote:
>
>> Hi Miko,
>> it is possible to develop a neutron extension for achieveing your goal.
>> Indeed for a customer we developed a ML2 driver that creates the needed
>> portgroups and connect them to the right vlan in vCenter and hence when
>> VMware VMs are created connect them to the create portgroups. The solution
>> in this case is very simple, i.e. all the traffic goes through the
>> controller nodes (no dvr, for example using the vmware proxy compute).
>> Unfortunately, I don't think we can share the code (the customer retained
>> the IPR on it) :(
>>
>> my suggestion is:
>> - have a look on how to create a ML2 plugin
>> - understand vCenter APIs
>>
>> Br,
>> Federico
>>
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>>
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>>
>> --
>> Dr. Federico M. Facca
>>
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>>
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
>>
>> On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <openstack at mikebeauty.com>
>> wrote:
>>
>>> Hi Folks,
>>> i would like to know if anybody has tried to implement a neutron
>>> solution with vsphere without using NSX-like solutions.
>>> I mean, my lab environment is composed of :
>>>
>>>  - 1 network node ( neutron )
>>>  - 1 controller node
>>>  - 2 compute node ( kvm)
>>>  - 1 compute node linked to a cluster vsphere 6.0
>>>
>>> i tried, without success ;( to deploy an instance on vsphere node with a
>>> network configuration of type VLAN; ( obviously, in this
>>> configuration,i have not the ambition of a ovs solution type :) )
>>> so my questions are: it's' possible to implement a network neutron
>>> solution of type VLAN ? if yes how can i do?
>>> Thanks in advantage.
>>> Miko Bello
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/c23b611d/attachment.html>

From federico.facca at create-net.org  Thu Sep 24 09:49:02 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Thu, 24 Sep 2015 11:49:02 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CAB7j8cWtaYxK4rYJv6Wt75HuRWz6_LMdTSehMzYihm1WtbAGeg@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
 <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>
 <CAB7j8cWtaYxK4rYJv6Wt75HuRWz6_LMdTSehMzYihm1WtbAGeg@mail.gmail.com>
Message-ID: <CABfHRuu2RBGQdUiaXyw5oSTw54gsn9y+i6Cer3_X-PoFnrPe+Q@mail.gmail.com>

Hi Ignazio,
never tested it, I may suppose that during the installation the appliance
is created or downloaded (but I may be totally wrong). As by documentation:

For help using or hacking on OVSvApp solution, you can send an email to the
OpenStack Development Mailing List <mailto:openstack-dev at lists.openstack.org>;
kindly use the [Networking-vSphere] Tag in the subject.

Br,
Federico

--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org

On Thu, Sep 24, 2015 at 11:40 AM, Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Hi Federico, the link you suggested  is very interesting but I did not
> find a link to download the vm appliance for vmware.
> Regards
> Ignazio
>
> 2015-09-24 11:25 GMT+02:00 Federico Michele Facca <
> federico.facca at create-net.org>:
>
>> you may have a look also at this project which uses a vm inside vcenter:
>>
>> https://wiki.openstack.org/wiki/Neutron/Networking-vSphere
>>
>> Br,
>> Federico
>>
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>>
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>>
>> --
>> Dr. Federico M. Facca
>>
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>>
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
>>
>> On Thu, Sep 24, 2015 at 11:20 AM, Federico Michele Facca <
>> federico.facca at create-net.org> wrote:
>>
>>> Hi Miko,
>>> it is possible to develop a neutron extension for achieveing your goal.
>>> Indeed for a customer we developed a ML2 driver that creates the needed
>>> portgroups and connect them to the right vlan in vCenter and hence when
>>> VMware VMs are created connect them to the create portgroups. The solution
>>> in this case is very simple, i.e. all the traffic goes through the
>>> controller nodes (no dvr, for example using the vmware proxy compute).
>>> Unfortunately, I don't think we can share the code (the customer retained
>>> the IPR on it) :(
>>>
>>> my suggestion is:
>>> - have a look on how to create a ML2 plugin
>>> - understand vCenter APIs
>>>
>>> Br,
>>> Federico
>>>
>>> --
>>> Future Internet is closer than you think!
>>> http://www.fiware.org
>>>
>>> Official Mirantis partner for OpenStack Training
>>> https://www.create-net.org/community/openstack-training
>>>
>>> --
>>> Dr. Federico M. Facca
>>>
>>> CREATE-NET
>>> Via alla Cascata 56/D
>>> 38123 Povo Trento (Italy)
>>>
>>> P  +39 0461 312471
>>> M +39 334 6049758
>>> E  federico.facca at create-net.org
>>> T @chicco785
>>> W  www.create-net.org
>>>
>>> On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <openstack at mikebeauty.com>
>>> wrote:
>>>
>>>> Hi Folks,
>>>> i would like to know if anybody has tried to implement a neutron
>>>> solution with vsphere without using NSX-like solutions.
>>>> I mean, my lab environment is composed of :
>>>>
>>>>  - 1 network node ( neutron )
>>>>  - 1 controller node
>>>>  - 2 compute node ( kvm)
>>>>  - 1 compute node linked to a cluster vsphere 6.0
>>>>
>>>> i tried, without success ;( to deploy an instance on vsphere node with
>>>> a network configuration of type VLAN; ( obviously, in this
>>>> configuration,i have not the ambition of a ovs solution type :) )
>>>> so my questions are: it's' possible to implement a network neutron
>>>> solution of type VLAN ? if yes how can i do?
>>>> Thanks in advantage.
>>>> Miko Bello
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/59bc9238/attachment-0001.html>

From ignaziocassano at gmail.com  Thu Sep 24 09:52:59 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Thu, 24 Sep 2015 11:52:59 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CABfHRuu2RBGQdUiaXyw5oSTw54gsn9y+i6Cer3_X-PoFnrPe+Q@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
 <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>
 <CAB7j8cWtaYxK4rYJv6Wt75HuRWz6_LMdTSehMzYihm1WtbAGeg@mail.gmail.com>
 <CABfHRuu2RBGQdUiaXyw5oSTw54gsn9y+i6Cer3_X-PoFnrPe+Q@mail.gmail.com>
Message-ID: <CAB7j8cXh-KnSL5KNGmTX-ciiXJac4mFcQqpP9adROw8UcD9QnA@mail.gmail.com>

Thanks

2015-09-24 11:49 GMT+02:00 Federico Michele Facca <
federico.facca at create-net.org>:

> Hi Ignazio,
> never tested it, I may suppose that during the installation the appliance
> is created or downloaded (but I may be totally wrong). As by documentation:
>
> For help using or hacking on OVSvApp solution, you can send an email to
> the OpenStack Development Mailing List <mailto:
> openstack-dev at lists.openstack.org>; kindly use the [Networking-vSphere]
> Tag in the subject.
>
> Br,
> Federico
>
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
>
> On Thu, Sep 24, 2015 at 11:40 AM, Ignazio Cassano <
> ignaziocassano at gmail.com> wrote:
>
>> Hi Federico, the link you suggested  is very interesting but I did not
>> find a link to download the vm appliance for vmware.
>> Regards
>> Ignazio
>>
>> 2015-09-24 11:25 GMT+02:00 Federico Michele Facca <
>> federico.facca at create-net.org>:
>>
>>> you may have a look also at this project which uses a vm inside vcenter:
>>>
>>> https://wiki.openstack.org/wiki/Neutron/Networking-vSphere
>>>
>>> Br,
>>> Federico
>>>
>>> --
>>> Future Internet is closer than you think!
>>> http://www.fiware.org
>>>
>>> Official Mirantis partner for OpenStack Training
>>> https://www.create-net.org/community/openstack-training
>>>
>>> --
>>> Dr. Federico M. Facca
>>>
>>> CREATE-NET
>>> Via alla Cascata 56/D
>>> 38123 Povo Trento (Italy)
>>>
>>> P  +39 0461 312471
>>> M +39 334 6049758
>>> E  federico.facca at create-net.org
>>> T @chicco785
>>> W  www.create-net.org
>>>
>>> On Thu, Sep 24, 2015 at 11:20 AM, Federico Michele Facca <
>>> federico.facca at create-net.org> wrote:
>>>
>>>> Hi Miko,
>>>> it is possible to develop a neutron extension for achieveing your goal.
>>>> Indeed for a customer we developed a ML2 driver that creates the needed
>>>> portgroups and connect them to the right vlan in vCenter and hence when
>>>> VMware VMs are created connect them to the create portgroups. The solution
>>>> in this case is very simple, i.e. all the traffic goes through the
>>>> controller nodes (no dvr, for example using the vmware proxy compute).
>>>> Unfortunately, I don't think we can share the code (the customer retained
>>>> the IPR on it) :(
>>>>
>>>> my suggestion is:
>>>> - have a look on how to create a ML2 plugin
>>>> - understand vCenter APIs
>>>>
>>>> Br,
>>>> Federico
>>>>
>>>> --
>>>> Future Internet is closer than you think!
>>>> http://www.fiware.org
>>>>
>>>> Official Mirantis partner for OpenStack Training
>>>> https://www.create-net.org/community/openstack-training
>>>>
>>>> --
>>>> Dr. Federico M. Facca
>>>>
>>>> CREATE-NET
>>>> Via alla Cascata 56/D
>>>> 38123 Povo Trento (Italy)
>>>>
>>>> P  +39 0461 312471
>>>> M +39 334 6049758
>>>> E  federico.facca at create-net.org
>>>> T @chicco785
>>>> W  www.create-net.org
>>>>
>>>> On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <openstack at mikebeauty.com>
>>>> wrote:
>>>>
>>>>> Hi Folks,
>>>>> i would like to know if anybody has tried to implement a neutron
>>>>> solution with vsphere without using NSX-like solutions.
>>>>> I mean, my lab environment is composed of :
>>>>>
>>>>>  - 1 network node ( neutron )
>>>>>  - 1 controller node
>>>>>  - 2 compute node ( kvm)
>>>>>  - 1 compute node linked to a cluster vsphere 6.0
>>>>>
>>>>> i tried, without success ;( to deploy an instance on vsphere node with
>>>>> a network configuration of type VLAN; ( obviously, in this
>>>>> configuration,i have not the ambition of a ovs solution type :) )
>>>>> so my questions are: it's' possible to implement a network neutron
>>>>> solution of type VLAN ? if yes how can i do?
>>>>> Thanks in advantage.
>>>>> Miko Bello
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/92fcc488/attachment.html>

From ignaziocassano at gmail.com  Thu Sep 24 09:55:16 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Thu, 24 Sep 2015 11:55:16 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CAB7j8cXh-KnSL5KNGmTX-ciiXJac4mFcQqpP9adROw8UcD9QnA@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
 <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>
 <CAB7j8cWtaYxK4rYJv6Wt75HuRWz6_LMdTSehMzYihm1WtbAGeg@mail.gmail.com>
 <CABfHRuu2RBGQdUiaXyw5oSTw54gsn9y+i6Cer3_X-PoFnrPe+Q@mail.gmail.com>
 <CAB7j8cXh-KnSL5KNGmTX-ciiXJac4mFcQqpP9adROw8UcD9QnA@mail.gmail.com>
Message-ID: <CAB7j8cUfnn8ZQc4Zm7ejALhs352EgRjQLG0W0ngoPFbHOrYdAQ@mail.gmail.com>

Federico, I presume you speak italian.
Your company is a Mirantis partner ?
We are going to select an openstack distro and we need to speak about
mirantis.
Ignazio

2015-09-24 11:52 GMT+02:00 Ignazio Cassano <ignaziocassano at gmail.com>:

> Thanks
>
> 2015-09-24 11:49 GMT+02:00 Federico Michele Facca <
> federico.facca at create-net.org>:
>
>> Hi Ignazio,
>> never tested it, I may suppose that during the installation the appliance
>> is created or downloaded (but I may be totally wrong). As by documentation:
>>
>> For help using or hacking on OVSvApp solution, you can send an email to
>> the OpenStack Development Mailing List <mailto:
>> openstack-dev at lists.openstack.org>; kindly use the [Networking-vSphere]
>> Tag in the subject.
>>
>> Br,
>> Federico
>>
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>>
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>>
>> --
>> Dr. Federico M. Facca
>>
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>>
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.facca at create-net.org
>> T @chicco785
>> W  www.create-net.org
>>
>> On Thu, Sep 24, 2015 at 11:40 AM, Ignazio Cassano <
>> ignaziocassano at gmail.com> wrote:
>>
>>> Hi Federico, the link you suggested  is very interesting but I did not
>>> find a link to download the vm appliance for vmware.
>>> Regards
>>> Ignazio
>>>
>>> 2015-09-24 11:25 GMT+02:00 Federico Michele Facca <
>>> federico.facca at create-net.org>:
>>>
>>>> you may have a look also at this project which uses a vm inside vcenter:
>>>>
>>>> https://wiki.openstack.org/wiki/Neutron/Networking-vSphere
>>>>
>>>> Br,
>>>> Federico
>>>>
>>>> --
>>>> Future Internet is closer than you think!
>>>> http://www.fiware.org
>>>>
>>>> Official Mirantis partner for OpenStack Training
>>>> https://www.create-net.org/community/openstack-training
>>>>
>>>> --
>>>> Dr. Federico M. Facca
>>>>
>>>> CREATE-NET
>>>> Via alla Cascata 56/D
>>>> 38123 Povo Trento (Italy)
>>>>
>>>> P  +39 0461 312471
>>>> M +39 334 6049758
>>>> E  federico.facca at create-net.org
>>>> T @chicco785
>>>> W  www.create-net.org
>>>>
>>>> On Thu, Sep 24, 2015 at 11:20 AM, Federico Michele Facca <
>>>> federico.facca at create-net.org> wrote:
>>>>
>>>>> Hi Miko,
>>>>> it is possible to develop a neutron extension for achieveing your
>>>>> goal. Indeed for a customer we developed a ML2 driver that creates the
>>>>> needed portgroups and connect them to the right vlan in vCenter and hence
>>>>> when VMware VMs are created connect them to the create portgroups. The
>>>>> solution in this case is very simple, i.e. all the traffic goes through the
>>>>> controller nodes (no dvr, for example using the vmware proxy compute).
>>>>> Unfortunately, I don't think we can share the code (the customer retained
>>>>> the IPR on it) :(
>>>>>
>>>>> my suggestion is:
>>>>> - have a look on how to create a ML2 plugin
>>>>> - understand vCenter APIs
>>>>>
>>>>> Br,
>>>>> Federico
>>>>>
>>>>> --
>>>>> Future Internet is closer than you think!
>>>>> http://www.fiware.org
>>>>>
>>>>> Official Mirantis partner for OpenStack Training
>>>>> https://www.create-net.org/community/openstack-training
>>>>>
>>>>> --
>>>>> Dr. Federico M. Facca
>>>>>
>>>>> CREATE-NET
>>>>> Via alla Cascata 56/D
>>>>> 38123 Povo Trento (Italy)
>>>>>
>>>>> P  +39 0461 312471
>>>>> M +39 334 6049758
>>>>> E  federico.facca at create-net.org
>>>>> T @chicco785
>>>>> W  www.create-net.org
>>>>>
>>>>> On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <openstack at mikebeauty.com
>>>>> > wrote:
>>>>>
>>>>>> Hi Folks,
>>>>>> i would like to know if anybody has tried to implement a neutron
>>>>>> solution with vsphere without using NSX-like solutions.
>>>>>> I mean, my lab environment is composed of :
>>>>>>
>>>>>>  - 1 network node ( neutron )
>>>>>>  - 1 controller node
>>>>>>  - 2 compute node ( kvm)
>>>>>>  - 1 compute node linked to a cluster vsphere 6.0
>>>>>>
>>>>>> i tried, without success ;( to deploy an instance on vsphere node
>>>>>> with a network configuration of type VLAN; ( obviously, in this
>>>>>> configuration,i have not the ambition of a ovs solution type :) )
>>>>>> so my questions are: it's' possible to implement a network neutron
>>>>>> solution of type VLAN ? if yes how can i do?
>>>>>> Thanks in advantage.
>>>>>> Miko Bello
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-operators mailing list
>>>>>> OpenStack-operators at lists.openstack.org
>>>>>>
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/5c173ad4/attachment.html>

From federico.facca at create-net.org  Thu Sep 24 10:57:01 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Thu, 24 Sep 2015 12:57:01 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CAB7j8cUfnn8ZQc4Zm7ejALhs352EgRjQLG0W0ngoPFbHOrYdAQ@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <CABfHRusRoL-zAvkzPOEroB+SFuMi+wswiteQBiZB6XnvV8xyRA@mail.gmail.com>
 <CABfHRus2SqC=t2PZt97GB2eMDNrpECgsBDHrpoxaWwB9WVh+xA@mail.gmail.com>
 <CAB7j8cWtaYxK4rYJv6Wt75HuRWz6_LMdTSehMzYihm1WtbAGeg@mail.gmail.com>
 <CABfHRuu2RBGQdUiaXyw5oSTw54gsn9y+i6Cer3_X-PoFnrPe+Q@mail.gmail.com>
 <CAB7j8cXh-KnSL5KNGmTX-ciiXJac4mFcQqpP9adROw8UcD9QnA@mail.gmail.com>
 <CAB7j8cUfnn8ZQc4Zm7ejALhs352EgRjQLG0W0ngoPFbHOrYdAQ@mail.gmail.com>
Message-ID: <CABfHRut8eRU1krW+aAFb8-fCkn=frfruYdhprMRB4L_AD8QkCg@mail.gmail.com>

Ciao Ignazio,
As you evinced from my "itanglish", I am italian :) and, yees we are
official partners with Mirantis for OpenStack training:
https://training.mirantis.com/mirantis-training-partners

Feel free to contact me directly for any inquiry.

Regards,
Federico

Br,
Federico

--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org

On Thu, Sep 24, 2015 at 11:55 AM, Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Federico, I presume you speak italian.
> Your company is a Mirantis partner ?
> We are going to select an openstack distro and we need to speak about
> mirantis.
> Ignazio
>
> 2015-09-24 11:52 GMT+02:00 Ignazio Cassano <ignaziocassano at gmail.com>:
>
>> Thanks
>>
>> 2015-09-24 11:49 GMT+02:00 Federico Michele Facca <
>> federico.facca at create-net.org>:
>>
>>> Hi Ignazio,
>>> never tested it, I may suppose that during the installation the
>>> appliance is created or downloaded (but I may be totally wrong). As by
>>> documentation:
>>>
>>> For help using or hacking on OVSvApp solution, you can send an email to
>>> the OpenStack Development Mailing List <mailto:
>>> openstack-dev at lists.openstack.org>; kindly use the [Networking-vSphere]
>>> Tag in the subject.
>>>
>>> Br,
>>> Federico
>>>
>>> --
>>> Future Internet is closer than you think!
>>> http://www.fiware.org
>>>
>>> Official Mirantis partner for OpenStack Training
>>> https://www.create-net.org/community/openstack-training
>>>
>>> --
>>> Dr. Federico M. Facca
>>>
>>> CREATE-NET
>>> Via alla Cascata 56/D
>>> 38123 Povo Trento (Italy)
>>>
>>> P  +39 0461 312471
>>> M +39 334 6049758
>>> E  federico.facca at create-net.org
>>> T @chicco785
>>> W  www.create-net.org
>>>
>>> On Thu, Sep 24, 2015 at 11:40 AM, Ignazio Cassano <
>>> ignaziocassano at gmail.com> wrote:
>>>
>>>> Hi Federico, the link you suggested  is very interesting but I did not
>>>> find a link to download the vm appliance for vmware.
>>>> Regards
>>>> Ignazio
>>>>
>>>> 2015-09-24 11:25 GMT+02:00 Federico Michele Facca <
>>>> federico.facca at create-net.org>:
>>>>
>>>>> you may have a look also at this project which uses a vm inside
>>>>> vcenter:
>>>>>
>>>>> https://wiki.openstack.org/wiki/Neutron/Networking-vSphere
>>>>>
>>>>> Br,
>>>>> Federico
>>>>>
>>>>> --
>>>>> Future Internet is closer than you think!
>>>>> http://www.fiware.org
>>>>>
>>>>> Official Mirantis partner for OpenStack Training
>>>>> https://www.create-net.org/community/openstack-training
>>>>>
>>>>> --
>>>>> Dr. Federico M. Facca
>>>>>
>>>>> CREATE-NET
>>>>> Via alla Cascata 56/D
>>>>> 38123 Povo Trento (Italy)
>>>>>
>>>>> P  +39 0461 312471
>>>>> M +39 334 6049758
>>>>> E  federico.facca at create-net.org
>>>>> T @chicco785
>>>>> W  www.create-net.org
>>>>>
>>>>> On Thu, Sep 24, 2015 at 11:20 AM, Federico Michele Facca <
>>>>> federico.facca at create-net.org> wrote:
>>>>>
>>>>>> Hi Miko,
>>>>>> it is possible to develop a neutron extension for achieveing your
>>>>>> goal. Indeed for a customer we developed a ML2 driver that creates the
>>>>>> needed portgroups and connect them to the right vlan in vCenter and hence
>>>>>> when VMware VMs are created connect them to the create portgroups. The
>>>>>> solution in this case is very simple, i.e. all the traffic goes through the
>>>>>> controller nodes (no dvr, for example using the vmware proxy compute).
>>>>>> Unfortunately, I don't think we can share the code (the customer retained
>>>>>> the IPR on it) :(
>>>>>>
>>>>>> my suggestion is:
>>>>>> - have a look on how to create a ML2 plugin
>>>>>> - understand vCenter APIs
>>>>>>
>>>>>> Br,
>>>>>> Federico
>>>>>>
>>>>>> --
>>>>>> Future Internet is closer than you think!
>>>>>> http://www.fiware.org
>>>>>>
>>>>>> Official Mirantis partner for OpenStack Training
>>>>>> https://www.create-net.org/community/openstack-training
>>>>>>
>>>>>> --
>>>>>> Dr. Federico M. Facca
>>>>>>
>>>>>> CREATE-NET
>>>>>> Via alla Cascata 56/D
>>>>>> 38123 Povo Trento (Italy)
>>>>>>
>>>>>> P  +39 0461 312471
>>>>>> M +39 334 6049758
>>>>>> E  federico.facca at create-net.org
>>>>>> T @chicco785
>>>>>> W  www.create-net.org
>>>>>>
>>>>>> On Thu, Sep 24, 2015 at 11:01 AM, Miko Bello <
>>>>>> openstack at mikebeauty.com> wrote:
>>>>>>
>>>>>>> Hi Folks,
>>>>>>> i would like to know if anybody has tried to implement a neutron
>>>>>>> solution with vsphere without using NSX-like solutions.
>>>>>>> I mean, my lab environment is composed of :
>>>>>>>
>>>>>>>  - 1 network node ( neutron )
>>>>>>>  - 1 controller node
>>>>>>>  - 2 compute node ( kvm)
>>>>>>>  - 1 compute node linked to a cluster vsphere 6.0
>>>>>>>
>>>>>>> i tried, without success ;( to deploy an instance on vsphere node
>>>>>>> with a network configuration of type VLAN; ( obviously, in this
>>>>>>> configuration,i have not the ambition of a ovs solution type :) )
>>>>>>> so my questions are: it's' possible to implement a network neutron
>>>>>>> solution of type VLAN ? if yes how can i do?
>>>>>>> Thanks in advantage.
>>>>>>> Miko Bello
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-operators mailing list
>>>>>>> OpenStack-operators at lists.openstack.org
>>>>>>>
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/6bb19fa1/attachment.html>

From tom at openstack.org  Thu Sep 24 11:32:22 2015
From: tom at openstack.org (Tom Fifield)
Date: Thu, 24 Sep 2015 19:32:22 +0800
Subject: [Openstack-operators] [Tags] Meeting today :)
Message-ID: <5603DF46.2090005@openstack.org>

Hi all,

Let's meet today in #OpenStack-meeting at 1400 UTC (in about 2.5 hours 
time).

On the agenda is:
1. Planning our summit session
2. Review of open reviews 
(https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z 
)
3. Tag Brainstorming


Hope to see you there!



Regards,


Tom



From george.shuklin at gmail.com  Thu Sep 24 13:02:26 2015
From: george.shuklin at gmail.com (George Shuklin)
Date: Thu, 24 Sep 2015 16:02:26 +0300
Subject: [Openstack-operators] Live snapshots on the raw disks never ends
Message-ID: <5603F462.6050905@gmail.com>

Hello everyone.

Is someone ever saw 'endless snapshot' problem? Some instances (with raw 
disks and live snapshoting enabled) are stuck at image_uploading forever.

It looks like this:

+--------------------------------------+----------------------------------------------------------+
| Property                             | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| status                               | ACTIVE                                                   |
| updated                              | 2015-07-16T08:07:00Z                                     |
| OS-EXT-STS:task_state                | image_uploading                                          |
| OS-EXT-SRV-ATTR:host                 | compute                                                  |
| key_name                             | ses                                                      |
| image                                | Ubuntu 14.04 (3736af94-b25e-4b8d-96fd-fd5949bbd81e)      |
| OS-EXT-STS:vm_state                  | active                                                   |
| OS-EXT-SRV-ATTR:instance_name        | instance-0000000d                                        |
| OS-SRV-USG:launched_at               | 2015-05-09T17:28:09.000000                               |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.lab.internal                                     |
| flavor                               | flavor2 (2)                                              |
| id                                   | f2365fe4-9b30-4c24-b7b9-f7fcb4165160                     |
| security_groups                      | [{u'name': u'default'}]                                  |
| OS-SRV-USG:terminated_at             | None                                                     |
| user_id                              | 61096c639d674e4cb8bf487cec01432a                         |
| name                                 | non-test                                                 |
| created                              | 2015-05-09T17:27:48Z                                     |
...etc

Any ideas why this happens? All logs are clear, no errors or anything. 
And it happens at random so no 'debug' log available...


From klindgren at godaddy.com  Thu Sep 24 15:11:40 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Thu, 24 Sep 2015 15:11:40 +0000
Subject: [Openstack-operators] Live snapshots on the raw disks never ends
In-Reply-To: <5603F462.6050905@gmail.com>
References: <5603F462.6050905@gmail.com>
Message-ID: <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>

I believe I was talking to Josh Harlow (he's harlowja in #openstack-operators on freenode) from Yahoo, about something like this the other day.  He was saying that recently on a few hypervisors they would randomly run into HV disks that were completely full due to snapshots.  I have not personally ran into this, so I can't be of more help.

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy





On 9/24/15, 7:02 AM, "George Shuklin" <george.shuklin at gmail.com> wrote:

>Hello everyone.
>
>Is someone ever saw 'endless snapshot' problem? Some instances (with raw 
>disks and live snapshoting enabled) are stuck at image_uploading forever.
>
>It looks like this:
>
>+--------------------------------------+----------------------------------------------------------+
>| Property                             | Value                                                    |
>+--------------------------------------+----------------------------------------------------------+
>| status                               | ACTIVE                                                   |
>| updated                              | 2015-07-16T08:07:00Z                                     |
>| OS-EXT-STS:task_state                | image_uploading                                          |
>| OS-EXT-SRV-ATTR:host                 | compute                                                  |
>| key_name                             | ses                                                      |
>| image                                | Ubuntu 14.04 (3736af94-b25e-4b8d-96fd-fd5949bbd81e)      |
>| OS-EXT-STS:vm_state                  | active                                                   |
>| OS-EXT-SRV-ATTR:instance_name        | instance-0000000d                                        |
>| OS-SRV-USG:launched_at               | 2015-05-09T17:28:09.000000                               |
>| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.lab.internal                                     |
>| flavor                               | flavor2 (2)                                              |
>| id                                   | f2365fe4-9b30-4c24-b7b9-f7fcb4165160                     |
>| security_groups                      | [{u'name': u'default'}]                                  |
>| OS-SRV-USG:terminated_at             | None                                                     |
>| user_id                              | 61096c639d674e4cb8bf487cec01432a                         |
>| name                                 | non-test                                                 |
>| created                              | 2015-05-09T17:27:48Z                                     |
>...etc
>
>Any ideas why this happens? All logs are clear, no errors or anything. 
>And it happens at random so no 'debug' log available...
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From mriedem at linux.vnet.ibm.com  Thu Sep 24 15:46:15 2015
From: mriedem at linux.vnet.ibm.com (Matt Riedemann)
Date: Thu, 24 Sep 2015 10:46:15 -0500
Subject: [Openstack-operators] Potential deprecation of
 cinder.cross_az_attach option in nova
In-Reply-To: <050F747A-A466-48BE-B5A1-AA4E1AB38BBD@gmail.com>
References: <5603106D.5000008@linux.vnet.ibm.com>
 <050F747A-A466-48BE-B5A1-AA4E1AB38BBD@gmail.com>
Message-ID: <56041AC7.7020106@linux.vnet.ibm.com>



On 9/23/2015 6:27 PM, Sam Morrison wrote:
> We very much rely on this and I see this is already merged! Great another patch I have to manage locally.
>
> I don?t understand what the confusion is. We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone.
>
> We don?t want people attaching a volume from one zone to another as the network won?t allow that as the zones are in different network domains and different data centres.
>
> I will reply in the mailing list post on the dev channel but it seems it?s too late.
>
> Sam
>
>
>
>> On 24 Sep 2015, at 6:49 am, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
>>
>> I wanted to bring this to the attention of the operators mailing list in case someone is relying on the cinder.cross_az_attach.
>>
>> There is a -dev thread here [1] that started this discussion.  That led to a change proposed to deprecate the cinder.cross_az_attach option in nova [2].
>>
>> This is for deprecation in mitaka and removal in N.  If this affects you, please speak up in the mailing list or in the review.
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html
>> [2] https://review.openstack.org/#/c/226977/
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

The revert is approved.  Having done that, this is a mess of a feature, 
at least in the boot from volume case where source != volume.  The 
details on that are in the -dev thread but I'd appreciate operators that 
are using this to weigh in there on how they are handling the BFV case 
with cinder.cross_az_attach=False.  My main issue is the amount of API 
policy being defined in config options and when BFV fails to create the 
volume it's in the compute layer where we end up with a NoValidHost for 
the user.  I want to figure out how we can fail fast with a 400 response 
from nova API if we know the volume create is going to fail.

-- 

Thanks,

Matt Riedemann



From mvoelker at vmware.com  Thu Sep 24 15:58:37 2015
From: mvoelker at vmware.com (Mark Voelker)
Date: Thu, 24 Sep 2015 15:58:37 +0000
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
Message-ID: <DC2C386E-A4FC-4FAB-AD64-FCA74818B01C@vmware.com>

Miko,

There?s a VDS driver for Neutron in addition to the NSX one that you might want to have a look at if you haven?t already.  Some notes on that here (these are from the admin guides for the VMware Integrated OpenStack distribution as it does a pretty good job of describing the requirements, architecture, and limitations of the VDS driver, but the driver itself is open source and can be used by anyone):

http://pubs.vmware.com/integrated-openstack-2/index.jsp#com.vmware.openstack.install.doc/GUID-98D92A0C-E568-4380-A9AA-7AE9A59E360E.html

VDS obviously won?t work for the KVM compute hosts though.  A fairly widely-used tactic if you don?t want to use an SDN or overlay based solution for spanning multiple hypervisors is to separate the hypervisor hosts into separate regions (which have distinct API endpoints and can therefore have services configured completely differently if you so desire).  If you?re not familiar with the concept of regions, have a look here:

http://docs.openstack.org/openstack-ops/content/scaling.html

Note that if you go that route users need to target one region or the other when making API calls since they are distinct API endpoints.  

At Your Service,

Mark T. Voelker



> On Sep 24, 2015, at 5:01 AM, Miko Bello <openstack at mikebeauty.com> wrote:
> 
> Hi Folks,
> i would like to know if anybody has tried to implement a neutron solution with vsphere without using NSX-like solutions.
> I mean, my lab environment is composed of :
> 
>  - 1 network node ( neutron )
>  - 1 controller node
>  - 2 compute node ( kvm)
>  - 1 compute node linked to a cluster vsphere 6.0
>  
> i tried, without success ;( to deploy an instance on vsphere node with a network configuration of type VLAN; ( obviously, in this configuration,i have not the ambition of a ovs solution type :)  )
> so my questions are: it's' possible to implement a network neutron solution of type VLAN ? if yes how can i do?
> Thanks in advantage.
> Miko Bello
> 
>  
> 
> 
> 
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


From federico.facca at create-net.org  Thu Sep 24 16:14:29 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Thu, 24 Sep 2015 18:14:29 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <DC2C386E-A4FC-4FAB-AD64-FCA74818B01C@vmware.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <DC2C386E-A4FC-4FAB-AD64-FCA74818B01C@vmware.com>
Message-ID: <CABfHRuvSd7vhKWeZ41P97mbFvghmnZqEBqoHh=FrwLs_p_c1ow@mail.gmail.com>

As early mentioned this week, Mark's option is a valid alternative
(separate regions). @ Mark, I wonder if this excpert from your pointer is
still valid:

"VDS-based networking has limitations, including the inability of tenants
to create their own private L2 networks, and the inability to deliver L3
and higher networking services such as virtual routers, security groups,
and floating IPs.
If such features are important for your VMware Integrated OpenStack
deployment, consider using NSX-V for Neutron networking."

In case I think people should be aware of this before going for this option.

Br,
Federico

--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org

On Thu, Sep 24, 2015 at 5:58 PM, Mark Voelker <mvoelker at vmware.com> wrote:

> Miko,
>
> There?s a VDS driver for Neutron in addition to the NSX one that you might
> want to have a look at if you haven?t already.  Some notes on that here
> (these are from the admin guides for the VMware Integrated OpenStack
> distribution as it does a pretty good job of describing the requirements,
> architecture, and limitations of the VDS driver, but the driver itself is
> open source and can be used by anyone):
>
>
> http://pubs.vmware.com/integrated-openstack-2/index.jsp#com.vmware.openstack.install.doc/GUID-98D92A0C-E568-4380-A9AA-7AE9A59E360E.html
>
> VDS obviously won?t work for the KVM compute hosts though.  A fairly
> widely-used tactic if you don?t want to use an SDN or overlay based
> solution for spanning multiple hypervisors is to separate the hypervisor
> hosts into separate regions (which have distinct API endpoints and can
> therefore have services configured completely differently if you so
> desire).  If you?re not familiar with the concept of regions, have a look
> here:
>
> http://docs.openstack.org/openstack-ops/content/scaling.html
>
> Note that if you go that route users need to target one region or the
> other when making API calls since they are distinct API endpoints.
>
> At Your Service,
>
> Mark T. Voelker
>
>
>
> > On Sep 24, 2015, at 5:01 AM, Miko Bello <openstack at mikebeauty.com>
> wrote:
> >
> > Hi Folks,
> > i would like to know if anybody has tried to implement a neutron
> solution with vsphere without using NSX-like solutions.
> > I mean, my lab environment is composed of :
> >
> >  - 1 network node ( neutron )
> >  - 1 controller node
> >  - 2 compute node ( kvm)
> >  - 1 compute node linked to a cluster vsphere 6.0
> >
> > i tried, without success ;( to deploy an instance on vsphere node with a
> network configuration of type VLAN; ( obviously, in this configuration,i
> have not the ambition of a ovs solution type :)  )
> > so my questions are: it's' possible to implement a network neutron
> solution of type VLAN ? if yes how can i do?
> > Thanks in advantage.
> > Miko Bello
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/496bbbed/attachment.html>

From mvoelker at vmware.com  Thu Sep 24 17:27:21 2015
From: mvoelker at vmware.com (Mark Voelker)
Date: Thu, 24 Sep 2015 17:27:21 +0000
Subject: [Openstack-operators] nova-neutron with vsphere
In-Reply-To: <CABfHRuvSd7vhKWeZ41P97mbFvghmnZqEBqoHh=FrwLs_p_c1ow@mail.gmail.com>
References: <NV6BQC$1E72AB309FE38475E424452E55744462@mikebeauty.com>
 <DC2C386E-A4FC-4FAB-AD64-FCA74818B01C@vmware.com>
 <CABfHRuvSd7vhKWeZ41P97mbFvghmnZqEBqoHh=FrwLs_p_c1ow@mail.gmail.com>
Message-ID: <C6738821-F821-492B-AFFC-50949ED23F8C@vmware.com>

Yes: as the document there notes, the VDS driver uses provider networks (which in Neutron are created by the admin rather than the tenant and basically map neutron networks to VLANs in the physical datacenter network) and therefore punt L3 operations to the datacenter network.

At Your Service,

Mark T. Voelker



> On Sep 24, 2015, at 12:14 PM, Federico Michele Facca <federico.facca at create-net.org> wrote:
> 
> As early mentioned this week, Mark's option is a valid alternative (separate regions). @ Mark, I wonder if this excpert from your pointer is still valid:
> 
> "VDS-based networking has limitations, including the inability of tenants to create their own private L2 networks, and the inability to deliver L3 and higher networking services such as virtual routers, security groups, and floating IPs. 
> If such features are important for your VMware Integrated OpenStack deployment, consider using NSX-V for Neutron networking."
> 
> In case I think people should be aware of this before going for this option.
> 
> Br,
> Federico
> 
> --
> Future Internet is closer than you think!
> http://www.fiware.org
> 
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
> 
> -- 
> Dr. Federico M. Facca
> 
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
> 
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.facca at create-net.org
> T @chicco785
> W  www.create-net.org
> 
> On Thu, Sep 24, 2015 at 5:58 PM, Mark Voelker <mvoelker at vmware.com> wrote:
> Miko,
> 
> There?s a VDS driver for Neutron in addition to the NSX one that you might want to have a look at if you haven?t already.  Some notes on that here (these are from the admin guides for the VMware Integrated OpenStack distribution as it does a pretty good job of describing the requirements, architecture, and limitations of the VDS driver, but the driver itself is open source and can be used by anyone):
> 
> http://pubs.vmware.com/integrated-openstack-2/index.jsp#com.vmware.openstack.install.doc/GUID-98D92A0C-E568-4380-A9AA-7AE9A59E360E.html
> 
> VDS obviously won?t work for the KVM compute hosts though.  A fairly widely-used tactic if you don?t want to use an SDN or overlay based solution for spanning multiple hypervisors is to separate the hypervisor hosts into separate regions (which have distinct API endpoints and can therefore have services configured completely differently if you so desire).  If you?re not familiar with the concept of regions, have a look here:
> 
> http://docs.openstack.org/openstack-ops/content/scaling.html
> 
> Note that if you go that route users need to target one region or the other when making API calls since they are distinct API endpoints.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
> > On Sep 24, 2015, at 5:01 AM, Miko Bello <openstack at mikebeauty.com> wrote:
> >
> > Hi Folks,
> > i would like to know if anybody has tried to implement a neutron solution with vsphere without using NSX-like solutions.
> > I mean, my lab environment is composed of :
> >
> >  - 1 network node ( neutron )
> >  - 1 controller node
> >  - 2 compute node ( kvm)
> >  - 1 compute node linked to a cluster vsphere 6.0
> >
> > i tried, without success ;( to deploy an instance on vsphere node with a network configuration of type VLAN; ( obviously, in this configuration,i have not the ambition of a ovs solution type :)  )
> > so my questions are: it's' possible to implement a network neutron solution of type VLAN ? if yes how can i do?
> > Thanks in advantage.
> > Miko Bello
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 


From clint at fewbar.com  Thu Sep 24 22:53:28 2015
From: clint at fewbar.com (Clint Byrum)
Date: Thu, 24 Sep 2015 15:53:28 -0700
Subject: [Openstack-operators] [openstack-dev] [Large Deployments
	Team][Performance Team] New informal working group suggestion
In-Reply-To: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
References: <CACsCO2yHugc0FQmXBxO_-uzaOvR_KXQNdPOEYYneU=vqoeJSEw@mail.gmail.com>
Message-ID: <1443135171-sup-1175@fewbar.com>

Excerpts from Dina Belova's message of 2015-09-22 05:57:19 -0700:
> Hey, OpenStackers!
> 
> I'm writing to propose to organise new informal team to work specifically
> on the OpenStack performance issues. This will be a sub team in already
> existing Large Deployments Team, and I suppose it will be a good idea to
> gather people interested in OpenStack performance in one room and identify
> what issues are worrying contributors, what can be done and share results
> of performance researches :)
> 
> So please volunteer to take part in this initiative. I hope it will be many
> people interested and we'll be able to use cross-projects session slot
> <http://odsreg.openstack.org/cfp/details/5> to meet in Tokyo and hold a
> kick-off meeting.
> 
> I would like to apologise I'm writing to two mailing lists at the same
> time, but I want to make sure that all possibly interested people will
> notice the email.
> 

Dina, this is great. Count me in, and see you in Tokyo!


From boris at pavlovic.me  Fri Sep 25 00:05:38 2015
From: boris at pavlovic.me (Boris Pavlovic)
Date: Thu, 24 Sep 2015 17:05:38 -0700
Subject: [Openstack-operators] [openstack-dev][openstack-operators][Rally]
 Rally plugins reference is available
Message-ID: <CAD85om30QcMUHi4vB8BjD0dUf_h=ZZNjKo-w72+ffKMC9GRTAg@mail.gmail.com>

Hi stackers,

As far as you know Rally test cases are created as a mix of plugins.

At this point of time we have more than 200 plugins for almost all
OpenStack projects.
Before you had to analyze code of plugins or use "rally plugin find/list"
commands to find plugins that you need, which was the pain in neck.

So finally we have auto generated plugin reference:
https://rally.readthedocs.org/en/latest/plugin/plugin_reference.html


Best regards,
Boris Pavlovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150924/985c4339/attachment.html>

From pieter.c.kruithof-jr at hpe.com  Fri Sep 25 03:32:13 2015
From: pieter.c.kruithof-jr at hpe.com (Kruithof, Piet)
Date: Fri, 25 Sep 2015 03:32:13 +0000
Subject: [Openstack-operators] [all] [neutron] [ux] [nova] Nova
	Network/Neutron Migration Survey
Message-ID: <D22A1C5B.182A1%pieter.c.kruithof-jr@hp.com>

The OpenStack UX project team would like to invite you to participate in a survey to help drive product direction for the Neutron project.  The survey should take no more than fifteen minutes to complete.

We are specifically looking for folks with the following kinds of roles; Architect, Cloud Operator, System Administrator, Network Architect / Engineer / Administrator, Developer, or IT Manager / Director.  In addition, they should be familiar with either Nova Networks and/or Neutron.

You will also be entered in a raffle for one of two $100 US Amazon gift cards at the end of the survey.   As always, the results from the survey will be shared with the OpenStack community.

Please click on the following link to begin the survey.

https://www.surveymonkey.com/r/osnetworking

Thanks,


Piet
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

"For every complex problem, there is a solution that is simple, neat and wrong.?

H L Menken



From sorrison at gmail.com  Fri Sep 25 05:07:29 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Fri, 25 Sep 2015 15:07:29 +1000
Subject: [Openstack-operators] deprecation of allow_duplicate_networks
Message-ID: <59FB5AB7-F807-4109-B53D-73926A87090C@gmail.com>

We are in the process of migrating to neutron and have come across this handy config option that is sadly being deprecated. (seems to be a theme of mine this week)
Does anyone know if this is supported in some other way?

We have limited IP addresses and ideally we?d like to prevent users from taking more than 1 per instance. I?m wondering if this should be a neutron setting and could be set on a per network basis. We?d like to prevent duplicates on our public provider networks but don?t care about the private tenant networks.

Anyone got any ideas or know of anything happening in this space?

Cheers,
Sam



cfg.BoolOpt('allow_duplicate_networks',
               default=False,
               help='DEPRECATED: Allow an instance to have multiple vNICs '
                    'attached to the same Neutron network. This option is '
                    'deprecated in the 2015.1 release and will be removed '
                    'in the 2015.2 release where the default behavior will '
                    'be to always allow multiple ports from the same network '
                    'to be attached to an instance.',
               deprecated_for_removal=True),





From rahulsharmaait at gmail.com  Fri Sep 25 05:44:42 2015
From: rahulsharmaait at gmail.com (Rahul Sharma)
Date: Fri, 25 Sep 2015 01:44:42 -0400
Subject: [Openstack-operators] [puppet] need help understanding specific
	puppet logs in openstack installation
Message-ID: <CAAw0FvT+j3tPewdr_xJuZK6jqRG46C67W-R_aOU9u+9Usbc4sg@mail.gmail.com>

Hi All,

I am trying the RDO installation of Openstack using puppet. It works fine
when I puppetize my controller node for the first time after fresh
installation of OS. There are no errors thrown at terminal during the
installation. However, if I try to rerun the puppet agent, it configures
something additional this time which is not configured during the first
run. Mentioned below are the logs it prints to terminal:-

Notice: /File[/etc/sysconfig/iptables]/seluser: seluser changed
'unconfined_u' to 'system_u'
Notice:
/Stage[main]/Neutron::Agents::Ml2::Ovs/Service[ovs-cleanup-service]/enable:
enable changed 'false' to 'true'
Notice:
/Stage[main]/Neutron::Agents::Ml2::Ovs/Neutron::Plugins::Ovs::Bridge[physext1:br-ex]/Vs_bridge[br-ex]/external_ids:
external_ids changed '' to 'bridge-id=br-ex'
Notice: /Stage[main]/Quickstack::Neutron::Controller/Exec[neutron-db-manage
upgrade]/returns: executed successfully
Notice: Finished catalog run in 36.61 seconds

>From these logs, I am unable to figure out which of the parameters were not
configured when it was run for the first time so that I can try fixing them
in the script itself. I want to avoid the dependency of running puppet
multiple times. Looking at the *.conf files on the controller node doesn't
help much.

Can someone please help me out in understanding what the above mentioned
logs point to? Any pointers would be really helpful.

Thanks.

*Rahul Sharma*
*MS in Computer Science, 2016*
College of Computer and Information Science, Northeastern University
Mobile:  801-706-7860
Email: rahulsharmaait at gmail.com
Linkedin: www.linkedin.com/in/rahulsharmaait
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/e4c79e7b/attachment.html>

From salv.orlando at gmail.com  Fri Sep 25 06:43:57 2015
From: salv.orlando at gmail.com (Salvatore Orlando)
Date: Fri, 25 Sep 2015 08:43:57 +0200
Subject: [Openstack-operators] deprecation of allow_duplicate_networks
In-Reply-To: <59FB5AB7-F807-4109-B53D-73926A87090C@gmail.com>
References: <59FB5AB7-F807-4109-B53D-73926A87090C@gmail.com>
Message-ID: <CAP0B2WPvASugy6i2Z5T4dR86OkYpZ8EgAsf+ZJWgorHWwA+9iw@mail.gmail.com>

Good morning Sam,

As you say, your requirement cannot be satisfied today. The option you
mention provided a nice workaround but did not fully solve your problem.
I think in order to satisfy it Neutron could either:
1) Specify this on a per-network setting in Neutron
2) Enable VIF usage tracking grouping it by networks and apply a limit of 1
3) A combination of the previous two where VIF usage limiting is enforce
only on selected networks

I think #2 alone would satisfy your requirement.

On the other you could have also your requirement satisfied by adding
something in nova, but since allow_duplicate_networks is being deprecated
I'm not sure it makes sense to reintroduce something which is semantically
similar.

At this stage - since Mitaka dev cycle just started - I would suggest to
file a Neutron RFE bug [1] if you have not already done so.

Salvatore

[1]
http://docs.openstack.org/developer/neutron/policies/blueprints.html#rfe-submission-guidelines

On 25 September 2015 at 07:07, Sam Morrison <sorrison at gmail.com> wrote:

> We are in the process of migrating to neutron and have come across this
> handy config option that is sadly being deprecated. (seems to be a theme of
> mine this week)
> Does anyone know if this is supported in some other way?
>
> We have limited IP addresses and ideally we?d like to prevent users from
> taking more than 1 per instance. I?m wondering if this should be a neutron
> setting and could be set on a per network basis. We?d like to prevent
> duplicates on our public provider networks but don?t care about the private
> tenant networks.
>
> Anyone got any ideas or know of anything happening in this space?
>
> Cheers,
> Sam
>
>
>
> cfg.BoolOpt('allow_duplicate_networks',
>                default=False,
>                help='DEPRECATED: Allow an instance to have multiple vNICs '
>                     'attached to the same Neutron network. This option is '
>                     'deprecated in the 2015.1 release and will be removed '
>                     'in the 2015.2 release where the default behavior will
> '
>                     'be to always allow multiple ports from the same
> network '
>                     'to be attached to an instance.',
>                deprecated_for_removal=True),
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/d1060d53/attachment.html>

From Tim.Bell at cern.ch  Fri Sep 25 12:22:40 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Fri, 25 Sep 2015 12:22:40 +0000
Subject: [Openstack-operators] [all] [neutron] [ux] [nova]
	Nova	Network/Neutron Migration Survey
In-Reply-To: <D22A1C5B.182A1%pieter.c.kruithof-jr@hp.com>
References: <D22A1C5B.182A1%pieter.c.kruithof-jr@hp.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A46903A@CERNXCHG41.cern.ch>

Piet,

There seems to be a lot of overlap with the user survey which is currently
running.  This also includes questions for those running nova network and
these are also reviewed in the operators summit sessions and mid-cycle
meetups.

There is a significant risk of over surveying the operator community and
then we would lose all the valuable feedback.

Feel free to get in touch on the User-committee at lists.openstack.org if you
have questions to suggest to the survey or would like specific queries to be
run on the anonymised data.

Tim

> -----Original Message-----
> From: Kruithof, Piet [mailto:pieter.c.kruithof-jr at hpe.com]
> Sent: 25 September 2015 05:32
> To: openstack-operators at lists.openstack.org
> Subject: [Openstack-operators] [all] [neutron] [ux] [nova] Nova
> Network/Neutron Migration Survey
> 
> The OpenStack UX project team would like to invite you to participate in a
> survey to help drive product direction for the Neutron project.  The
survey
> should take no more than fifteen minutes to complete.
> 
> We are specifically looking for folks with the following kinds of roles;
> Architect, Cloud Operator, System Administrator, Network Architect /
> Engineer / Administrator, Developer, or IT Manager / Director.  In
addition,
> they should be familiar with either Nova Networks and/or Neutron.
> 
> You will also be entered in a raffle for one of two $100 US Amazon gift
cards
> at the end of the survey.   As always, the results from the survey will be
> shared with the OpenStack community.
> 
> Please click on the following link to begin the survey.
> 
> https://www.surveymonkey.com/r/osnetworking
> 
> Thanks,
> 
> 
> Piet
> Sr UX Architect, HP Helion Cloud
> PTL, OpenStack UX project
> 
> "For every complex problem, there is a solution that is simple, neat and
> wrong."
> 
> H L Menken
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/e5611f63/attachment.bin>

From raju.roks at gmail.com  Fri Sep 25 12:49:58 2015
From: raju.roks at gmail.com (raju)
Date: Fri, 25 Sep 2015 08:49:58 -0400
Subject: [Openstack-operators] kilo/nfv-vlan-trunks
Message-ID: <CAMhjf2hW9vu0q0ky2Q-syopaeQTH-LkGtMcBzs+XeAmStQP+3g@mail.gmail.com>

Hi Team,

I need to create trunk ports inside neutron where instances will receive
traffic from multiple vlans.

Do I need to apply any patch to my current openstack version(kilo) to get
this feature?


Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/b4587f30/attachment.html>

From sean at seanhamilton.co.uk  Fri Sep 25 15:55:18 2015
From: sean at seanhamilton.co.uk (Sean Hamilton)
Date: Fri, 25 Sep 2015 16:55:18 +0100
Subject: [Openstack-operators] Potential deprecation of
 cinder.cross_az_attach option in nova
In-Reply-To: <56041AC7.7020106@linux.vnet.ibm.com>
References: <5603106D.5000008@linux.vnet.ibm.com>
 <050F747A-A466-48BE-B5A1-AA4E1AB38BBD@gmail.com>
 <56041AC7.7020106@linux.vnet.ibm.com>
Message-ID: <CAPnk8EhWubXe4dpu2MhMEhuySC83HnH5=9soZZwpRBdTugAmzw@mail.gmail.com>

We use cinder.cross_az_attach=False as a way of separating failure domains.
Each AZ is effectively a set of racks with compute and storage in them,
this way we keep the compute and storage close to each other and in the
event of an issue in one AZ it won't affect the other (mostly).

In this scenario a user could attach a volume from AZ1 to a nova compute in
AZ2. If AZ1 went down then the instance would be affected.

On 24 September 2015 at 16:46, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
>
> On 9/23/2015 6:27 PM, Sam Morrison wrote:
>
>> We very much rely on this and I see this is already merged! Great another
>> patch I have to manage locally.
>>
>> I don?t understand what the confusion is. We have multiple availability
>> zones in nova and each zone has a corresponding cinder-volume service(s) in
>> the same availability zone.
>>
>> We don?t want people attaching a volume from one zone to another as the
>> network won?t allow that as the zones are in different network domains and
>> different data centres.
>>
>> I will reply in the mailing list post on the dev channel but it seems
>> it?s too late.
>>
>> Sam
>>
>>
>>
>> On 24 Sep 2015, at 6:49 am, Matt Riedemann <mriedem at linux.vnet.ibm.com>
>>> wrote:
>>>
>>> I wanted to bring this to the attention of the operators mailing list in
>>> case someone is relying on the cinder.cross_az_attach.
>>>
>>> There is a -dev thread here [1] that started this discussion.  That led
>>> to a change proposed to deprecate the cinder.cross_az_attach option in nova
>>> [2].
>>>
>>> This is for deprecation in mitaka and removal in N.  If this affects
>>> you, please speak up in the mailing list or in the review.
>>>
>>> [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html
>>> [2] https://review.openstack.org/#/c/226977/
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
> The revert is approved.  Having done that, this is a mess of a feature, at
> least in the boot from volume case where source != volume.  The details on
> that are in the -dev thread but I'd appreciate operators that are using
> this to weigh in there on how they are handling the BFV case with
> cinder.cross_az_attach=False.  My main issue is the amount of API policy
> being defined in config options and when BFV fails to create the volume
> it's in the compute layer where we end up with a NoValidHost for the user.
> I want to figure out how we can fail fast with a 400 response from nova API
> if we know the volume create is going to fail.
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/e3896d34/attachment.html>

From mgagne at internap.com  Fri Sep 25 16:00:58 2015
From: mgagne at internap.com (=?UTF-8?Q?Mathieu_Gagn=c3=a9?=)
Date: Fri, 25 Sep 2015 12:00:58 -0400
Subject: [Openstack-operators] deprecation of allow_duplicate_networks
In-Reply-To: <59FB5AB7-F807-4109-B53D-73926A87090C@gmail.com>
References: <59FB5AB7-F807-4109-B53D-73926A87090C@gmail.com>
Message-ID: <56056FBA.6000105@internap.com>

On 2015-09-25 1:07 AM, Sam Morrison wrote:
> We are in the process of migrating to neutron and have come across this handy config option that is sadly being deprecated. (seems to be a theme of mine this week)
> Does anyone know if this is supported in some other way?
> 
> We have limited IP addresses and ideally we?d like to prevent users from taking more than 1 per instance. I?m wondering if this should be a neutron setting and could be set on a per network basis. We?d like to prevent duplicates on our public provider networks but don?t care about the private tenant networks.
> 
> Anyone got any ideas or know of anything happening in this space?


The problem with allow_duplicate_networks is that it doesn't really work
as you might think it does. If you have anti-spoofing in place, traffic
coming in on the 2nd port will try to come out using the 1st port and it
just won't work.

You can assign multiple fixed_ips to the same Neutron port. Be advised
that there is a maximum of fixed ips a port can get assigned.
Fortunately, you can control it with the max_fixed_ips_per_port Neutron
config.

Unfortunately, the Horizon dashboard does not support this feature (you
can see the information, you just can't assign more IPs), but the CLI
does by repeating the --fixed-ip argument.

As for limiting the number of IPs per port on a specific network, I
don't think it's possible yet. I would be interested to see it
implemented as well for the same reason as you.

-- 
Mathieu


From emilien at redhat.com  Fri Sep 25 16:31:46 2015
From: emilien at redhat.com (Emilien Macchi)
Date: Fri, 25 Sep 2015 12:31:46 -0400
Subject: [Openstack-operators] [puppet] need help understanding specific
 puppet logs in openstack installation
In-Reply-To: <CAAw0FvT+j3tPewdr_xJuZK6jqRG46C67W-R_aOU9u+9Usbc4sg@mail.gmail.com>
References: <CAAw0FvT+j3tPewdr_xJuZK6jqRG46C67W-R_aOU9u+9Usbc4sg@mail.gmail.com>
Message-ID: <560576F2.6060804@redhat.com>

[cc jayg - quickstack maintainer]

On 09/25/2015 01:44 AM, Rahul Sharma wrote:
> Hi All,
> 
> I am trying the RDO installation of Openstack using puppet. It works
> fine when I puppetize my controller node for the first time after fresh
> installation of OS. There are no errors thrown at terminal during the
> installation. However, if I try to rerun the puppet agent, it configures
> something additional this time which is not configured during the first
> run. Mentioned below are the logs it prints to terminal:-
> 
> Notice: /File[/etc/sysconfig/iptables]/seluser: seluser changed
> 'unconfined_u' to 'system_u'
> Notice:
> /Stage[main]/Neutron::Agents::Ml2::Ovs/Service[ovs-cleanup-service]/enable:
> enable changed 'false' to 'true'
> Notice:
> /Stage[main]/Neutron::Agents::Ml2::Ovs/Neutron::Plugins::Ovs::Bridge[physext1:br-ex]/Vs_bridge[br-ex]/external_ids:
> external_ids changed '' to 'bridge-id=br-ex'
> Notice:
> /Stage[main]/Quickstack::Neutron::Controller/Exec[neutron-db-manage
> upgrade]/returns: executed successfully
> Notice: Finished catalog run in 36.61 seconds

Regarding the catalog is seems your catalog is not idempotent, something
with IPtables packaging that tries to apply a SElinux context different
of what Puppet tries to apply.

I'll let Jay (Quickstack maintainer) give more support.

> From these logs, I am unable to figure out which of the parameters were
> not configured when it was run for the first time so that I can try
> fixing them in the script itself. I want to avoid the dependency of
> running puppet multiple times. Looking at the *.conf files on the
> controller node doesn't help much.
> 
> Can someone please help me out in understanding what the above mentioned
> logs point to? Any pointers would be really helpful.
> 
> Thanks.
> 
> *Rahul Sharma*
> /MS in Computer Science, 2016/
> College of Computer and Information Science, Northeastern University
> Mobile:  801-706-7860
> Email: rahulsharmaait at gmail.com <mailto:rahulsharmaait at gmail.com>
> Linkedin: www.linkedin.com/in/rahulsharmaait
> <http://www.linkedin.com/in/rahulsharmaait>
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/796ee6c5/attachment.pgp>

From emilien at redhat.com  Fri Sep 25 17:01:59 2015
From: emilien at redhat.com (Emilien Macchi)
Date: Fri, 25 Sep 2015 13:01:59 -0400
Subject: [Openstack-operators] [puppet] feedback request about
 puppet-keystone
In-Reply-To: <56002E35.2010807@redhat.com>
References: <56002E35.2010807@redhat.com>
Message-ID: <56057E07.6070201@redhat.com>



On 09/21/2015 12:20 PM, Emilien Macchi wrote:
> Hi,
> 
> Puppet OpenStack group would like to know your feedback about using
> puppet-keystone module.
> 
> Please take two minutes and feel the form [1] that contains a few
> questions. The answers will help us to define our roadmap for the next
> cycle and make Keystone deployment stronger for our users.
> 
> The result of the forms should be visible online, otherwise I'll make
> sure the results are 100% public and transparent.
> 
> Thank you for your time,
> 
> [1] http://goo.gl/forms/eiGWFkkXLZ
> 

So after 5 days, here is a bit of feedback (13 people did the poll [1]):

1/ Providers
Except for 1, most of people are managing a few number of Keystone
users/tenants.
I would like to know if it's because the current implementation (using
openstackclient) is too slow or just because they don't need to do that
(they use bash, sdk, ansible, etc).

2/ Features you want

* "Configuration of federation via shibboleth":
WIP on https://review.openstack.org/#/c/216821/

* "Configuration of federation via mod_mellon":
Will come after shibboleth I guess.

* "Allow to configure websso"":
See
http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/enabling-federation.html

* "Management of fernet keys":
nothing *yet* in our roadmap AFIK, adding it in our backlog [2]

* "Support for hybrid domain configurations (e.g. using both LDAP and
built in database backend)":
http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html

* "Full v3 API support (depends on other modules beyond just
puppet-keystone)":
http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html

* "the ability to upgrade modules independently of one another, like we
do in production - currently the puppet dependencies dictate the order
in which we do upgrades more than the OpenStack dependencies":

During the last Summit, we decided [3] as a community that our modules
branches will only support the OpenStack release of the branch.
ie: stable/kilo supports OpenStack 2015.1 (Kilo). Maybe you can deploy
Juno or Liberty with it, but our community does not support it.
To give a little background, we already discussed about it [4] on the ML.
Our interface is 100% (or should be) backward compatible for at least
one full cycle, so you should not have issue when using a new version of
the module with the same parameters. Though (and indeed), you need to
keep your modules synchronized, specially because we have libraries and
common providers (in puppet-keystone).
AFIK, OpenStack also works like this with openstack/requirements.
I'm not sure you can run Glance Kilo with Oslo Juno (maybe I'm wrong).
What you're asking would be technically hard because we would have to
support old versions of our providers & libraries, with a lot of
backward compatible & legacy code in place, while we already do a good
job in the parameters (interface).
If you have any serious proposal, we would be happy to discuss design
and find a solution.

3/ What we could improve in Puppet Keystone (and in general, regarding
the answers)

* "(...) but it would be nice to be able to deploy master and the most
recent version immediately rather than wait. Happy to get involved with
that as our maturity improves and we actually start to use the current
version earlier. Contribution is hard when you folk are ahead of the
game, any fixes and additions we have are ancient already":

I would like to understand the issues here:
do you have problems to contribute?
is your issue "a feature is in master and not in stable/*" ? If that's
the case, that means we can do a better job in backport policy.
Something we already talked each others and I hope our group is aware
about that.

* "We were using keystone_user_role until we had huge compilation times
due to the matrix (tenant x role x user) that is not scalable. With
every single user and tenant on the environment, the catalog compilation
increased. An improvement on that area will be useful."

I understand the frustration and we are working on it [5].

* "Currently does not handle deployment of hybrid domain configurations."

Ditto:
http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html


I liked running a poll like this, if you don't mind I'll take time to
prepare a bigger poll so we can gather more and more feedback, because
it's really useful. Thanks for that.


Discussion is open on this thread about features/concerns mentioned in
the poll.


[1]
https://docs.google.com/forms/d/1Z6IGeJRNmX7xx0Ggmr5Pmpzq7BudphDkZE-3t4Q5G1k/viewanalytics
[2] https://trello.com/c/HjiWUng3/65-puppet-keystone-manage-fernet-keys
[3]
http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/master-policy.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069147.html
[5] https://bugs.launchpad.net/puppet-keystone/+bug/1493450
-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/cd4fa89e/attachment.pgp>

From edgar.magana at workday.com  Fri Sep 25 17:41:06 2015
From: edgar.magana at workday.com (Edgar Magana)
Date: Fri, 25 Sep 2015 17:41:06 +0000
Subject: [Openstack-operators] [all] [neutron] [ux] [nova] Nova
 Network/Neutron Migration Survey
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A46903A@CERNXCHG41.cern.ch>
References: <D22A1C5B.182A1%pieter.c.kruithof-jr@hp.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A46903A@CERNXCHG41.cern.ch>
Message-ID: <24C3005C-230F-4C60-8E88-6133AF9ADE3E@workday.com>

Piet,

I do agree with Tim. Our concerns as Operators are about the correlation of this information with the one collected by the OpenStack Foundation in the operators/users survey.
Besides, your employer is an OpenStack vendor and from my point of view all this information could benefit HP versus other. Is that acceptable by the Foundation?

I am including Allison from the Foundation to hear her opinion.

Thanks,


Edgar

On 9/25/15, 5:22 AM, "Tim Bell" <Tim.Bell at cern.ch> wrote:

>Piet,
>
>There seems to be a lot of overlap with the user survey which is currently
>running.  This also includes questions for those running nova network and
>these are also reviewed in the operators summit sessions and mid-cycle
>meetups.
>
>There is a significant risk of over surveying the operator community and
>then we would lose all the valuable feedback.
>
>Feel free to get in touch on the User-committee at lists.openstack.org if you
>have questions to suggest to the survey or would like specific queries to be
>run on the anonymised data.
>
>Tim
>
>> -----Original Message-----
>> From: Kruithof, Piet [mailto:pieter.c.kruithof-jr at hpe.com]
>> Sent: 25 September 2015 05:32
>> To: openstack-operators at lists.openstack.org
>> Subject: [Openstack-operators] [all] [neutron] [ux] [nova] Nova
>> Network/Neutron Migration Survey
>> 
>> The OpenStack UX project team would like to invite you to participate in a
>> survey to help drive product direction for the Neutron project.  The
>survey
>> should take no more than fifteen minutes to complete.
>> 
>> We are specifically looking for folks with the following kinds of roles;
>> Architect, Cloud Operator, System Administrator, Network Architect /
>> Engineer / Administrator, Developer, or IT Manager / Director.  In
>addition,
>> they should be familiar with either Nova Networks and/or Neutron.
>> 
>> You will also be entered in a raffle for one of two $100 US Amazon gift
>cards
>> at the end of the survey.   As always, the results from the survey will be
>> shared with the OpenStack community.
>> 
>> Please click on the following link to begin the survey.
>> 
>> https://www.surveymonkey.com/r/osnetworking
>> 
>> Thanks,
>> 
>> 
>> Piet
>> Sr UX Architect, HP Helion Cloud
>> PTL, OpenStack UX project
>> 
>> "For every complex problem, there is a solution that is simple, neat and
>> wrong."
>> 
>> H L Menken
>> 
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From sgordon at redhat.com  Fri Sep 25 17:53:40 2015
From: sgordon at redhat.com (Steve Gordon)
Date: Fri, 25 Sep 2015 13:53:40 -0400 (EDT)
Subject: [Openstack-operators] Migrating an instance to a host with
	less	cores fails
In-Reply-To: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
Message-ID: <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>

Adding Nikola as he has been working on this.

----- Original Message -----
> From: "Aubrey Wells" <awells at digiumcloud.com>
> To: openstack-operators at 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):
> 
> <vcpu
> cpuset="1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39">1</vcpu>
> 
> 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 at 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


From klindgren at godaddy.com  Fri Sep 25 18:16:56 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Fri, 25 Sep 2015 18:16:56 +0000
Subject: [Openstack-operators] Migrating an instance to a host with less
 cores fails
In-Reply-To: <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
 <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>
Message-ID: <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>

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.
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 9/25/15, 11:53 AM, "Steve Gordon" <sgordon at redhat.com> wrote:

>Adding Nikola as he has been working on this.
>
>----- Original Message -----
>> From: "Aubrey Wells" <awells at digiumcloud.com>
>> To: openstack-operators at 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):
>> 
>> <vcpu
>> cpuset="1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39">1</vcpu>
>> 
>> 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 at 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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From sgordon at redhat.com  Fri Sep 25 18:34:24 2015
From: sgordon at redhat.com (Steve Gordon)
Date: Fri, 25 Sep 2015 14:34:24 -0400 (EDT)
Subject: [Openstack-operators] Migrating an instance to a host with less
 cores fails
In-Reply-To: <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
 <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>
 <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>
Message-ID: <424234981.58015304.1443206064837.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Kris G. Lindgren" <klindgren at godaddy.com>
> To: "Steve Gordon" <sgordon at redhat.com>, "Aubrey Wells" <awells at 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" <sgordon at redhat.com> wrote:
> 
> >Adding Nikola as he has been working on this.
> >
> >----- Original Message -----
> >> From: "Aubrey Wells" <awells at digiumcloud.com>
> >> To: openstack-operators at 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):
> >> 
> >> <vcpu
> >> cpuset="1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39">1</vcpu>
> >> 
> >> 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 at 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 at 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


From chris.friesen at windriver.com  Fri Sep 25 18:41:10 2015
From: chris.friesen at windriver.com (Chris Friesen)
Date: Fri, 25 Sep 2015 12:41:10 -0600
Subject: [Openstack-operators] Migrating an instance to a host with less
 cores fails
In-Reply-To: <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
 <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>
 <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>
Message-ID: <56059546.3040604@windriver.com>

This is a long-standing issue.  Nikola has been working on it in Liberty for the 
CPU pinning case, not sure about the non-pinned case.  And of course patching 
back to Kilo hasn't been done yet.

Aubrey, what you're seeing is definitely a bug.  There is an existing bug 
https://bugs.launchpad.net/nova/+bug/1417667 but that is specifically for 
dedicated CPUs which doesn't apply in your case.  Please feel free to open a new 
bug.

Chris

On 09/25/2015 12:16 PM, Kris G. Lindgren wrote:
> 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.
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
>
>
>
>
>
>
> On 9/25/15, 11:53 AM, "Steve Gordon" <sgordon at redhat.com> wrote:
>
>> Adding Nikola as he has been working on this.
>>
>> ----- Original Message -----
>>> From: "Aubrey Wells" <awells at digiumcloud.com>
>>> To: openstack-operators at 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):
>>>
>>> <vcpu
>>> cpuset="1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39">1</vcpu>
>>>
>>> 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 at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



From chris.friesen at windriver.com  Fri Sep 25 18:43:50 2015
From: chris.friesen at windriver.com (Chris Friesen)
Date: Fri, 25 Sep 2015 12:43:50 -0600
Subject: [Openstack-operators] Migrating an instance to a host with less
 cores fails
In-Reply-To: <424234981.58015304.1443206064837.JavaMail.zimbra@redhat.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
 <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>
 <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>
 <424234981.58015304.1443206064837.JavaMail.zimbra@redhat.com>
Message-ID: <560595E6.9030306@windriver.com>

On 09/25/2015 12:34 PM, Steve Gordon wrote:

> 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!

My concern with that patch is that it only applies if there is no numa topology 
for the instance.  I think it's possible to specify hugepages but not CPU 
pinning, in which case there would still be a numa topology for the instance, it 
just wouldn't have pinned CPUs in it.

Chris


From openstack at medberry.net  Fri Sep 25 19:12:33 2015
From: openstack at medberry.net (David Medberry)
Date: Fri, 25 Sep 2015 13:12:33 -0600
Subject: [Openstack-operators] Migrating an instance to a host with less
 cores fails
In-Reply-To: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
Message-ID: <CAJhvMSvPccfwkNOgFhfSr-vz1PVjwAcQcm4cb4KYOYkR1O6pjg@mail.gmail.com>

As Kris Lindgren noted, this has bit us big time. Defaults appear wrong,
desired behavior would be other than it is. I'm re-reading this entire
thread now (sorry for not weighing in earlier.)

On Fri, May 15, 2015 at 12:52 PM, Aubrey Wells <awells at digiumcloud.com>
wrote:

> 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):
>
> <vcpu
> cpuset="1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39">1</vcpu>
>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/a91820c7/attachment.html>

From jay at openstack.org  Fri Sep 25 19:44:32 2015
From: jay at openstack.org (Jay Fankhauser)
Date: Fri, 25 Sep 2015 14:44:32 -0500
Subject: [Openstack-operators] =?utf-8?q?OpenStack_Weekly_Community_Newsle?=
 =?utf-8?b?dHRlciAoU2VwdC4sMTkg4oCTIDI1KQ==?=
Message-ID: <AA5B7A65-AF56-4546-8D12-50F4D272A72E@openstack.org>

Register for OpenStack Summit Tokyo 2015 <https://www.eventbrite.com/e/openstack-summit-october-2015-tokyo-tickets-17356780598>
Full access registration prices increase on 9/29 at 11:59pm PT
This trove of user stories highlights what people want in OpenStack <http://superuser.openstack.org/articles/this-trove-of-user-stories-highlights-what-people-want-in-openstack>
The Product Working Group recently launched a Git repository to collect requirements ranging from encrypted storage to rolling upgrades.
How storage works in containers <http://superuser.openstack.org/articles/how-storage-works-in-containers>
Nick Gerasimatos, senior director of cloud services engineering at FICO, dives into the lack of persistent storage with containers and how Docker volumes and data containers provide a fix.
The Road to Tokyo 

Get your OpenStack Summit Tokyo visa in five steps: Deadline for Visa invitation requests is?10/1 <http://superuser.openstack.org/articles/get-your-openstack-summit-tokyo-visa-in-five-steps>
The schedule and mobile app for the OpenStack Summit in Tokyo are now available <https://www.openstack.org/summit/tokyo-2015/schedule/>
Community feedback
OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the OpenStack Weekly Community Newsletter or have ideas on how to present content please get in touch: community at openstack.org <mailto:community at openstack.org>.
Reports from Previous Events 

OpenStack Heats Up Silicon Valley <https://developer.ibm.com/opentech/2015/09/20/openstack-heats-up-silicon-valley/>
OpenStack Day Benelux 2015 <http://superuser.openstack.org/articles/openstack-day-benelux-2015>
Deadlines and Contributors Notifications 

Liberty Release Oct., 15, 2015 <https://wiki.openstack.org/wiki/Liberty_Release_Schedule>
Security Advisories and Notices 

[openstack-announce] [OSSA 2015-019] Glance image status manipulation (CVE-2015-5251) <http://lists.openstack.org/pipermail/openstack-announce/2015-September/000655.html>
Tips ?n Tricks 

By Swapnil Kulkarni <http://blog.coolsvap.net/>: [OpenStack][RDO] Liberty Test-Day <http://blog.coolsvap.net/2015/09/24/openstackrdo-test-day-liberty/>
Upcoming Events <https://www.openstack.org/community/events> 

Sep 28, 2015???Jan 3, 2016?Presenting At PyCon (call for papers) Portland,OR, US? <https://us.pycon.org/2016/speaking/>
Sep 29?? 30, 2015 Cloud Storage in OpenStack <https://groups.openstack.org/groups/frederick-md/cloud-storage-openstack>
Oct 01, 2015?OpenStack Meetup Cluj?Cluj-Napoc, Cluj, RO <http://www.meetup.com/OpenStackRomania/events/222910344/>
Oct 01, 2015?South Bay OpenStack Meetup, Beginner track San Francisco, CA, US <http://www.meetup.com/openstack/events/221806052/>
Oct 01 ? 02, 2015?October OpenStack Meetup ? SDN and Containers?Chicago, IL, US <http://www.meetup.com/meetup-group-NjZdcegA/events/225081881/>
Oct 04 ? 08, 2015?Gartner SymposiumITxpo?Orlando, FL, US <http://www.gartner.com/events/na/orlando-symposium>
Oct 06, 2015?October Sydney Meetup <http://www.meetup.com/Australian-OpenStack-User-Group/events/220202327/>
Oct 07, 2015?Houston OpenStack Meetup?Houston, TX, US <http://www.meetup.com/openstackhoustonmeetup/events/224870393/?eventId=224870393&action=detail>
Oct 07 ? 08, 2015?OpenStack Liberty Release?Richardson, TX, US <http://www.meetup.com/OpenStack-DFW/events/225014699/>
Oct 07 ? 08, 2015?OpenStack 101?Houston, TX, US <http://www.meetup.com/openstackhoustonmeetup/events/224870393/>What you need to know from the developer?s list
Handling Projects with no PTL candidates <http://lists.openstack.org/pipermail/openstack-dev/2015-September/075227.html>
The technical committee will appoint a PTL [1] if there is no identified eligible candidate.
Appointed PTLs:
Robert Clark nominated security PTL
Serg Melikyan nominated Murano PTL
Douglas Mendizabal nominated Barbican PTL
Election for Magnum PTL between Adrian Otto and Hongbin Lu
MagnetoDB being abandoned, not PTL was chosen. Instead, it will be fast tracked for removal [2] from the official list of OpenStack projects.
Release help needed - we are incompatible with ourselves <http://lists.openstack.org/pipermail/openstack-dev/2015-September/075075.html>
Robert Collins raises that while the constraints system in place for how we recognize incompatible components in our release is working, the release team needs help from the community to fix the incompatibility that exists so we can cut the full Liberty release.
Issues that exist:
OpenStack client not able to create an image.
Fix is merged [3].
Semver and dependency changes <http://lists.openstack.org/pipermail/openstack-dev/2015-September/075107.html>
Robert Collins says currently we don?t provide guidance on what happens when the only changes in a project are dependency changes and a release is made.
Today the release team treats dependency changes as a ?feature? rather than a bug fix. (e.g. if the previous release 1.2.3, requirement sync happens, the next version is  1.3.0.)
Reasons behind this are complex, some guidance is needed to answer the questions:
Is this requirements change an API break?
Is this requirements change feature work?
Is this requirements change a bug fix?
All of these questions can be true. Some examples:
If library X exposes library Y as part of its API, and library Y?s dependency changes from Y>=1 to Y>=2. X does this because it needs a feature from Y==2.
Library Y is not exposed in library X?s API, however, a change in Y?s dependencies for X will impact users who independently use Y. (ignoring intricacies surrounding PIP here.)
Proposal:
nothing -> a requirement -> major version change
1.x.y -> 2.0.0 -> major version change
1.2.y -> 1.3.0 -> minor version change
1.2.3. -> 1.2.4 -> patch version change
Thierry Carrez is ok with the last two proposals. Defaulting to a major version bump sounds a bit overkill.
Doug Hellmann reminds that we can?t assume the dependency is using semver itself. We would need something other than the version number to determine from the outside whether the API is in fact breaking.
Due this problem being so complicated, Doug would rather over-simplify the analysis of requirements updates until we?re better at identifying our own API breaking changes and differentiating between features and bug fixes. This will allow us to be consistent, if not 100% correct.
Criteria for applying vulnerability:managed tag <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073435.html>
The vulnerability management processes were brought to the big tent a couple of months ago [4].
Initially we listed what repos the Vulnerability Manage Team (VMT) tracks for vulnerabilities.
TC decided to change this from repos to deliverables as per-repo tags were decided against.
Jeremy Stanley provides transparency for how deliverables can qualify for this tag:
All repos in a given deliverable must qualify. If one repo doesn?t, they all don?t in a given deliverable.
Points of contact:
Deliverable must have a dedicated point of contact.
The VMT will engage with this contact to triage reports.
A group of core reviewers should be part of the <project>-corsec team and will:
Confirm whether a bug is accurate/applicable.
Provide pre-approval of patches attached to reports.
The PTLs for the deliverable should agree to act as (or delegate) a vulnerability management liaison to escalate for the VMT.
The bug tracker for the repos within a deliverable should have a bug tracker configured to initially provide access to privately reported vulnerabilities initially to the VMT.
The VMT will determine if the vulnerability is reported against the correct deliverable and redirect when possible.
The deliverable repos should undergo a third-party review/audit looking for obvious signs of insecure design or risky implementation.
This aims to keep the VMT?s workload down.
It has not been identified who will perform this review. Maybe the OpenStack Security project team?
Review of this proposal is posted [5].
Consistent support for SSL termination proxies across all APIs <http://lists.openstack.org/pipermail/openstack-dev/2015-September/074871.html>
While a bug [6] was being debugged, an issue was identified where an API sitting behind a proxy performing SSL termination would not generate the right redirection (http instead of https).
A review [7] has been given to have a config option ?secure_proxy_ssl_header? which allows the API service to detect ssl termination based on the header X-Forwarded-Proto.
Another bug back in 2014 was open with the same issue [8].
Several projects applied patches to fix this issue, but are inconsistent:
Glance added public_endpoint config
Cinder added public_endpoint config
Heat added secure_proxy_ssl_header config (through heat.api.openstack:sslmiddleware_filter)
Nova added secure_proxy_ssl_header config
Manila added secure_proxy_ssl_header config (through oslo_middleware.ssl:SSLMiddleware.factory)
Ironic added public_endpoint config
Keystone added secure_proxy_ssl_header config
Ben Nemec comments that solving this at the service level is the wrong place, due to this requiring changes in a bunch of different API services. Instead it should be fixed in the proxy that?s converting the traffic to http.
Sean Dague notes that this should be done in the service catalog. Service discovery is a base thing that all services should use in talking to each other. There?s an OpenStack spec [9] in an attempt to get a handle on this
Mathieu Gagn? notes that this won?t work. There is a ?split view? in the service catalog where internal management nodes have a specific catalog and public nodes (for users) have a different one.
Suggestion to use oslo middleware SSL for supporting the ?secure_proxy_ssl_header? config to fix the problem with little code.
Sean agrees the split view needs to be considered, however, another layer of work shouldn?t decide if the service catalog is a good way to keep track of what our service urls are. We shouldn?t push a model where Keystone is optional.
Sean notes that while the ?secure_proxy_ssl_header? config solution supports the cases where there?s a 1 HA proxy with SSL termination to 1 API service, it may not work in the cases where there?s a 1 API service to N HA Proxies for:
Clients needing to understand the ?Location:? headers correctly.
Libraries like request/phatomjs can follow the links provided in REST documents, and they?re correct.
The minority of services that ?operate without keystone? as an option are able to function.
ZZelle mentions this solution does not work in the cases when the service itself acts as a proxy (e.g. nova image-list).
Would this solution work in the HA Proxy case where there is one terminating address for multiple backend servers?
Yes, by honoring the headers X-Forwarded-Host and X-Forwarded-Port which are set by HTTP proxies, making WSGI applications unaware of the fact that there is a request in front of them.
Jamie Lennox says this same topic came up as a block in a Devstack patch to get TLS testing in the gate with HA Proxy.
Longer term solution, transition services to use relative links.
This is a pretty serious change. We?ve been returning absolute URLs forever, so assuming that all client code out there would with relative code is a big assumption. That?s a major version for sure.
Sean agrees that we have enough pieces to get something better with proxy headers for Mitaka. We can do the remaining edge cases if clean up the service catalog use.
[1] - http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html <http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html>
[2] - https://review.openstack.org/#/c/224743/ <https://review.openstack.org/#/c/224743/>
[3] - https://review.openstack.org/#/c/225443/ <https://review.openstack.org/#/c/225443/>
[4] - http://governance.openstack.org/reference/tags/vulnerability_managed.html <http://governance.openstack.org/reference/tags/vulnerability_managed.html>
[5] - https://review.openstack.org/#/c/226869/ <https://review.openstack.org/#/c/226869/>
[6] - https://bugs.launchpad.net/python-novaclient/+bug/1491579 <https://bugs.launchpad.net/python-novaclient/+bug/1491579>
[7] - https://review.openstack.org/#/c/206479/ <https://review.openstack.org/#/c/206479/>
[8] - https://bugs.launchpad.net/glance/+bug/1384379 <https://bugs.launchpad.net/glance/+bug/1384379>
[9] - https://review.openstack.org/#/c/181393/ <https://review.openstack.org/#/c/181393/>
?
The weekly newsletter is a way for the community to learn about all the various activities in the OpenStack world._______________________________________________
Community mailing list
Community at lists.openstack.org <mailto:Community at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/community <http://lists.openstack.org/cgi-bin/mailman/listinfo/community>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150925/7a34cfe0/attachment.html>

From allison at openstack.org  Fri Sep 25 20:55:10 2015
From: allison at openstack.org (Allison Price)
Date: Fri, 25 Sep 2015 15:55:10 -0500
Subject: [Openstack-operators] [all] [neutron] [ux] [nova] Nova
	Network/Neutron Migration Survey
In-Reply-To: <24C3005C-230F-4C60-8E88-6133AF9ADE3E@workday.com>
References: <D22A1C5B.182A1%pieter.c.kruithof-jr@hp.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A46903A@CERNXCHG41.cern.ch>
 <24C3005C-230F-4C60-8E88-6133AF9ADE3E@workday.com>
Message-ID: <ABC3DB79-4D6B-4688-9864-62D07A694EFE@openstack.org>

Hi Edgar, 

Thanks for adding me to the thread. 

I wanted to include Heidi Joy Tretheway (cc?d above), as she is the Foundation team member that is running the user survey on our end. She will be able to shed more light on any concerns with survey overlap and what next steps should be taken. 

Cheers,
Allison


Allison Price
OpenStack Marketing
allison at openstack.org


> On Sep 25, 2015, at 12:41 PM, Edgar Magana <edgar.magana at workday.com> wrote:
> 
> Piet,
> 
> I do agree with Tim. Our concerns as Operators are about the correlation of this information with the one collected by the OpenStack Foundation in the operators/users survey.
> Besides, your employer is an OpenStack vendor and from my point of view all this information could benefit HP versus other. Is that acceptable by the Foundation?
> 
> I am including Allison from the Foundation to hear her opinion.
> 
> Thanks,
> 
> 
> Edgar
> 
> On 9/25/15, 5:22 AM, "Tim Bell" <Tim.Bell at cern.ch> wrote:
> 
>> Piet,
>> 
>> There seems to be a lot of overlap with the user survey which is currently
>> running.  This also includes questions for those running nova network and
>> these are also reviewed in the operators summit sessions and mid-cycle
>> meetups.
>> 
>> There is a significant risk of over surveying the operator community and
>> then we would lose all the valuable feedback.
>> 
>> Feel free to get in touch on the User-committee at lists.openstack.org if you
>> have questions to suggest to the survey or would like specific queries to be
>> run on the anonymised data.
>> 
>> Tim
>> 
>>> -----Original Message-----
>>> From: Kruithof, Piet [mailto:pieter.c.kruithof-jr at hpe.com]
>>> Sent: 25 September 2015 05:32
>>> To: openstack-operators at lists.openstack.org
>>> Subject: [Openstack-operators] [all] [neutron] [ux] [nova] Nova
>>> Network/Neutron Migration Survey
>>> 
>>> The OpenStack UX project team would like to invite you to participate in a
>>> survey to help drive product direction for the Neutron project.  The
>> survey
>>> should take no more than fifteen minutes to complete.
>>> 
>>> We are specifically looking for folks with the following kinds of roles;
>>> Architect, Cloud Operator, System Administrator, Network Architect /
>>> Engineer / Administrator, Developer, or IT Manager / Director.  In
>> addition,
>>> they should be familiar with either Nova Networks and/or Neutron.
>>> 
>>> You will also be entered in a raffle for one of two $100 US Amazon gift
>> cards
>>> at the end of the survey.   As always, the results from the survey will be
>>> shared with the OpenStack community.
>>> 
>>> Please click on the following link to begin the survey.
>>> 
>>> https://www.surveymonkey.com/r/osnetworking
>>> 
>>> Thanks,
>>> 
>>> 
>>> Piet
>>> Sr UX Architect, HP Helion Cloud
>>> PTL, OpenStack UX project
>>> 
>>> "For every complex problem, there is a solution that is simple, neat and
>>> wrong."
>>> 
>>> H L Menken
>>> 
>>> 
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From sgordon at redhat.com  Fri Sep 25 21:18:51 2015
From: sgordon at redhat.com (Steve Gordon)
Date: Fri, 25 Sep 2015 17:18:51 -0400 (EDT)
Subject: [Openstack-operators] Migrating an instance to a host with less
 cores fails
In-Reply-To: <560595E6.9030306@windriver.com>
References: <CAJ+z88oqAPOLi3k+X94FxvO2HSMqrDd8ufrEU3q-zfTDcsTWNA@mail.gmail.com>
 <1649928027.58005170.1443203620769.JavaMail.zimbra@redhat.com>
 <B9629266-B7E3-43C1-AC39-2610A2112E8D@godaddy.com>
 <424234981.58015304.1443206064837.JavaMail.zimbra@redhat.com>
 <560595E6.9030306@windriver.com>
Message-ID: <1615020709.58078367.1443215931622.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Chris Friesen" <chris.friesen at windriver.com>
> To: openstack-operators at lists.openstack.org
> 
> On 09/25/2015 12:34 PM, Steve Gordon wrote:
> 
> > 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!
> 
> My concern with that patch is that it only applies if there is no numa
> topology
> for the instance.  I think it's possible to specify hugepages but not CPU
> pinning, in which case there would still be a numa topology for the instance,
> it
> just wouldn't have pinned CPUs in it.
> 
> Chris

I think everyone involved shares that concern but the NUMA-related features (incl. huge pages) were at least as I understand it supposed to be opt in, the above patch at least alleviates the issues caused for those who never opted into them and got caught up in these unintended side effects.

-Steve


From itzshamail at gmail.com  Sat Sep 26 18:40:17 2015
From: itzshamail at gmail.com (Shamail)
Date: Sat, 26 Sep 2015 14:40:17 -0400
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag for
	"Scale"
Message-ID: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>

Hi Large Deployments Team,

The ops-tags team was brainstorming potential future tags at our last meeting and one topic of interest was to express the "scale" a service can operate at via tags. 

Scale, of course, can imply several different dimensions (not to mention test types).  We figured who better to talk to about the definition of scale than the large deployment team.  :-)

Can you please help us understand how your team classifies a deployment as being large?  I recall that, in the initial discussions, LDT was using the number of nodes.  Is this still the case?  Does large deployment factor in things such as throughout requirements, number of networks, number of volumes, etc. when deciding if a deployment is "large"?  

Thanks in advance for your help.  If it makes more sense to discuss this topic at the next LDT meeting then I would be glad to join.

Thank you,
Shamail Tahir
t: @ShamailXD
tz: EST





From mestery at mestery.com  Sat Sep 26 19:31:15 2015
From: mestery at mestery.com (Kyle Mestery)
Date: Sat, 26 Sep 2015 14:31:15 -0500
Subject: [Openstack-operators] kilo/nfv-vlan-trunks
In-Reply-To: <CAMhjf2hW9vu0q0ky2Q-syopaeQTH-LkGtMcBzs+XeAmStQP+3g@mail.gmail.com>
References: <CAMhjf2hW9vu0q0ky2Q-syopaeQTH-LkGtMcBzs+XeAmStQP+3g@mail.gmail.com>
Message-ID: <CAL3VkVwBL0SQneqR-L8u+PgwpqO4D33jEOQV3n_qg6krsHW=2w@mail.gmail.com>

On Fri, Sep 25, 2015 at 7:49 AM, raju <raju.roks at gmail.com> wrote:

> Hi Team,
>
> I need to create trunk ports inside neutron where instances will receive
> traffic from multiple vlans.
>
> Do I need to apply any patch to my current openstack version(kilo) to get
> this feature?
>
>
You can look here [1] for the BP which hopes to eventually implement VLAN
aware VMs. The patches that are out there are not ready for inclusion in
Neutron yet, so your mileage may vary. Further, my gut says they do not
apply easily to Kilo either, as they are based on Liberty. The Neutron team
hopes to get this work settled and landed during the Mitaka cycle, though
that won't help you with Kilo.

Thanks,
Kyle

[1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

>
> Thanks
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150926/658eb0b9/attachment.html>

From blak111 at gmail.com  Sat Sep 26 20:11:16 2015
From: blak111 at gmail.com (Kevin Benton)
Date: Sat, 26 Sep 2015 13:11:16 -0700
Subject: [Openstack-operators] kilo/nfv-vlan-trunks
In-Reply-To: <CAMhjf2hW9vu0q0ky2Q-syopaeQTH-LkGtMcBzs+XeAmStQP+3g@mail.gmail.com>
References: <CAMhjf2hW9vu0q0ky2Q-syopaeQTH-LkGtMcBzs+XeAmStQP+3g@mail.gmail.com>
Message-ID: <CAO_F6JMd7Xe_4VJQNhaux8S95kNvXh7atY1s7uA_ePzpmVCfgw@mail.gmail.com>

It depends on what you want. If the VLANs on the trunk need to correspond
to different neutron networks, then you will have to wait for the vlan
aware VMs feature.

If you just want the vlan tags passed transparently, then check out the
transparent VLANs feature that went into Kilo IIRC.
On Sep 25, 2015 2:51 PM, "raju" <raju.roks at gmail.com> wrote:

> Hi Team,
>
> I need to create trunk ports inside neutron where instances will receive
> traffic from multiple vlans.
>
> Do I need to apply any patch to my current openstack version(kilo) to get
> this feature?
>
>
> Thanks
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150926/e6dab9b3/attachment.html>

From clint at fewbar.com  Sun Sep 27 00:10:07 2015
From: clint at fewbar.com (Clint Byrum)
Date: Sat, 26 Sep 2015 17:10:07 -0700
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
	for "Scale"
In-Reply-To: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
Message-ID: <1443312603-sup-6878@fewbar.com>

Excerpts from Shamail's message of 2015-09-26 11:40:17 -0700:
> Hi Large Deployments Team,
> 
> The ops-tags team was brainstorming potential future tags at our last meeting and one topic of interest was to express the "scale" a service can operate at via tags. 
> 
> Scale, of course, can imply several different dimensions (not to mention test types).  We figured who better to talk to about the definition of scale than the large deployment team.  :-)
> 
> Can you please help us understand how your team classifies a deployment as being large?  I recall that, in the initial discussions, LDT was using the number of nodes.  Is this still the case?  Does large deployment factor in things such as throughout requirements, number of networks, number of volumes, etc. when deciding if a deployment is "large"?  
> 
> Thanks in advance for your help.  If it makes more sense to discuss this topic at the next LDT meeting then I would be glad to join.

I wasn't involved with the discussion, but I think it is an important one.

IMO, the objective way to do this is to add tests for scaling factors,
like ensuring reasonable resource cost per operation, response time during
simulated high concurrency, and actual large scale 3rd-party CI. If a
project hasn't done that, they shouldn't be considered "high scale".

(note that I don't think any of the projects actually has these things
surfaced upstream, but we are definitely going to need these things)


From boris at pavlovic.me  Sun Sep 27 00:21:06 2015
From: boris at pavlovic.me (Boris Pavlovic)
Date: Sat, 26 Sep 2015 17:21:06 -0700
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
	for "Scale"
In-Reply-To: <CAD85om0TCY4BsnPZMrezVMN_d6rgqLhb=tvQq=Fg9HnSg8zz8A@mail.gmail.com>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
 <CAD85om0TCY4BsnPZMrezVMN_d6rgqLhb=tvQq=Fg9HnSg8zz8A@mail.gmail.com>
Message-ID: <CAD85om1vQStDQWg4X_-GSn6-ter9GE7EbeRm0Ftygog5Pg9wUg@mail.gmail.com>

Shamail,

It's really quite hard thing to standardize because there are few
dimensions:
- Amount of resources (VMs, Volumes, Images, ... of service),
- Amount of active users (how ofter resource are created/deleted),
- Size of cloud (amount of nodes)
- Cloud deployment architecture
- ...

What I believe is that we should standardize:

- Amount of  resource per service per node
- Typical sizes of cloud: 10, 20, 50, 100, ... nodes
- Workloads that we should be run:
   For example In Rally team we are trying to standardize them here:
   https://github.com/openstack/rally/tree/master/certification/openstack
- Deployment Reference Architecture
- Somebody should find enough resources to run at least for each release
  those tests on real hardware

And create depending on this few scale tags:
works-on-X-scale


Best regards,
Boris Pavlovic

On Sat, Sep 26, 2015 at 5:19 PM, Boris Pavlovic <bpavlovic at mirantis.com>
wrote:

> Shamail,
>
> It's really quite hard thing to standardize because there are few
> dimensions:
> - Amount of resources (VMs, Volumes, Images, ... of service),
> - Amount of active users (how ofter resource are created/deleted),
> - Size of cloud (amount of nodes)
> - Cloud deployment architecture
> - ...
>
> What I believe is that we should standardize:
>
> - Amount of  resource per service per node
> - Typical sizes of cloud: 10, 20, 50, 100, ... nodes
> - Workloads that we should be run:
>    For example In Rally team we are trying to standardize them here:
>    https://github.com/openstack/rally/tree/master/certification/openstack
> - Deployment Reference Architecture
> - Somebody should find enough resources to run at least for each release
>   those tests on real hardware
>
> And create depending on this few scale tags:
> works-on-X-scale
>
>
> Best regards,
> Boris Pavlovic
>
> On Sat, Sep 26, 2015 at 11:40 AM, Shamail <itzshamail at gmail.com> wrote:
>
>> Hi Large Deployments Team,
>>
>> The ops-tags team was brainstorming potential future tags at our last
>> meeting and one topic of interest was to express the "scale" a service can
>> operate at via tags.
>>
>> Scale, of course, can imply several different dimensions (not to mention
>> test types).  We figured who better to talk to about the definition of
>> scale than the large deployment team.  :-)
>>
>> Can you please help us understand how your team classifies a deployment
>> as being large?  I recall that, in the initial discussions, LDT was using
>> the number of nodes.  Is this still the case?  Does large deployment factor
>> in things such as throughout requirements, number of networks, number of
>> volumes, etc. when deciding if a deployment is "large"?
>>
>> Thanks in advance for your help.  If it makes more sense to discuss this
>> topic at the next LDT meeting then I would be glad to join.
>>
>> Thank you,
>> Shamail Tahir
>> t: @ShamailXD
>> tz: EST
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150926/d8beb8b4/attachment.html>

From runner_cheng at hotmail.com  Sun Sep 27 03:19:42 2015
From: runner_cheng at hotmail.com (RunnerCheng)
Date: Sun, 27 Sep 2015 11:19:42 +0800
Subject: [Openstack-operators] "Master" keystone and "sub" keystone
Message-ID: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>

Hi All,
I'm a newbie of keystone, and I'm doing some research about it recently. I have a question about how to deploy it. The scenario is on below:
 
One comany has one headquarter dc and 5 sub dc locate in different cities. We want to deploy separate OpenStack with "sub" keystone at the sub dc, and want to deploy one "master" keystone at headquarter dc. We want to manage all users, roles and tenants etc on the "master" keystone, however we want the end-user can authenticate with the "sub" keystone where he or she is locate.
  
Is anyone understant this scenario? How to realize it without additionaly development?
  
Thanks in advance!
 
Sam Cheng
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/d46b1e74/attachment.html>

From applyhhj at 163.com  Sun Sep 27 14:59:20 2015
From: applyhhj at 163.com (applyhhj)
Date: Sun, 27 Sep 2015 22:59:20 +0800
Subject: [Openstack-operators] Data transmission failure between VM and
	outside machines
Message-ID: <3096fc63.31f21.1500f50cb96.Coremail.applyhhj@163.com>


Hi, I have setup the openstack cloud and launched VMs in the cloud. At first everything went very well. But yesterday evening, due to some reasons our lab lost power and all servers were shutdown. This morning I turned on all nodes and try to connect to the VM by ssh but failed. I used netstat to check the status of port 22. It shows that connection between VM and machine in the external network can be established. However the ssh process just stuck at SSH2_MSG_KEXINIT sent. Also I setup a rabbitmq server in the VM and the same situation happened. When connecting rabbitmq server through web ui, netstat shows that connections have been established however the web browser can not get any data from the server, it shows a blank page. Also I tried to ssh from one VM to another VM through internal network, the 192.168.1.0/24 network, similar things happened. Does anyone know how to fix this problem? Thank you! By the way the br-ex bridge can only be brought up manually, so after boot the network node I brought up the br-ex bridge and restart all relevant network services in network node. Please help me with this problem. Thank you very much!!

 
Regards!!
hjh
2015-09-27



applyhhj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/b86fccb7/attachment.html>

From itzshamail at gmail.com  Sun Sep 27 17:49:38 2015
From: itzshamail at gmail.com (Shamail Tahir)
Date: Sun, 27 Sep 2015 13:49:38 -0400
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
	for "Scale"
In-Reply-To: <1443312603-sup-6878@fewbar.com>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
 <1443312603-sup-6878@fewbar.com>
Message-ID: <CALrdpTXaGohT4pW5fi6dKyy5Zhyv3GgjTfhSD0jtE9KHwjBfWA@mail.gmail.com>

On Sat, Sep 26, 2015 at 8:10 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Shamail's message of 2015-09-26 11:40:17 -0700:
> > Hi Large Deployments Team,
> >
> > The ops-tags team was brainstorming potential future tags at our last
> meeting and one topic of interest was to express the "scale" a service can
> operate at via tags.
> >
> > Scale, of course, can imply several different dimensions (not to mention
> test types).  We figured who better to talk to about the definition of
> scale than the large deployment team.  :-)
> >
> > Can you please help us understand how your team classifies a deployment
> as being large?  I recall that, in the initial discussions, LDT was using
> the number of nodes.  Is this still the case?  Does large deployment factor
> in things such as throughout requirements, number of networks, number of
> volumes, etc. when deciding if a deployment is "large"?
> >
> > Thanks in advance for your help.  If it makes more sense to discuss this
> topic at the next LDT meeting then I would be glad to join.
>
> I wasn't involved with the discussion, but I think it is an important one.
>
> IMO, the objective way to do this is to add tests for scaling factors,
> like ensuring reasonable resource cost per operation, response time during
> simulated high concurrency, and actual large scale 3rd-party CI. If a
> project hasn't done that, they shouldn't be considered "high scale".
>

I think these are all good suggestions, as a starting point though, our
thought process was that maybe we could use the same criteria as LDT.
Let's say (as an example) that a deployment that is considered a "large
deployment" is using a project then we could then say the project has been
known to achieve "scale".  With this method, we are inferring scale based
on real world deployments rather than establishing it via testing.  I think
both views (testing criteria for scale along with real-world data) probably
have a part to play in the longer term scope of the tag.  Will definitely
factor in your suggestions in the tag description though even if its a
future objective.

>
> (note that I don't think any of the projects actually has these things
> surfaced upstream, but we are definitely going to need these things)
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/e2f53f83/attachment.html>

From itzshamail at gmail.com  Sun Sep 27 17:57:00 2015
From: itzshamail at gmail.com (Shamail Tahir)
Date: Sun, 27 Sep 2015 13:57:00 -0400
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
	for "Scale"
In-Reply-To: <CAD85om0TCY4BsnPZMrezVMN_d6rgqLhb=tvQq=Fg9HnSg8zz8A@mail.gmail.com>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
 <CAD85om0TCY4BsnPZMrezVMN_d6rgqLhb=tvQq=Fg9HnSg8zz8A@mail.gmail.com>
Message-ID: <CALrdpTUry7Pp5SWT3a0pPXusnLvumnPnxeZgk_DsqCNdbRJFMA@mail.gmail.com>

On Sat, Sep 26, 2015 at 8:19 PM, Boris Pavlovic <bpavlovic at mirantis.com>
wrote:

> Shamail,
>
> It's really quite hard thing to standardize because there are few
> dimensions:
> - Amount of resources (VMs, Volumes, Images, ... of service),
> - Amount of active users (how ofter resource are created/deleted),
> - Size of cloud (amount of nodes)
> - Cloud deployment architecture
> - ...
>
> What I believe is that we should standardize:
>
> - Amount of  resource per service per node
> - Typical sizes of cloud: 10, 20, 50, 100, ... nodes
> - Workloads that we should be run:
>    For example In Rally team we are trying to standardize them here:
>    https://github.com/openstack/rally/tree/master/certification/openstack
> - Deployment Reference Architecture
> - Somebody should find enough resources to run at least for each release
>   those tests on real hardware
>

+1, the intention of this email was to get the initial criteria used by the
LDT team to qualify a "large deployment".

We will need to factor in the dimensions as well as establishing a baseline
RA/testing criteria for validation eventually.  Do you think that we should
bring up the "test scale on real HW" with the OpenStack Innovation Center
(OSIC) team since they will have multiple clusters running with 1K nodes
eventually?  I think Clint's reply ties in well with yours (establish
tests, deployment model for testing, and benchmark workloads).

>
> And create depending on this few scale tags:
> works-on-X-scale
>
>
> Best regards,
> Boris Pavlovic
>
> On Sat, Sep 26, 2015 at 11:40 AM, Shamail <itzshamail at gmail.com> wrote:
>
>> Hi Large Deployments Team,
>>
>> The ops-tags team was brainstorming potential future tags at our last
>> meeting and one topic of interest was to express the "scale" a service can
>> operate at via tags.
>>
>> Scale, of course, can imply several different dimensions (not to mention
>> test types).  We figured who better to talk to about the definition of
>> scale than the large deployment team.  :-)
>>
>> Can you please help us understand how your team classifies a deployment
>> as being large?  I recall that, in the initial discussions, LDT was using
>> the number of nodes.  Is this still the case?  Does large deployment factor
>> in things such as throughout requirements, number of networks, number of
>> volumes, etc. when deciding if a deployment is "large"?
>>
>> Thanks in advance for your help.  If it makes more sense to discuss this
>> topic at the next LDT meeting then I would be glad to join.
>>
>> Thank you,
>> Shamail Tahir
>> t: @ShamailXD
>> tz: EST
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/996641e6/attachment.html>

From klindgren at godaddy.com  Sun Sep 27 18:15:58 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Sun, 27 Sep 2015 18:15:58 +0000
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
 for "Scale"
In-Reply-To: <CALrdpTXaGohT4pW5fi6dKyy5Zhyv3GgjTfhSD0jtE9KHwjBfWA@mail.gmail.com>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
 <1443312603-sup-6878@fewbar.com>
 <CALrdpTXaGohT4pW5fi6dKyy5Zhyv3GgjTfhSD0jtE9KHwjBfWA@mail.gmail.com>
Message-ID: <C02C2797-18C4-42E8-9CA6-01578C6ADD1C@godaddy.com>

We (LDT) actually don't have a formal definition of what defines a "large" deployment.  We have historical said that the definition of large is up to the operator to decide.  We have members people who operate the worlds largest public cloud, we have members who operate many many many private clouds of varying size, we have members who currently only operate a small openstack cloud but are trying to grow that in what would be considered by most a "large deployment".  We have others that have a "large deployment" but compared to their other infrastructure consider their deployment fairly small.

I think it would be best to consult the User survey to figure out what constitutes a small/medium/large/huge deployment. We (ops/LDT) can then provide feedback as to if something performs at that scale.  I think part of the feedback needs to be on how a project is used as well.  For Example, we (Godaddy) use neutron for networking, however we do not use tunneling of any type and we do not create virtual routers or private networks and we do not rely on dhcp (we use config-drive to set instance ip configuration).  So areas that other deployments have ran into in the past on scaling neutron (router scheduling performance, router HA, dhcp server performance) we simply avoided (by luck) due to the way that we implemented neutron in our environment.

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Shamail Tahir
Date: Sunday, September 27, 2015 at 11:49 AM
To: Clint Byrum
Cc: openstack-operators
Subject: Re: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"


On Sat, Sep 26, 2015 at 8:10 PM, Clint Byrum <clint at fewbar.com<mailto:clint at fewbar.com>> wrote:
Excerpts from Shamail's message of 2015-09-26 11:40:17 -0700:
> Hi Large Deployments Team,
>
> The ops-tags team was brainstorming potential future tags at our last meeting and one topic of interest was to express the "scale" a service can operate at via tags.
>
> Scale, of course, can imply several different dimensions (not to mention test types).  We figured who better to talk to about the definition of scale than the large deployment team.  :-)
>
> Can you please help us understand how your team classifies a deployment as being large?  I recall that, in the initial discussions, LDT was using the number of nodes.  Is this still the case?  Does large deployment factor in things such as throughout requirements, number of networks, number of volumes, etc. when deciding if a deployment is "large"?
>
> Thanks in advance for your help.  If it makes more sense to discuss this topic at the next LDT meeting then I would be glad to join.

I wasn't involved with the discussion, but I think it is an important one.

IMO, the objective way to do this is to add tests for scaling factors,
like ensuring reasonable resource cost per operation, response time during
simulated high concurrency, and actual large scale 3rd-party CI. If a
project hasn't done that, they shouldn't be considered "high scale".

I think these are all good suggestions, as a starting point though, our thought process was that maybe we could use the same criteria as LDT.  Let's say (as an example) that a deployment that is considered a "large deployment" is using a project then we could then say the project has been known to achieve "scale".  With this method, we are inferring scale based on real world deployments rather than establishing it via testing.  I think both views (testing criteria for scale along with real-world data) probably have a part to play in the longer term scope of the tag.  Will definitely factor in your suggestions in the tag description though even if its a future objective.

(note that I don't think any of the projects actually has these things
surfaced upstream, but we are definitely going to need these things)

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/41477d53/attachment.html>

From Tim.Bell at cern.ch  Sun Sep 27 18:38:46 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Sun, 27 Sep 2015 18:38:46 +0000
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
 for "Scale"
In-Reply-To: <C02C2797-18C4-42E8-9CA6-01578C6ADD1C@godaddy.com>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
 <1443312603-sup-6878@fewbar.com>
 <CALrdpTXaGohT4pW5fi6dKyy5Zhyv3GgjTfhSD0jtE9KHwjBfWA@mail.gmail.com>
 <C02C2797-18C4-42E8-9CA6-01578C6ADD1C@godaddy.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A47401A@CERNXCHG41.cern.ch>

In the past, we considered large deployments as those who were looking at O(1) scalability rather than O(n)? i.e. adding further resources is just business as usual rather than needing a corresponding increase in resources.

 

It was more of a mentality (i.e. CI, config mgmt, automation, acceptance of infrastructure failure) rather than >N nodes or M GBs.

 

Tagging a project is not easy on this basis, however. 

 

Certainly, our experience is variable across projects. Ceilometer, for example, has not been easy to scale. 

 

Tim

 

From: Kris G. Lindgren [mailto:klindgren at godaddy.com] 
Sent: 27 September 2015 20:16
To: Shamail Tahir <itzshamail at gmail.com>; Clint Byrum <clint at fewbar.com>
Cc: openstack-operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"

 

We (LDT) actually don't have a formal definition of what defines a "large" deployment.  We have historical said that the definition of large is up to the operator to decide.  We have members people who operate the worlds largest public cloud, we have members who operate many many many private clouds of varying size, we have members who currently only operate a small openstack cloud but are trying to grow that in what would be considered by most a "large deployment".  We have others that have a "large deployment" but compared to their other infrastructure consider their deployment fairly small.

 

I think it would be best to consult the User survey to figure out what constitutes a small/medium/large/huge deployment. We (ops/LDT) can then provide feedback as to if something performs at that scale.  I think part of the feedback needs to be on how a project is used as well.  For Example, we (Godaddy) use neutron for networking, however we do not use tunneling of any type and we do not create virtual routers or private networks and we do not rely on dhcp (we use config-drive to set instance ip configuration).  So areas that other deployments have ran into in the past on scaling neutron (router scheduling performance, router HA, dhcp server performance) we simply avoided (by luck) due to the way that we implemented neutron in our environment.

 

___________________________________________________________________

Kris Lindgren

Senior Linux Systems Engineer

GoDaddy

 

From: Shamail Tahir
Date: Sunday, September 27, 2015 at 11:49 AM
To: Clint Byrum
Cc: openstack-operators
Subject: Re: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag for "Scale"

 

 

On Sat, Sep 26, 2015 at 8:10 PM, Clint Byrum <clint at fewbar.com <mailto:clint at fewbar.com> > wrote:

Excerpts from Shamail's message of 2015-09-26 11:40:17 -0700:
> Hi Large Deployments Team,
>
> The ops-tags team was brainstorming potential future tags at our last meeting and one topic of interest was to express the "scale" a service can operate at via tags.
>
> Scale, of course, can imply several different dimensions (not to mention test types).  We figured who better to talk to about the definition of scale than the large deployment team.  :-)
>
> Can you please help us understand how your team classifies a deployment as being large?  I recall that, in the initial discussions, LDT was using the number of nodes.  Is this still the case?  Does large deployment factor in things such as throughout requirements, number of networks, number of volumes, etc. when deciding if a deployment is "large"?
>
> Thanks in advance for your help.  If it makes more sense to discuss this topic at the next LDT meeting then I would be glad to join.

I wasn't involved with the discussion, but I think it is an important one.

IMO, the objective way to do this is to add tests for scaling factors,
like ensuring reasonable resource cost per operation, response time during
simulated high concurrency, and actual large scale 3rd-party CI. If a
project hasn't done that, they shouldn't be considered "high scale".

 

I think these are all good suggestions, as a starting point though, our thought process was that maybe we could use the same criteria as LDT.  Let's say (as an example) that a deployment that is considered a "large deployment" is using a project then we could then say the project has been known to achieve "scale".  With this method, we are inferring scale based on real world deployments rather than establishing it via testing.  I think both views (testing criteria for scale along with real-world data) probably have a part to play in the longer term scope of the tag.  Will definitely factor in your suggestions in the tag description though even if its a future objective.


(note that I don't think any of the projects actually has these things
surfaced upstream, but we are definitely going to need these things)

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





 

-- 

Thanks,

Shamail Tahir

t: @ShamailXD

tz: Eastern Time

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/a086c8eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/a086c8eb/attachment.bin>

From matt at mattfischer.com  Sun Sep 27 22:36:37 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Sun, 27 Sep 2015 16:36:37 -0600
Subject: [Openstack-operators] [puppet] feedback request about
	puppet-keystone
In-Reply-To: <56057E07.6070201@redhat.com>
References: <56002E35.2010807@redhat.com>
	<56057E07.6070201@redhat.com>
Message-ID: <CAHr1CO9qCyLetUmx+3WKMUuB+y7ARLJUysvtNtAix2JVrdcK9A@mail.gmail.com>

On Fri, Sep 25, 2015 at 11:01 AM, Emilien Macchi <emilien at redhat.com> wrote:
>
>
> So after 5 days, here is a bit of feedback (13 people did the poll [1]):
>
> 1/ Providers
> Except for 1, most of people are managing a few number of Keystone
> users/tenants.
> I would like to know if it's because the current implementation (using
> openstackclient) is too slow or just because they don't need to do that
> (they use bash, sdk, ansible, etc).
>

I'm generally thinking the opposite of you, I'd actually love to know the
use case for anyone managing more than a few users with Puppet. We have
service users and a few accounts for things like backups, monitoring etc.
Beyond that, the accounts are for actual users and they have to follow an
intake and project creation process that also handles things like networks.
We found this workflow much easier to script with python and it can also be
done without a deploy. This is all handled by a manager after ensuring that
OpenStack is the right solution for them, finding project requirements,
etc. So I think this is what many folks are doing, their user creation
workflow just doesn't mesh with puppet and their puppet deployment process.
 (This also discounts password management, something I don't want to be
doing for users with puppet)



>
> 2/ Features you want
>
> * "Configuration of federation via shibboleth":
> WIP on https://review.openstack.org/#/c/216821/
>
> * "Configuration of federation via mod_mellon":
> Will come after shibboleth I guess.
>
> * "Allow to configure websso"":
> See
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/enabling-federation.html
>
> * "Management of fernet keys":
> nothing *yet* in our roadmap AFIK, adding it in our backlog [2]
>

I looked into this when we deployed but could not come up with a great
solution that didn't involve declaring a master node on which keys were
generated. Would be happy to re-investigate or work with someone on this.


>
> * "Support for hybrid domain configurations (e.g. using both LDAP and
> built in database backend)":
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html
>
> * "Full v3 API support (depends on other modules beyond just
> puppet-keystone)":
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html
>
> * "the ability to upgrade modules independently of one another, like we
> do in production - currently the puppet dependencies dictate the order
> in which we do upgrades more than the OpenStack dependencies":
>
> During the last Summit, we decided [3] as a community that our modules
> branches will only support the OpenStack release of the branch.
> ie: stable/kilo supports OpenStack 2015.1 (Kilo). Maybe you can deploy
> Juno or Liberty with it, but our community does not support it.
> To give a little background, we already discussed about it [4] on the ML.
> Our interface is 100% (or should be) backward compatible for at least
> one full cycle, so you should not have issue when using a new version of
> the module with the same parameters. Though (and indeed), you need to
> keep your modules synchronized, specially because we have libraries and
> common providers (in puppet-keystone).
> AFIK, OpenStack also works like this with openstack/requirements.
> I'm not sure you can run Glance Kilo with Oslo Juno (maybe I'm wrong).
> What you're asking would be technically hard because we would have to
> support old versions of our providers & libraries, with a lot of
> backward compatible & legacy code in place, while we already do a good
> job in the parameters (interface).
> If you have any serious proposal, we would be happy to discuss design
> and find a solution.
>
> 3/ What we could improve in Puppet Keystone (and in general, regarding
> the answers)
>
> * "(...) but it would be nice to be able to deploy master and the most
> recent version immediately rather than wait. Happy to get involved with
> that as our maturity improves and we actually start to use the current
> version earlier. Contribution is hard when you folk are ahead of the
> game, any fixes and additions we have are ancient already":
>
> I would like to understand the issues here:
> do you have problems to contribute?
> is your issue "a feature is in master and not in stable/*" ? If that's
> the case, that means we can do a better job in backport policy.
> Something we already talked each others and I hope our group is aware
> about that.
>
> * "We were using keystone_user_role until we had huge compilation times
> due to the matrix (tenant x role x user) that is not scalable. With
> every single user and tenant on the environment, the catalog compilation
> increased. An improvement on that area will be useful."
>
> I understand the frustration and we are working on it [5].
>
> * "Currently does not handle deployment of hybrid domain configurations."
>
> Ditto:
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html
>
>
> I liked running a poll like this, if you don't mind I'll take time to
> prepare a bigger poll so we can gather more and more feedback, because
> it's really useful. Thanks for that.
>
>
> Discussion is open on this thread about features/concerns mentioned in
> the poll.
>
>
> [1]
>
> https://docs.google.com/forms/d/1Z6IGeJRNmX7xx0Ggmr5Pmpzq7BudphDkZE-3t4Q5G1k/viewanalytics
> [2] https://trello.com/c/HjiWUng3/65-puppet-keystone-manage-fernet-keys
> [3]
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/master-policy.html
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069147.html
> [5] https://bugs.launchpad.net/puppet-keystone/+bug/1493450
> --
> Emilien Macchi
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150927/0dc70888/attachment.html>

From runner_cheng at hotmail.com  Mon Sep 28 05:47:39 2015
From: runner_cheng at hotmail.com (RunnerCheng)
Date: Mon, 28 Sep 2015 13:47:39 +0800
Subject: [Openstack-operators] "Master" keystone and "sub" keystone
In-Reply-To: <CAHr1CO8t3Lehtckj_fDo+WMRGpYg+3XNO+sSx=mpyiROXWd8uA@mail.gmail.com>
References: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>,
 <CAHr1CO8t3Lehtckj_fDo+WMRGpYg+3XNO+sSx=mpyiROXWd8uA@mail.gmail.com>
Message-ID: <BLU173-W142E5E9B26A0C4D9C18B80E74F0@phx.gbl>

Hi Matt Fischer,
 
I'm really appreciating your help! 
I think you point out the directions (regions & federation) which I need to study and research on next setp. 
 
Best Regards,
Sam Cheng
 
Date: Sun, 27 Sep 2015 14:26:58 -0600
Subject: Re: [Openstack-operators] "Master" keystone and "sub" keystone
From: matt at mattfischer.com
To: runner_cheng at hotmail.com

As far as I know you have to do this with regions unless there's something special that can be done with federation. If you're not storing tokens in the DB (which you shouldn't be doing) I'm not sure why you'd want special read-only nodes. Where are your actual services running? Because it's not just the user getting the token, but all your services (cinder, glance, etc) need to validate that token and you'll need to determine which keystone cluster they'll be talking to.
On Sat, Sep 26, 2015 at 9:19 PM, RunnerCheng <runner_cheng at hotmail.com> wrote:



Hi All,
I'm a newbie of keystone, and I'm doing some research about it recently. I have a question about how to deploy it. The scenario is on below:
 
One comany has one headquarter dc and 5 sub dc locate in different cities. We want to deploy separate OpenStack with "sub" keystone at the sub dc, and want to deploy one "master" keystone at headquarter dc. We want to manage all users, roles and tenants etc on the "master" keystone, however we want the end-user can authenticate with the "sub" keystone where he or she is locate.
  
Is anyone understant this scenario? How to realize it without additionaly development?
  
Thanks in advance!
 
Sam Cheng
 		 	   		  

_______________________________________________

OpenStack-operators mailing list

OpenStack-operators at lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/839bc8ec/attachment.html>

From openstack at mikebeauty.com  Mon Sep 28 11:49:43 2015
From: openstack at mikebeauty.com (Miko Bello)
Date: Mon, 28 Sep 2015 13:49:43 +0200
Subject: [Openstack-operators] nova-neutron with vsphere
Message-ID: <NVDY6V$840A5B86ECCB51A8153BB3C082C6F01B@mikebeauty.com>


   Thanks all for your contribution on my request.
   I already knew VIO ( previous version 1.0 ) but i just wanted to see what I could (or could not) do without NSX .

   Miko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/b0076128/attachment.html>

From gord at live.ca  Mon Sep 28 15:17:43 2015
From: gord at live.ca (gord chung)
Date: Mon, 28 Sep 2015 11:17:43 -0400
Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user survey
Message-ID: <BLU436-SMTP2288A2C638F254C7BA01F32DE4F0@phx.gbl>

Hello,

The OpenStack Telemetry (aka Ceilometer) team would like to collect 
feedback and information from its user base in order to drive future 
improvements to the project.  To do so, we have developed a survey. It 
should take about 15min to complete.
Questions are fairly technical, so please ensure that you ask someone 
within your organization that is hands on using Ceilometer.

     https://goo.gl/rKNhM1

On behalf of the Ceilometer community, we thank you for the time you 
will spend in helping us understand your needs.

--
Gordon Chung
Ceilometer PTL


From Tim.Bell at cern.ch  Mon Sep 28 16:24:31 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Mon, 28 Sep 2015 16:24:31 +0000
Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
 survey
In-Reply-To: <BLU436-SMTP2288A2C638F254C7BA01F32DE4F0@phx.gbl>
References: <BLU436-SMTP2288A2C638F254C7BA01F32DE4F0@phx.gbl>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A477C6F@CERNXCHG41.cern.ch>

There seems to be a lot of overlap with the user survey which has just 
finished.  

Feel free to get in touch on the User-committee at lists.openstack.org if you
have questions to suggest to the survey or would like specific queries to be
run on the anonymised data.

There is a significant risk of over surveying the operator community and
then we would lose all the valuable feedback.

Tim

> -----Original Message-----
> From: gord chung [mailto:gord at live.ca]
> Sent: 28 September 2015 17:18
> To: openstack-operators at lists.openstack.org
> Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
> survey
> 
> Hello,
> 
> The OpenStack Telemetry (aka Ceilometer) team would like to collect
> feedback and information from its user base in order to drive future
> improvements to the project.  To do so, we have developed a survey. It
> should take about 15min to complete.
> Questions are fairly technical, so please ensure that you ask someone
within
> your organization that is hands on using Ceilometer.
> 
>      https://goo.gl/rKNhM1
> 
> On behalf of the Ceilometer community, we thank you for the time you will
> spend in helping us understand your needs.
> 
> --
> Gordon Chung
> Ceilometer PTL
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/242ea7ee/attachment.bin>

From serverascode at gmail.com  Mon Sep 28 16:43:29 2015
From: serverascode at gmail.com (Curtis)
Date: Mon, 28 Sep 2015 10:43:29 -0600
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
 <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
Message-ID: <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>

Hi,

For organizations with the keystone database shared across regions via
galera, do you just have keystone (and perhaps glance as was
suggested) in its own cluster that is multi-region, and the other
databases in a cluster that is only in one region (ie. just local
their their region)? Or are you giving other services their own
database in the single multi-region cluster and thus replicating all
the databases? Or is there another solution?

Thanks,
Curtis.

On Tue, Sep 8, 2015 at 3:22 PM, Jonathan Proulx <jon at jonproulx.com> wrote:
> Thanks Jay & Matt,
>
> That's basically what I thought, so I'll keep thinking it :)
>
> We're not replicating glance DB because images will be stored in
> different local Ceph storage on each side so the images won't be
> directly available.  We thought about moving back to a file back end
> and rsync'ing but RBD gets us lots of fun things we want to keep
> (quick start, copy on write thin cloned ephemeral storage etc...) so
> decided to live with making our users copy images around.
>
> -Jon
>
>
>
> On Tue, Sep 8, 2015 at 5:00 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 09/08/2015 04:44 PM, Jonathan Proulx wrote:
>>>
>>> Hi All,
>>>
>>> I'm pretty close to opening a second region in my cloud at a second
>>> physical location.
>>>
>>> The plan so far had been to only share keystone between the regions
>>> (nova, glance, cinder etc would be distinct) and implement this by
>>> using MariaDB with galera replication between sites with each site
>>> having it's own gmcast_segment to minimize the long distance catter
>>> plus a 3rd site with a galera arbitrator for the obvious reason.
>>
>>
>> I would also strongly consider adding the Glance registry database to the
>> same cross-WAN Galera cluster. At AT&T, we had such a setup for Keystone and
>> Glance registry databases at 10+ deployment zones across 6+ datacenters
>> across the nation. Besides adjusting the latency timeout for the Galera
>> settings, we made no other modifications to our
>> internal-to-an-availability-zone Nova database Galera cluster settings.
>>
>> The Keystone and Glance registry databases have a virtually identical read
>> and write data access pattern: small record/row size, small number of
>> INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT operations
>> on a small data set. This data access pattern is an ideal fit for a
>> WAN-replicated Galera cluster.
>>
>>> Today I was warned against using this in a multi writer setup. I'd planned
>>>   on one writer per physical location.
>>
>>
>> I don't know who warned you about this, but it's not an issue in the real
>> world. We ran in full multi-writer mode, with each deployment zone writing
>> to and reading from its nearest Galera cluster nodes. No issues.
>>
>> Best,
>> -jay
>>
>>> I had been under the impression this was the 'done thing' for
>>> geographically sepperate regions, was I wrong? Should I replicate just
>>> for DR and always pick a single possible remote write site?
>>>
>>> site to site link is 2x10G (different physical paths), short link is
>>> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
>>> link shouldn't be much longer but isn't yet complete to test.
>>>
>>> -Jon
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Twitter: @serverascode
Blog: serverascode.com


From matt at mattfischer.com  Mon Sep 28 16:51:28 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Mon, 28 Sep 2015 10:51:28 -0600
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
 <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
 <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>
Message-ID: <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>

Yes. We have a separate DB cluster for global stuff like Keystone &
Designate, and a regional cluster for things like nova/neutron etc.

On Mon, Sep 28, 2015 at 10:43 AM, Curtis <serverascode at gmail.com> wrote:

> Hi,
>
> For organizations with the keystone database shared across regions via
> galera, do you just have keystone (and perhaps glance as was
> suggested) in its own cluster that is multi-region, and the other
> databases in a cluster that is only in one region (ie. just local
> their their region)? Or are you giving other services their own
> database in the single multi-region cluster and thus replicating all
> the databases? Or is there another solution?
>
> Thanks,
> Curtis.
>
> On Tue, Sep 8, 2015 at 3:22 PM, Jonathan Proulx <jon at jonproulx.com> wrote:
> > Thanks Jay & Matt,
> >
> > That's basically what I thought, so I'll keep thinking it :)
> >
> > We're not replicating glance DB because images will be stored in
> > different local Ceph storage on each side so the images won't be
> > directly available.  We thought about moving back to a file back end
> > and rsync'ing but RBD gets us lots of fun things we want to keep
> > (quick start, copy on write thin cloned ephemeral storage etc...) so
> > decided to live with making our users copy images around.
> >
> > -Jon
> >
> >
> >
> > On Tue, Sep 8, 2015 at 5:00 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> >> On 09/08/2015 04:44 PM, Jonathan Proulx wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I'm pretty close to opening a second region in my cloud at a second
> >>> physical location.
> >>>
> >>> The plan so far had been to only share keystone between the regions
> >>> (nova, glance, cinder etc would be distinct) and implement this by
> >>> using MariaDB with galera replication between sites with each site
> >>> having it's own gmcast_segment to minimize the long distance catter
> >>> plus a 3rd site with a galera arbitrator for the obvious reason.
> >>
> >>
> >> I would also strongly consider adding the Glance registry database to
> the
> >> same cross-WAN Galera cluster. At AT&T, we had such a setup for
> Keystone and
> >> Glance registry databases at 10+ deployment zones across 6+ datacenters
> >> across the nation. Besides adjusting the latency timeout for the Galera
> >> settings, we made no other modifications to our
> >> internal-to-an-availability-zone Nova database Galera cluster settings.
> >>
> >> The Keystone and Glance registry databases have a virtually identical
> read
> >> and write data access pattern: small record/row size, small number of
> >> INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT
> operations
> >> on a small data set. This data access pattern is an ideal fit for a
> >> WAN-replicated Galera cluster.
> >>
> >>> Today I was warned against using this in a multi writer setup. I'd
> planned
> >>>   on one writer per physical location.
> >>
> >>
> >> I don't know who warned you about this, but it's not an issue in the
> real
> >> world. We ran in full multi-writer mode, with each deployment zone
> writing
> >> to and reading from its nearest Galera cluster nodes. No issues.
> >>
> >> Best,
> >> -jay
> >>
> >>> I had been under the impression this was the 'done thing' for
> >>> geographically sepperate regions, was I wrong? Should I replicate just
> >>> for DR and always pick a single possible remote write site?
> >>>
> >>> site to site link is 2x10G (different physical paths), short link is
> >>> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
> >>> link shouldn't be much longer but isn't yet complete to test.
> >>>
> >>> -Jon
> >>>
> >>> _______________________________________________
> >>> OpenStack-operators mailing list
> >>> OpenStack-operators at lists.openstack.org
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>>
> >>
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> --
> Twitter: @serverascode
> Blog: serverascode.com
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/746cec13/attachment.html>

From Tim.Bell at cern.ch  Mon Sep 28 17:17:13 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Mon, 28 Sep 2015 17:17:13 +0000
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
 <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
 <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>
 <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A4780BA@CERNXCHG41.cern.ch>

CERN do the same?. The memcache functions on keystone are very useful for scaling it up.

 

Tim

 

From: Matt Fischer [mailto:matt at mattfischer.com] 
Sent: 28 September 2015 18:51
To: Curtis <serverascode at gmail.com>
Cc: openstack-operators at lists.openstack.org; Jonathan Proulx <jon at jonproulx.com>
Subject: Re: [Openstack-operators] Milti-site Keystone & Galera

 

Yes. We have a separate DB cluster for global stuff like Keystone & Designate, and a regional cluster for things like nova/neutron etc.

 

On Mon, Sep 28, 2015 at 10:43 AM, Curtis <serverascode at gmail.com <mailto:serverascode at gmail.com> > wrote:

Hi,

For organizations with the keystone database shared across regions via
galera, do you just have keystone (and perhaps glance as was
suggested) in its own cluster that is multi-region, and the other
databases in a cluster that is only in one region (ie. just local
their their region)? Or are you giving other services their own
database in the single multi-region cluster and thus replicating all
the databases? Or is there another solution?

Thanks,
Curtis.


On Tue, Sep 8, 2015 at 3:22 PM, Jonathan Proulx <jon at jonproulx.com <mailto:jon at jonproulx.com> > wrote:
> Thanks Jay & Matt,
>
> That's basically what I thought, so I'll keep thinking it :)
>
> We're not replicating glance DB because images will be stored in
> different local Ceph storage on each side so the images won't be
> directly available.  We thought about moving back to a file back end
> and rsync'ing but RBD gets us lots of fun things we want to keep
> (quick start, copy on write thin cloned ephemeral storage etc...) so
> decided to live with making our users copy images around.
>
> -Jon
>
>
>
> On Tue, Sep 8, 2015 at 5:00 PM, Jay Pipes <jaypipes at gmail.com <mailto:jaypipes at gmail.com> > wrote:
>> On 09/08/2015 04:44 PM, Jonathan Proulx wrote:
>>>
>>> Hi All,
>>>
>>> I'm pretty close to opening a second region in my cloud at a second
>>> physical location.
>>>
>>> The plan so far had been to only share keystone between the regions
>>> (nova, glance, cinder etc would be distinct) and implement this by
>>> using MariaDB with galera replication between sites with each site
>>> having it's own gmcast_segment to minimize the long distance catter
>>> plus a 3rd site with a galera arbitrator for the obvious reason.
>>
>>
>> I would also strongly consider adding the Glance registry database to the
>> same cross-WAN Galera cluster. At AT&T, we had such a setup for Keystone and
>> Glance registry databases at 10+ deployment zones across 6+ datacenters
>> across the nation. Besides adjusting the latency timeout for the Galera
>> settings, we made no other modifications to our
>> internal-to-an-availability-zone Nova database Galera cluster settings.
>>
>> The Keystone and Glance registry databases have a virtually identical read
>> and write data access pattern: small record/row size, small number of
>> INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT operations
>> on a small data set. This data access pattern is an ideal fit for a
>> WAN-replicated Galera cluster.
>>
>>> Today I was warned against using this in a multi writer setup. I'd planned
>>>   on one writer per physical location.
>>
>>
>> I don't know who warned you about this, but it's not an issue in the real
>> world. We ran in full multi-writer mode, with each deployment zone writing
>> to and reading from its nearest Galera cluster nodes. No issues.
>>
>> Best,
>> -jay
>>
>>> I had been under the impression this was the 'done thing' for
>>> geographically sepperate regions, was I wrong? Should I replicate just
>>> for DR and always pick a single possible remote write site?
>>>
>>> site to site link is 2x10G (different physical paths), short link is
>>> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
>>> link shouldn't be much longer but isn't yet complete to test.
>>>
>>> -Jon
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




--
Twitter: @serverascode
Blog: serverascode.com <http://serverascode.com> 


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/cf31c9b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/cf31c9b9/attachment.bin>

From federico.facca at create-net.org  Mon Sep 28 17:35:21 2015
From: federico.facca at create-net.org (Federico Michele Facca)
Date: Mon, 28 Sep 2015 19:35:21 +0200
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A4780BA@CERNXCHG41.cern.ch>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
 <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
 <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>
 <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A4780BA@CERNXCHG41.cern.ch>
Message-ID: <CABfHRuvkxFmG=L_GwKWP7neYZnH2U+KqH=_BHiYyMRKx7J0dkg@mail.gmail.com>

considering that across dc, latency increase, and that latency may cause
brain splits easily in high read/write, data of other services that are not
global should never be replicated on multisite using a synch approach
(asynch one for disaster recovery, may be good enough!)

Indeed, as Tim said, one of the most important things regarding keystone
distribution, is leveraging on memcached.

Somehow you deal with two totally different data types within keystone:
- user/projects/domain (quite static, i.e. it is not that every second you
change tons of these - so mostly read) -> perfect for db persistency
- tokens (quite dynamics - lot write and read)  -> better managed by
memcached.

An OPNFV group did an interesting analysis on the multisite IdM:

https://etherpad.opnfv.org/p/multisite_identity_management

I think most of the possible architectures are discussed with pro and cons.

Br,
Federico

--
Future Internet is closer than you think!
http://www.fiware.org

Official Mirantis partner for OpenStack Training
https://www.create-net.org/community/openstack-training

-- 
Dr. Federico M. Facca

CREATE-NET
Via alla Cascata 56/D
38123 Povo Trento (Italy)

P  +39 0461 312471
M +39 334 6049758
E  federico.facca at create-net.org
T @chicco785
W  www.create-net.org

On Mon, Sep 28, 2015 at 7:17 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

> CERN do the same?. The memcache functions on keystone are very useful for
> scaling it up.
>
>
>
> Tim
>
>
>
> *From:* Matt Fischer [mailto:matt at mattfischer.com]
> *Sent:* 28 September 2015 18:51
> *To:* Curtis <serverascode at gmail.com>
> *Cc:* openstack-operators at lists.openstack.org; Jonathan Proulx <
> jon at jonproulx.com>
> *Subject:* Re: [Openstack-operators] Milti-site Keystone & Galera
>
>
>
> Yes. We have a separate DB cluster for global stuff like Keystone &
> Designate, and a regional cluster for things like nova/neutron etc.
>
>
>
> On Mon, Sep 28, 2015 at 10:43 AM, Curtis <serverascode at gmail.com> wrote:
>
> Hi,
>
> For organizations with the keystone database shared across regions via
> galera, do you just have keystone (and perhaps glance as was
> suggested) in its own cluster that is multi-region, and the other
> databases in a cluster that is only in one region (ie. just local
> their their region)? Or are you giving other services their own
> database in the single multi-region cluster and thus replicating all
> the databases? Or is there another solution?
>
> Thanks,
> Curtis.
>
>
> On Tue, Sep 8, 2015 at 3:22 PM, Jonathan Proulx <jon at jonproulx.com> wrote:
> > Thanks Jay & Matt,
> >
> > That's basically what I thought, so I'll keep thinking it :)
> >
> > We're not replicating glance DB because images will be stored in
> > different local Ceph storage on each side so the images won't be
> > directly available.  We thought about moving back to a file back end
> > and rsync'ing but RBD gets us lots of fun things we want to keep
> > (quick start, copy on write thin cloned ephemeral storage etc...) so
> > decided to live with making our users copy images around.
> >
> > -Jon
> >
> >
> >
> > On Tue, Sep 8, 2015 at 5:00 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> >> On 09/08/2015 04:44 PM, Jonathan Proulx wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I'm pretty close to opening a second region in my cloud at a second
> >>> physical location.
> >>>
> >>> The plan so far had been to only share keystone between the regions
> >>> (nova, glance, cinder etc would be distinct) and implement this by
> >>> using MariaDB with galera replication between sites with each site
> >>> having it's own gmcast_segment to minimize the long distance catter
> >>> plus a 3rd site with a galera arbitrator for the obvious reason.
> >>
> >>
> >> I would also strongly consider adding the Glance registry database to
> the
> >> same cross-WAN Galera cluster. At AT&T, we had such a setup for
> Keystone and
> >> Glance registry databases at 10+ deployment zones across 6+ datacenters
> >> across the nation. Besides adjusting the latency timeout for the Galera
> >> settings, we made no other modifications to our
> >> internal-to-an-availability-zone Nova database Galera cluster settings.
> >>
> >> The Keystone and Glance registry databases have a virtually identical
> read
> >> and write data access pattern: small record/row size, small number of
> >> INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT
> operations
> >> on a small data set. This data access pattern is an ideal fit for a
> >> WAN-replicated Galera cluster.
> >>
> >>> Today I was warned against using this in a multi writer setup. I'd
> planned
> >>>   on one writer per physical location.
> >>
> >>
> >> I don't know who warned you about this, but it's not an issue in the
> real
> >> world. We ran in full multi-writer mode, with each deployment zone
> writing
> >> to and reading from its nearest Galera cluster nodes. No issues.
> >>
> >> Best,
> >> -jay
> >>
> >>> I had been under the impression this was the 'done thing' for
> >>> geographically sepperate regions, was I wrong? Should I replicate just
> >>> for DR and always pick a single possible remote write site?
> >>>
> >>> site to site link is 2x10G (different physical paths), short link is
> >>> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long
> >>> link shouldn't be much longer but isn't yet complete to test.
> >>>
> >>> -Jon
> >>>
> >>> _______________________________________________
> >>> OpenStack-operators mailing list
> >>> OpenStack-operators at lists.openstack.org
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>>
> >>
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> --
> Twitter: @serverascode
> Blog: serverascode.com
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/d477383f/attachment.html>

From jaypipes at gmail.com  Mon Sep 28 18:06:11 2015
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 28 Sep 2015 14:06:11 -0400
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
 <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
 <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>
 <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>
Message-ID: <56098193.8000108@gmail.com>

On 09/28/2015 12:51 PM, Matt Fischer wrote:
> Yes. We have a separate DB cluster for global stuff like Keystone &
> Designate, and a regional cluster for things like nova/neutron etc.

Yep, this ^

-jay


From gord at live.ca  Mon Sep 28 18:30:41 2015
From: gord at live.ca (gord chung)
Date: Mon, 28 Sep 2015 14:30:41 -0400
Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
 survey
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A477C6F@CERNXCHG41.cern.ch>
References: <BLU436-SMTP2288A2C638F254C7BA01F32DE4F0@phx.gbl>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A477C6F@CERNXCHG41.cern.ch>
Message-ID: <BLU436-SMTP242DE01BD410147CB992F0DDE4F0@phx.gbl>

hi Tim,

it's not our intention to over-survey the community -- i apologise if 
this is your takeaway. the user survey that just finished was aimed to 
gather information regarding general OpenStack practices (one question 
being assigned to each project).

the idea here is to have a dialogue between user and developers 
specifically regarding Ceilometer. creating this survey, the goal is to 
gather specific information regarding each of the components of 
Ceilometer so we know to 'work on component xyz of Ceilometer' rather 
than 'work on Ceilometer'.

please have a look at the survey at your own convenience and interest -- 
feedback is welcomed at any time. this will help the community 
continuously know what the use cases/gaps are.


On 28/09/2015 12:24 PM, Tim Bell wrote:
> There seems to be a lot of overlap with the user survey which has just
> finished.
>
> Feel free to get in touch on the User-committee at lists.openstack.org if you
> have questions to suggest to the survey or would like specific queries to be
> run on the anonymised data.
>
> There is a significant risk of over surveying the operator community and
> then we would lose all the valuable feedback.
>
> Tim
>
>> -----Original Message-----
>> From: gord chung [mailto:gord at live.ca]
>> Sent: 28 September 2015 17:18
>> To: openstack-operators at lists.openstack.org
>> Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
>> survey
>>
>> Hello,
>>
>> The OpenStack Telemetry (aka Ceilometer) team would like to collect
>> feedback and information from its user base in order to drive future
>> improvements to the project.  To do so, we have developed a survey. It
>> should take about 15min to complete.
>> Questions are fairly technical, so please ensure that you ask someone
> within
>> your organization that is hands on using Ceilometer.
>>
>>       https://goo.gl/rKNhM1
>>
>> On behalf of the Ceilometer community, we thank you for the time you will
>> spend in helping us understand your needs.
>>
>> --
>> Gordon Chung
>> Ceilometer PTL
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
gord



From jj at chef.io  Mon Sep 28 18:32:23 2015
From: jj at chef.io (JJ Asghar)
Date: Mon, 28 Sep 2015 13:32:23 -0500
Subject: [Openstack-operators] [openstack-operators][osops] First
	contribution
Message-ID: <560987B7.4090203@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey everyone!

I wanted to point out that we have had our first official contribution
to OSOps today. [1][2] comes from David Wahlstrom, and I want to
personally thank him for this.

For the time being we are just looking for contributions, so if you have
something that can fit please don't hesitate to commit!

Everyone please take a moment for David to thank him for getting the
ball rolling!

[1]: https://review.openstack.org/228545
[2]: https://review.openstack.org/228534

- -JJ

- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCYe2AAoJEDZbxzMH0+jTKwsP/1W33yZ9vzn7mzdH6029Es8U
6jcPlikyboQBAedVeU9k9vzO+Mh5fPXvuk88dkX40+07Rok2VN6gS1/q9Lqr85h9
/xH3DzHoMF3bIoo3d54ULUzjfq08b6BrjBSGKd3rd13G4Dr81YAKwqCMHI/PPTS/
bJHXUsjFvZOanicPt1ndw5tdQcd2Rm+kZeiWl4xY/zFDreAXTYtUqAlVPXy+ueLk
LHg7DLMzA5Sztx0bW7NvmqN3ZftVuyXfSz53xtsXqh7CBgVrTXd7vT1luCI3Ytea
ABymELKbW+fYlKZ4WURTFvMNOqtGg6YLS8vA3UuMA1MdUAXUVzO+xx46D/XBEdcY
WPjmRDjYinJpJmeNepkj2rUJ39joNILdv70rt2vkf1uvzr0pGaZwmVydozy9EZ9T
isGTJXWBwakrEn7tkt3VUBTofnOREtdeRA6aXdK5Y40suKzrexfxPRu5hHF/Bsei
Khzrn1SX6b1yVzpnCJA/V3LU341P1CbDCKS/ljhHS4PJpS/pNCfQcEJ/00pywe8L
Y9t+w9GFmDC/2zHD1N3ak2eVmZ6nfrzlW/P0oi/l3itsuo4A90o/Yh52TsW6gn2q
Xo5d7SUILhl9JxfdyY63hFvCbPqlHGTelVhcZNpwUwbo2ri0xE1w19C/nODtlntA
Gpu6jIZPtsbi7bAYdB/+
=J+RD
-----END PGP SIGNATURE-----



From Tim.Bell at cern.ch  Mon Sep 28 18:42:35 2015
From: Tim.Bell at cern.ch (Tim Bell)
Date: Mon, 28 Sep 2015 18:42:35 +0000
Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
 survey
In-Reply-To: <BLU436-SMTP242DE01BD410147CB992F0DDE4F0@phx.gbl>
References: <BLU436-SMTP2288A2C638F254C7BA01F32DE4F0@phx.gbl>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A477C6F@CERNXCHG41.cern.ch>
 <BLU436-SMTP242DE01BD410147CB992F0DDE4F0@phx.gbl>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5010A4785E5@CERNXCHG41.cern.ch>

I have started a thread on User-committee at lists.openstack.org so we can try
to find the right balance between ensuring the surveys are completed and
meeting the needs for more detailed information for the projects.

Tim

> -----Original Message-----
> From: gord chung [mailto:gord at live.ca]
> Sent: 28 September 2015 20:31
> To: Tim Bell <Tim.Bell at cern.ch>; openstack-operators at lists.openstack.org
> Subject: Re: [Openstack-operators] [ceilometer] OpenStack Telemetry user
> survey
> 
> hi Tim,
> 
> it's not our intention to over-survey the community -- i apologise if this
is
> your takeaway. the user survey that just finished was aimed to gather
> information regarding general OpenStack practices (one question being
> assigned to each project).
> 
> the idea here is to have a dialogue between user and developers
specifically
> regarding Ceilometer. creating this survey, the goal is to gather specific
> information regarding each of the components of Ceilometer so we know to
> 'work on component xyz of Ceilometer' rather than 'work on Ceilometer'.
> 
> please have a look at the survey at your own convenience and interest --
> feedback is welcomed at any time. this will help the community
continuously
> know what the use cases/gaps are.
> 
> 
> On 28/09/2015 12:24 PM, Tim Bell wrote:
> > There seems to be a lot of overlap with the user survey which has just
> > finished.
> >
> > Feel free to get in touch on the User-committee at lists.openstack.org if
> > you have questions to suggest to the survey or would like specific
> > queries to be run on the anonymised data.
> >
> > There is a significant risk of over surveying the operator community
> > and then we would lose all the valuable feedback.
> >
> > Tim
> >
> >> -----Original Message-----
> >> From: gord chung [mailto:gord at live.ca]
> >> Sent: 28 September 2015 17:18
> >> To: openstack-operators at lists.openstack.org
> >> Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
> >> survey
> >>
> >> Hello,
> >>
> >> The OpenStack Telemetry (aka Ceilometer) team would like to collect
> >> feedback and information from its user base in order to drive future
> >> improvements to the project.  To do so, we have developed a survey.
> >> It should take about 15min to complete.
> >> Questions are fairly technical, so please ensure that you ask someone
> > within
> >> your organization that is hands on using Ceilometer.
> >>
> >>       https://goo.gl/rKNhM1
> >>
> >> On behalf of the Ceilometer community, we thank you for the time you
> >> will spend in helping us understand your needs.
> >>
> >> --
> >> Gordon Chung
> >> Ceilometer PTL
> >>
> >> _______________________________________________
> >> OpenStack-operators mailing list
> >> OpenStack-operators at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operato
> >> rs
> 
> --
> gord

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7349 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/f39eea97/attachment.bin>

From ayoung at redhat.com  Mon Sep 28 19:31:54 2015
From: ayoung at redhat.com (Adam Young)
Date: Mon, 28 Sep 2015 15:31:54 -0400
Subject: [Openstack-operators] "Master" keystone and "sub" keystone
In-Reply-To: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>
References: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>
Message-ID: <560995AA.5040808@redhat.com>

On 09/26/2015 11:19 PM, RunnerCheng wrote:
> Hi All,
> I'm a newbie of keystone, and I'm doing some research about it 
> recently. I have a question about how to deploy it. The scenario is on 
> below:
>
> One comany has one headquarter dc and 5 sub dc locate in different 
> cities. We want to deploy separate OpenStack with "sub" keystone at 
> the sub dc, and want to deploy one "master" keystone at headquarter 
> dc. We want to manage all users, roles and tenants etc on the "master" 
> keystone, however we want the end-user can authenticate with the "sub" 
> keystone where he or she is locate.


Use LDAP for the users, don't keep them in Keystone.

Replicate roles, projects etc from master to sub.

Use Fernet tokens.  Replicate revocation events both ways.


>
> Is anyone understant this scenario? How to realize it without 
> additionaly development?
>
> Thanks in advance!
>
> Sam Cheng
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/7a0c57c4/attachment.html>

From jon at csail.mit.edu  Mon Sep 28 19:46:50 2015
From: jon at csail.mit.edu (Jonathan Proulx)
Date: Mon, 28 Sep 2015 15:46:50 -0400
Subject: [Openstack-operators] "Master" keystone and "sub" keystone
In-Reply-To: <560995AA.5040808@redhat.com>
References: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>
 <560995AA.5040808@redhat.com>
Message-ID: <20150928194650.GO24467@csail.mit.edu>

On Mon, Sep 28, 2015 at 03:31:54PM -0400, Adam Young wrote:
:On 09/26/2015 11:19 PM, RunnerCheng wrote:
:>Hi All,
:>I'm a newbie of keystone, and I'm doing some research about it
:>recently. I have a question about how to deploy it. The scenario is
:>on below:
:>
:>One comany has one headquarter dc and 5 sub dc locate in different
:>cities. We want to deploy separate OpenStack with "sub" keystone at
:>the sub dc, and want to deploy one "master" keystone at headquarter
:>dc. We want to manage all users, roles and tenants etc on the
:>"master" keystone, however we want the end-user can authenticate
:>with the "sub" keystone where he or she is locate.
:
:
:Use LDAP for the users, don't keep them in Keystone.
:
:Replicate roles, projects etc from master to sub.
:
:Use Fernet tokens.  Replicate revocation events both ways.

I'm hearing conflicting advice about the suitibility of Fernet tokens
for production use.

I like the idea. I did get them to work in kilo trivially for CLI, but
Horizon was unhappy for reasons I didn't fully investigate as I heard
they 'weren't quite ready in kilo' so I defered further investigation
to next cycle.

Though honestly if you're building somthing new right now starting
with Liberty is probably the right thing anyway by the time you're
done PoC it will be released.

-Jon


From matt at mattfischer.com  Mon Sep 28 20:06:00 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Mon, 28 Sep 2015 14:06:00 -0600
Subject: [Openstack-operators] "Master" keystone and "sub" keystone
In-Reply-To: <20150928194650.GO24467@csail.mit.edu>
References: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>
 <560995AA.5040808@redhat.com>
 <20150928194650.GO24467@csail.mit.edu>
Message-ID: <CAHr1CO9sSjwb6ug-9D9K2Zt8Y6WWxQON1ZPecWojqZkMstPV+A@mail.gmail.com>

On Mon, Sep 28, 2015 at 1:46 PM, Jonathan Proulx <jon at csail.mit.edu> wrote:

> On Mon, Sep 28, 2015 at 03:31:54PM -0400, Adam Young wrote:
> :On 09/26/2015 11:19 PM, RunnerCheng wrote:
> :>Hi All,
> :>I'm a newbie of keystone, and I'm doing some research about it
> :>recently. I have a question about how to deploy it. The scenario is
> :>on below:
> :>
> :>One comany has one headquarter dc and 5 sub dc locate in different
> :>cities. We want to deploy separate OpenStack with "sub" keystone at
> :>the sub dc, and want to deploy one "master" keystone at headquarter
> :>dc. We want to manage all users, roles and tenants etc on the
> :>"master" keystone, however we want the end-user can authenticate
> :>with the "sub" keystone where he or she is locate.
> :
> :
> :Use LDAP for the users, don't keep them in Keystone.
> :
> :Replicate roles, projects etc from master to sub.
> :
> :Use Fernet tokens.  Replicate revocation events both ways.
>
> I'm hearing conflicting advice about the suitibility of Fernet tokens
> for production use.
>
> I like the idea. I did get them to work in kilo trivially for CLI, but
> Horizon was unhappy for reasons I didn't fully investigate as I heard
> they 'weren't quite ready in kilo' so I defered further investigation
> to next cycle.
>
> Though honestly if you're building somthing new right now starting
> with Liberty is probably the right thing anyway by the time you're
> done PoC it will be released.
>
> -Jon


We're using them in prod, generally happy except with Validation
performance. For Horizon we run off of master anyway but you have to pull
in some code from Liberty or it won't work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/e3e01f80/attachment.html>

From jon at csail.mit.edu  Mon Sep 28 20:20:56 2015
From: jon at csail.mit.edu (Jonathan Proulx)
Date: Mon, 28 Sep 2015 16:20:56 -0400
Subject: [Openstack-operators] "Master" keystone and "sub" keystone
In-Reply-To: <CAHr1CO9sSjwb6ug-9D9K2Zt8Y6WWxQON1ZPecWojqZkMstPV+A@mail.gmail.com>
References: <BLU173-W23A391B0F6C6616372E1EE7400@phx.gbl>
 <560995AA.5040808@redhat.com>
 <20150928194650.GO24467@csail.mit.edu>
 <CAHr1CO9sSjwb6ug-9D9K2Zt8Y6WWxQON1ZPecWojqZkMstPV+A@mail.gmail.com>
Message-ID: <20150928202056.GP24467@csail.mit.edu>

On Mon, Sep 28, 2015 at 02:06:00PM -0600, Matt Fischer wrote:
:On Mon, Sep 28, 2015 at 1:46 PM, Jonathan Proulx <jon at csail.mit.edu> wrote:

:> I'm hearing conflicting advice about the suitibility of Fernet tokens
:> for production use.
:>
:> I like the idea. I did get them to work in kilo trivially for CLI, but
:> Horizon was unhappy for reasons I didn't fully investigate as I heard
:> they 'weren't quite ready in kilo' so I defered further investigation
:> to next cycle.
:>
:> Though honestly if you're building somthing new right now starting
:> with Liberty is probably the right thing anyway by the time you're
:> done PoC it will be released.
:>
:> -Jon
:
:
:We're using them in prod, generally happy except with Validation
:performance. For Horizon we run off of master anyway but you have to pull
:in some code from Liberty or it won't work.

Thanks that's actually very good to know.  I have a recent master
version of Horizon that I hope to move to production soon, so if it's
all Horizon issues I may make the move to Fernet in production sooner
rather than later.

-Jon


From pgsousa at gmail.com  Mon Sep 28 21:49:54 2015
From: pgsousa at gmail.com (Pedro Sousa)
Date: Mon, 28 Sep 2015 22:49:54 +0100
Subject: [Openstack-operators] Kilo NFV Performance Optimization advices on
	compute nodes
Message-ID: <CA+E02ZBWeQYDAVCuu1QsvcT9y_ODCzWMTmZ8sGCMTLFam6NK1g@mail.gmail.com>

Hi all,

I'm trying to deploy some nfv apps on my Openstack deployment, however I'm
having some performance issues in my VMs, that start to lose UDP packets at
a specific packet transmission rate.

 Here's what I've tried and found so far:

- VMs Centos 7.1 with 10GBe Neutron SR-IOV nics
- Configured Memory Hugepages:
http://redhatstackblog.redhat.com/tag/huge-pages/
- Configured CPU Pinning and NUMA Topology:
- Increased memory network buffers in kernel
- Running "egrep ens6 /proc/interrupts" I see network Interrupts are not
balanced evenly inside my guest across CPU cores, always hitting the same
CPU.

Concerning this last issue does anybody have some good advices on how to
tackle this, how can I share the network load across the vcpus inside the
guest or am I looking in the wrong direction?

Some pointers would be appreciated.

Regards,
Pedro Sousa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/c9d9b5e5/attachment.html>

From serverascode at gmail.com  Mon Sep 28 21:52:54 2015
From: serverascode at gmail.com (Curtis)
Date: Mon, 28 Sep 2015 15:52:54 -0600
Subject: [Openstack-operators] Milti-site Keystone & Galera
In-Reply-To: <56098193.8000108@gmail.com>
References: <CABZB-shuYnWEasfX04n+LEwNv0XNHUOHYRb9UVyAniM7w+SUpQ@mail.gmail.com>
 <55EF4C50.7020109@gmail.com>
 <CABZB-sjTrSTcDmVtQkSA8PfZ8-eJjc0ZG_VEvJqvJg7swuL0AA@mail.gmail.com>
 <CAJ_JamD61TC+3eNV6dtzpS_xG3gM+FdN3Z+_2GYYneH2zhV8wQ@mail.gmail.com>
 <CAHr1CO_Y4roDE2fTr+zW-Ugd5FZaJCxWftc1oMUUQ=vS+vUV1w@mail.gmail.com>
 <56098193.8000108@gmail.com>
Message-ID: <CAJ_JamBCJCG3BX_N34P1WV5S15A10wkFUeU0DVyJwgqjr-66bw@mail.gmail.com>

OK thanks for the input everyone, much appreciated.

Thanks,
Curtis.

On Mon, Sep 28, 2015 at 12:06 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 09/28/2015 12:51 PM, Matt Fischer wrote:
>>
>> Yes. We have a separate DB cluster for global stuff like Keystone &
>> Designate, and a regional cluster for things like nova/neutron etc.
>
>
> Yep, this ^
>
> -jay
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Twitter: @serverascode
Blog: serverascode.com


From david.wahlstrom at gmail.com  Mon Sep 28 22:02:07 2015
From: david.wahlstrom at gmail.com (David Wahlstrom)
Date: Mon, 28 Sep 2015 15:02:07 -0700
Subject: [Openstack-operators] [openstack-operators][osops] First
	contribution
In-Reply-To: <560987B7.4090203@chef.io>
References: <560987B7.4090203@chef.io>
Message-ID: <CAJ4zFrYzxcpq2Nh3E4hoPv5dGMEXP1XxaVS7YhO0RhXDiVm5Fg@mail.gmail.com>

Thanks for the warm invite.  Hopefully my experience at
Dreamhost/DreamCompute will provide useful to this team!

On Mon, Sep 28, 2015 at 11:32 AM, JJ Asghar <jj at chef.io> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hey everyone!
>
> I wanted to point out that we have had our first official contribution
> to OSOps today. [1][2] comes from David Wahlstrom, and I want to
> personally thank him for this.
>
> For the time being we are just looking for contributions, so if you have
> something that can fit please don't hesitate to commit!
>
> Everyone please take a moment for David to thank him for getting the
> ball rolling!
>
> [1]: https://review.openstack.org/228545
> [2]: https://review.openstack.org/228534
>
> - -JJ
>
> - --
> Best Regards,
> JJ Asghar
> c: 512.619.0722 t: @jjasghar irc: j^2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJWCYe2AAoJEDZbxzMH0+jTKwsP/1W33yZ9vzn7mzdH6029Es8U
> 6jcPlikyboQBAedVeU9k9vzO+Mh5fPXvuk88dkX40+07Rok2VN6gS1/q9Lqr85h9
> /xH3DzHoMF3bIoo3d54ULUzjfq08b6BrjBSGKd3rd13G4Dr81YAKwqCMHI/PPTS/
> bJHXUsjFvZOanicPt1ndw5tdQcd2Rm+kZeiWl4xY/zFDreAXTYtUqAlVPXy+ueLk
> LHg7DLMzA5Sztx0bW7NvmqN3ZftVuyXfSz53xtsXqh7CBgVrTXd7vT1luCI3Ytea
> ABymELKbW+fYlKZ4WURTFvMNOqtGg6YLS8vA3UuMA1MdUAXUVzO+xx46D/XBEdcY
> WPjmRDjYinJpJmeNepkj2rUJ39joNILdv70rt2vkf1uvzr0pGaZwmVydozy9EZ9T
> isGTJXWBwakrEn7tkt3VUBTofnOREtdeRA6aXdK5Y40suKzrexfxPRu5hHF/Bsei
> Khzrn1SX6b1yVzpnCJA/V3LU341P1CbDCKS/ljhHS4PJpS/pNCfQcEJ/00pywe8L
> Y9t+w9GFmDC/2zHD1N3ak2eVmZ6nfrzlW/P0oi/l3itsuo4A90o/Yh52TsW6gn2q
> Xo5d7SUILhl9JxfdyY63hFvCbPqlHGTelVhcZNpwUwbo2ri0xE1w19C/nODtlntA
> Gpu6jIZPtsbi7bAYdB/+
> =J+RD
> -----END PGP SIGNATURE-----
>
>


-- 
David W.
Unix, because every barista in Seattle has an MCSE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/544c04e6/attachment.html>

From david.wahlstrom at gmail.com  Mon Sep 28 22:21:34 2015
From: david.wahlstrom at gmail.com (David Wahlstrom)
Date: Mon, 28 Sep 2015 15:21:34 -0700
Subject: [Openstack-operators] Live snapshots on the raw disks never ends
In-Reply-To: <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>
References: <5603F462.6050905@gmail.com>
 <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>
Message-ID: <CAJ4zFraKkU45PboJkeyYFfdBkC6aUxE1TSm98eVVfNSnNtL2DA@mail.gmail.com>

George,

What is your storage backend using (Gluster/ceph/local disk/etc)?  Some of
the distributed backend drivers have bugs in them or mask the real issue
(such as watchers on objects).

On Thu, Sep 24, 2015 at 8:11 AM, Kris G. Lindgren <klindgren at godaddy.com>
wrote:

> I believe I was talking to Josh Harlow (he's harlowja in
> #openstack-operators on freenode) from Yahoo, about something like this the
> other day.  He was saying that recently on a few hypervisors they would
> randomly run into HV disks that were completely full due to snapshots.  I
> have not personally ran into this, so I can't be of more help.
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
>
>
>
>
> On 9/24/15, 7:02 AM, "George Shuklin" <george.shuklin at gmail.com> wrote:
>
> >Hello everyone.
> >
> >Is someone ever saw 'endless snapshot' problem? Some instances (with raw
> >disks and live snapshoting enabled) are stuck at image_uploading forever.
> >
> >It looks like this:
> >
>
> >+--------------------------------------+----------------------------------------------------------+
> >| Property                             | Value
>                         |
>
> >+--------------------------------------+----------------------------------------------------------+
> >| status                               | ACTIVE
>                          |
> >| updated                              | 2015-07-16T08:07:00Z
>                          |
> >| OS-EXT-STS:task_state                | image_uploading
>                         |
> >| OS-EXT-SRV-ATTR:host                 | compute
>                         |
> >| key_name                             | ses
>                         |
> >| image                                | Ubuntu 14.04
> (3736af94-b25e-4b8d-96fd-fd5949bbd81e)      |
> >| OS-EXT-STS:vm_state                  | active
>                          |
> >| OS-EXT-SRV-ATTR:instance_name        | instance-0000000d
>                         |
> >| OS-SRV-USG:launched_at               | 2015-05-09T17:28:09.000000
>                          |
> >| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.lab.internal
>                          |
> >| flavor                               | flavor2 (2)
>                         |
> >| id                                   |
> f2365fe4-9b30-4c24-b7b9-f7fcb4165160                     |
> >| security_groups                      | [{u'name': u'default'}]
>                         |
> >| OS-SRV-USG:terminated_at             | None
>                          |
> >| user_id                              |
> 61096c639d674e4cb8bf487cec01432a                         |
> >| name                                 | non-test
>                          |
> >| created                              | 2015-05-09T17:27:48Z
>                          |
> >...etc
> >
> >Any ideas why this happens? All logs are clear, no errors or anything.
> >And it happens at random so no 'debug' log available...
> >
> >_______________________________________________
> >OpenStack-operators mailing list
> >OpenStack-operators at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
David W.
Unix, because every barista in Seattle has an MCSE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/e7014171/attachment-0001.html>

From e0ne at e0ne.info  Mon Sep 28 22:25:04 2015
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Tue, 29 Sep 2015 01:25:04 +0300
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The future of
	Cinder API v1
Message-ID: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>

Hi all,

As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API was
introduced in Grizzly and v1 API is deprecated since Juno.

After [1] is merged, Cinder API v1 is disabled in gates by default. We've
got a filed bug [2] to remove Cinder v1 API at all.


According to Deprecation Policy [3] looks like we are OK to remote it. But
I would like to ask Cinder API users if any still use API v1.
Should we remove it at all Mitaka release or just disable by default in the
cinder.conf?

AFAIR, only Rally doesn't support API v2 now and I'm going to implement it
asap.

[1] https://review.openstack.org/194726
[2] https://bugs.launchpad.net/cinder/+bug/1467589
[3]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html

Regards,
Ivan Kolodyazhny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/3adab28d/attachment.html>

From pieter.c.kruithof-jr at hpe.com  Mon Sep 28 22:24:11 2015
From: pieter.c.kruithof-jr at hpe.com (Kruithof, Piet)
Date: Mon, 28 Sep 2015 22:24:11 +0000
Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
 survey
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5010A4785E5@CERNXCHG41.cern.ch>
References: <BLU436-SMTP2288A2C638F254C7BA01F32DE4F0@phx.gbl>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A477C6F@CERNXCHG41.cern.ch>
 <BLU436-SMTP242DE01BD410147CB992F0DDE4F0@phx.gbl>
 <5D7F9996EA547448BC6C54C8C5AAF4E5010A4785E5@CERNXCHG41.cern.ch>
Message-ID: <D22F19FE.184EB%pieter.c.kruithof-jr@hp.com>

Hi Tim,

Thanks for addressing some of the potential challenges around conducting
surveys on behalf of the community.

The research conducted by the OpenStack UX project, including surveys,
tend to focus on specific project needs rather than the overall direction
of the industry, which is captured by the bi-annual survey. The project
surveys generally require a fair amount of detail in order to enable the
project teams to make decision around product direction. As a result,
adding a few questions to the foundation?s survey doesn?t generate the
level of detail typically needed by each project. Also, any questions
added to the bi-annual survey are at the discretion of the user committee,
which is a concern for me.

In addition, waiting for a survey every six months would not allow us to
be responsive to the project research needs.

I agree with your concern with population fatigue and we would prefer to
conduct studies with a more focused sample rather than the overall
OpenStack community. For example, we may specifically focus on network
admins during one survey while focusing on other roles during another
study. In those cases, user/operators
have generally been willing to participate because the results should have
a tangible impact on their daily activities.

One recommendation would be to distribute a screener to the overall
community to identify the specific skills and focus of its members. The
user committee and project
teams could use the database created from the screener to identify
potential participants for the various research activities. The goal would
be to be more focused on how
we recruit participants rather than rolling out to the entire community.
It would also allow us to track and limit how often members are being
invited to participate in studies to avoid population fatigue. The
screener would also respondents to opt of being recruited for research
activities.

We?ve asked in the past, but the user committee has not been unable to
provide anonymized data because of a policy within the foundation that
limits access to data to a handful of users. I don?t dispute the need for
the policy, but summary statistics aren?t helpful for conducting
statistical analysis. More recently, we?ve asked for the raw data from the
operator job analysis survey because of its value in helping to drive
persona development, but have yet to hear back from the foundation.

Piet




Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project


"For every complex problem, there is a solution that is simple, neat and
wrong.?

H L Menken





On 9/28/15, 12:42 PM, "Tim Bell" <Tim.Bell at cern.ch> wrote:

>I have started a thread on User-committee at lists.openstack.org so we can
>try
>to find the right balance between ensuring the surveys are completed and
>meeting the needs for more detailed information for the projects.
>
>Tim
>
>> -----Original Message-----
>> From: gord chung [mailto:gord at live.ca]
>> Sent: 28 September 2015 20:31
>> To: Tim Bell <Tim.Bell at cern.ch>; openstack-operators at lists.openstack.org
>> Subject: Re: [Openstack-operators] [ceilometer] OpenStack Telemetry user
>> survey
>> 
>> hi Tim,
>> 
>> it's not our intention to over-survey the community -- i apologise if
>>this
>is
>> your takeaway. the user survey that just finished was aimed to gather
>> information regarding general OpenStack practices (one question being
>> assigned to each project).
>> 
>> the idea here is to have a dialogue between user and developers
>specifically
>> regarding Ceilometer. creating this survey, the goal is to gather
>>specific
>> information regarding each of the components of Ceilometer so we know to
>> 'work on component xyz of Ceilometer' rather than 'work on Ceilometer'.
>> 
>> please have a look at the survey at your own convenience and interest --
>> feedback is welcomed at any time. this will help the community
>continuously
>> know what the use cases/gaps are.
>> 
>> 
>> On 28/09/2015 12:24 PM, Tim Bell wrote:
>> > There seems to be a lot of overlap with the user survey which has just
>> > finished.
>> >
>> > Feel free to get in touch on the User-committee at lists.openstack.org if
>> > you have questions to suggest to the survey or would like specific
>> > queries to be run on the anonymised data.
>> >
>> > There is a significant risk of over surveying the operator community
>> > and then we would lose all the valuable feedback.
>> >
>> > Tim
>> >
>> >> -----Original Message-----
>> >> From: gord chung [mailto:gord at live.ca]
>> >> Sent: 28 September 2015 17:18
>> >> To: openstack-operators at lists.openstack.org
>> >> Subject: [Openstack-operators] [ceilometer] OpenStack Telemetry user
>> >> survey
>> >>
>> >> Hello,
>> >>
>> >> The OpenStack Telemetry (aka Ceilometer) team would like to collect
>> >> feedback and information from its user base in order to drive future
>> >> improvements to the project.  To do so, we have developed a survey.
>> >> It should take about 15min to complete.
>> >> Questions are fairly technical, so please ensure that you ask someone
>> > within
>> >> your organization that is hands on using Ceilometer.
>> >>
>> >>       https://goo.gl/rKNhM1
>> >>
>> >> On behalf of the Ceilometer community, we thank you for the time you
>> >> will spend in helping us understand your needs.
>> >>
>> >> --
>> >> Gordon Chung
>> >> Ceilometer PTL
>> >>
>> >> _______________________________________________
>> >> OpenStack-operators mailing list
>> >> OpenStack-operators at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operato
>> >> rs
>> 
>> --
>> gord
>



From matt at mattfischer.com  Mon Sep 28 22:34:33 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Mon, 28 Sep 2015 16:34:33 -0600
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The future
 of Cinder API v1
In-Reply-To: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
References: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
Message-ID: <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>

Yes, people are probably still using it. Last time I tried to use V2 it
didn't work because the clients were broken, and then it went back on the
bottom of my to do list. Is this mess fixed?

http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html

On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <e0ne at e0ne.info> wrote:

> Hi all,
>
> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API was
> introduced in Grizzly and v1 API is deprecated since Juno.
>
> After [1] is merged, Cinder API v1 is disabled in gates by default. We've
> got a filed bug [2] to remove Cinder v1 API at all.
>
>
> According to Deprecation Policy [3] looks like we are OK to remote it. But
> I would like to ask Cinder API users if any still use API v1.
> Should we remove it at all Mitaka release or just disable by default in
> the cinder.conf?
>
> AFAIR, only Rally doesn't support API v2 now and I'm going to implement it
> asap.
>
> [1] https://review.openstack.org/194726
> [2] https://bugs.launchpad.net/cinder/+bug/1467589
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
>
> Regards,
> Ivan Kolodyazhny
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/53759de8/attachment.html>

From sorrison at gmail.com  Mon Sep 28 23:17:51 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Tue, 29 Sep 2015 09:17:51 +1000
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The future
	of Cinder API v1
In-Reply-To: <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>
References: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
 <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>
Message-ID: <CEC673AD-DE02-4B70-8691-68A57A037CCE@gmail.com>

Yeah we?re still using v1 as the clients that are packaged with most distros don?t support v2 easily.

Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our ?volume? endpoint to point to v2 (we have a volumev2 endpoint too) and the client breaks.

$ cinder list
ERROR: OpenStack Block Storage API version is set to 1 but you are accessing a 2 endpoint. Change its value through --os-volume-api-version or env[OS_VOLUME_API_VERSION].

Sam


> On 29 Sep 2015, at 8:34 am, Matt Fischer <matt at mattfischer.com> wrote:
> 
> Yes, people are probably still using it. Last time I tried to use V2 it didn't work because the clients were broken, and then it went back on the bottom of my to do list. Is this mess fixed?
> 
> http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html <http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html>
> 
> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <e0ne at e0ne.info <mailto:e0ne at e0ne.info>> wrote:
> Hi all,
> 
> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API was introduced in Grizzly and v1 API is deprecated since Juno.
> 
> After [1] is merged, Cinder API v1 is disabled in gates by default. We've got a filed bug [2] to remove Cinder v1 API at all.
> 
> 
> According to Deprecation Policy [3] looks like we are OK to remote it. But I would like to ask Cinder API users if any still use API v1.
> Should we remove it at all Mitaka release or just disable by default in the cinder.conf?
> 
> AFAIR, only Rally doesn't support API v2 now and I'm going to implement it asap.
> 
> [1] https://review.openstack.org/194726 <https://review.openstack.org/194726> 
> [2] https://bugs.launchpad.net/cinder/+bug/1467589 <https://bugs.launchpad.net/cinder/+bug/1467589>
> [3] http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html <http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html>
> Regards,
> Ivan Kolodyazhny
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/dbb6897c/attachment.html>

From harlowja at outlook.com  Mon Sep 28 23:37:22 2015
From: harlowja at outlook.com (Joshua Harlow)
Date: Mon, 28 Sep 2015 16:37:22 -0700
Subject: [Openstack-operators] Live snapshots on the raw disks never ends
In-Reply-To: <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>
References: <5603F462.6050905@gmail.com>
 <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>
Message-ID: <BLU436-SMTP243B19B34096F64A047C97FD84F0@phx.gbl>

Ours was local-disk,

I believe https://review.openstack.org/#/c/208078/ (and/or its followup 
bug/fix) will hopefully help address this. It might not be the same 
issue though (but maybe it is).

-Josh

Kris G. Lindgren wrote:
> I believe I was talking to Josh Harlow (he's harlowja in #openstack-operators on freenode) from Yahoo, about something like this the other day.  He was saying that recently on a few hypervisors they would randomly run into HV disks that were completely full due to snapshots.  I have not personally ran into this, so I can't be of more help.
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
>
>
>
>
> On 9/24/15, 7:02 AM, "George Shuklin"<george.shuklin at gmail.com>  wrote:
>
>> Hello everyone.
>>
>> Is someone ever saw 'endless snapshot' problem? Some instances (with raw
>> disks and live snapshoting enabled) are stuck at image_uploading forever.
>>
>> It looks like this:
>>
>> +--------------------------------------+----------------------------------------------------------+
>> | Property                             | Value                                                    |
>> +--------------------------------------+----------------------------------------------------------+
>> | status                               | ACTIVE                                                   |
>> | updated                              | 2015-07-16T08:07:00Z                                     |
>> | OS-EXT-STS:task_state                | image_uploading                                          |
>> | OS-EXT-SRV-ATTR:host                 | compute                                                  |
>> | key_name                             | ses                                                      |
>> | image                                | Ubuntu 14.04 (3736af94-b25e-4b8d-96fd-fd5949bbd81e)      |
>> | OS-EXT-STS:vm_state                  | active                                                   |
>> | OS-EXT-SRV-ATTR:instance_name        | instance-0000000d                                        |
>> | OS-SRV-USG:launched_at               | 2015-05-09T17:28:09.000000                               |
>> | OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.lab.internal                                     |
>> | flavor                               | flavor2 (2)                                              |
>> | id                                   | f2365fe4-9b30-4c24-b7b9-f7fcb4165160                     |
>> | security_groups                      | [{u'name': u'default'}]                                  |
>> | OS-SRV-USG:terminated_at             | None                                                     |
>> | user_id                              | 61096c639d674e4cb8bf487cec01432a                         |
>> | name                                 | non-test                                                 |
>> | created                              | 2015-05-09T17:27:48Z                                     |
>> ...etc
>>
>> Any ideas why this happens? All logs are clear, no errors or anything.
>> And it happens at random so no 'debug' log available...
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


From mvoelker at vmware.com  Tue Sep 29 00:19:46 2015
From: mvoelker at vmware.com (Mark Voelker)
Date: Tue, 29 Sep 2015 00:19:46 +0000
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The
	future	of Cinder API v1
In-Reply-To: <CEC673AD-DE02-4B70-8691-68A57A037CCE@gmail.com>
References: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
 <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>
 <CEC673AD-DE02-4B70-8691-68A57A037CCE@gmail.com>
Message-ID: <DA353AC8-CAE0-448D-9072-63C1246542D5@vmware.com>

FWIW, the most popular client libraries in the last user survey[1] other than OpenStack?s own clients were: libcloud (48 respondents), jClouds (36 respondents), Fog (34 respondents), php-opencloud (21 respondents), DeltaCloud (which has been retired by Apache and hasn?t seen a commit in two years, but 17 respondents are still using it), pkgcloud (15 respondents), and OpenStack.NET (14 respondents).  Of those:

* libcloud appears to support the nova-volume API but not the cinder API: https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251

* jClouds appears to support only the v1 API: https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds

* Fog also appears to only support the v1 API: https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99

* php-opencloud appears to only support the v1 API: https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html

* DeltaCloud I honestly haven?t looked at since it?s thoroughly dead, but I can?t imagine it supports v2.

* pkgcloud has beta-level support for Cinder but I think it?s v1 (may be mistaken): https://github.com/pkgcloud/pkgcloud/#block-storage----beta and https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage

* OpenStack.NET does appear to support v2: http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm

Now, it?s anyone?s guess as to whether or not users of those client libraries actually try to use them for volume operations or not (anecdotally I know a few clouds I help support are using client libraries that only support v1), and some users might well be using more than one library or mixing in code they wrote themselves.  But most of the above that support cinder do seem to rely on v1.  Some management tools also appear to still rely on the v1 API (such as RightScale: http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html ).  From that perspective it might be useful to keep it around a while longer and disable it by default.  Personally I?d probably lean that way, especially given that folks here on the ops list are still reporting problems too.

That said, v1 has been deprecated since Juno, and the Juno release notes said it was going to be removed [2], so there?s a case to be made that there?s been plenty of fair warning too I suppose.

[1] http://superuser.openstack.org/articles/openstack-application-developers-share-insights
[2] https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7

At Your Service,

Mark T. Voelker



> On Sep 28, 2015, at 7:17 PM, Sam Morrison <sorrison at gmail.com> wrote:
> 
> Yeah we?re still using v1 as the clients that are packaged with most distros don?t support v2 easily.
> 
> Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our ?volume? endpoint to point to v2 (we have a volumev2 endpoint too) and the client breaks.
> 
> $ cinder list
> ERROR: OpenStack Block Storage API version is set to 1 but you are accessing a 2 endpoint. Change its value through --os-volume-api-version or env[OS_VOLUME_API_VERSION].
> 
> Sam
> 
> 
>> On 29 Sep 2015, at 8:34 am, Matt Fischer <matt at mattfischer.com> wrote:
>> 
>> Yes, people are probably still using it. Last time I tried to use V2 it didn't work because the clients were broken, and then it went back on the bottom of my to do list. Is this mess fixed?
>> 
>> http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html
>> 
>> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <e0ne at e0ne.info> wrote:
>> Hi all,
>> 
>> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API was introduced in Grizzly and v1 API is deprecated since Juno.
>> 
>> After [1] is merged, Cinder API v1 is disabled in gates by default. We've got a filed bug [2] to remove Cinder v1 API at all.
>> 
>> 
>> According to Deprecation Policy [3] looks like we are OK to remote it. But I would like to ask Cinder API users if any still use API v1.
>> Should we remove it at all Mitaka release or just disable by default in the cinder.conf?
>> 
>> AFAIR, only Rally doesn't support API v2 now and I'm going to implement it asap.
>> 
>> [1] https://review.openstack.org/194726 
>> [2] https://bugs.launchpad.net/cinder/+bug/1467589
>> [3] http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
>> 
>> Regards,
>> Ivan Kolodyazhny
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


From pieter.c.kruithof-jr at hpe.com  Tue Sep 29 01:01:13 2015
From: pieter.c.kruithof-jr at hpe.com (Kruithof, Piet)
Date: Tue, 29 Sep 2015 01:01:13 +0000
Subject: [Openstack-operators] [neutron] [nova] Nova Network/Neutron
 Migration Survey - need response from folks currently using Nova Networks
 in their deployments
Message-ID: <D22F3EF2.18564%pieter.c.kruithof-jr@hp.com>

There has been a significant response to the Nova Network/Neutron migration survey.  However, the responses are leaning heavily on the side of deployments currently using Neutron.  As a result, we would like to have more representation from folks currently using Nova Networks.

If you are currently using Nova Networks, please respond to the survey!

You will also be entered in a raffle for one of two $100 US Amazon gift cards at the end of the survey.   As always, the results from the survey will be shared with the OpenStack community.

Please click on the following link to begin the survey.

https://www.surveymonkey.com/r/osnetworking


Piet Kruithof
PTL, OpenStack UX project

"For every complex problem, there is a solution that is simple, neat and wrong.?

H L Menken



From runner_cheng at hotmail.com  Tue Sep 29 03:25:23 2015
From: runner_cheng at hotmail.com (RunnerCheng)
Date: Tue, 29 Sep 2015 11:25:23 +0800
Subject: [Openstack-operators] "Master" keystone and "sub"
Message-ID: <BLU173-W4698CB113097536E9C9E99E74E0@phx.gbl>

Hi All,
 
Really thanks all of you disscussing this topic, I believe I got several important clues from your disscussion.
------------------------------

Message: 11
Date: Mon, 28 Sep 2015 15:31:54 -0400
From: Adam Young <ayoung at redhat.com>
To: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] "Master" keystone and "sub"
	keystone
Message-ID: <560995AA.5040808 at redhat.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 09/26/2015 11:19 PM, RunnerCheng wrote:
> Hi All,
> I'm a newbie of keystone, and I'm doing some research about it 
> recently. I have a question about how to deploy it. The scenario is on 
> below:
>
> One comany has one headquarter dc and 5 sub dc locate in different 
> cities. We want to deploy separate OpenStack with "sub" keystone at 
> the sub dc, and want to deploy one "master" keystone at headquarter 
> dc. We want to manage all users, roles and tenants etc on the "master" 
> keystone, however we want the end-user can authenticate with the "sub" 
> keystone where he or she is locate.


Use LDAP for the users, don't keep them in Keystone.

Replicate roles, projects etc from master to sub.

Use Fernet tokens.  Replicate revocation events both ways.


>
> Is anyone understant this scenario? How to realize it without 
> additionaly development?
>
> Thanks in advance!
>
> Sam Cheng
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/7a0c57c4/attachment-0001.html>

------------------------------

Message: 12
Date: Mon, 28 Sep 2015 15:46:50 -0400
From: Jonathan Proulx <jon at csail.mit.edu>
To: Adam Young <ayoung at redhat.com>
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] "Master" keystone and "sub"
	keystone
Message-ID: <20150928194650.GO24467 at csail.mit.edu>
Content-Type: text/plain; charset=us-ascii

On Mon, Sep 28, 2015 at 03:31:54PM -0400, Adam Young wrote:
:On 09/26/2015 11:19 PM, RunnerCheng wrote:
:>Hi All,
:>I'm a newbie of keystone, and I'm doing some research about it
:>recently. I have a question about how to deploy it. The scenario is
:>on below:
:>
:>One comany has one headquarter dc and 5 sub dc locate in different
:>cities. We want to deploy separate OpenStack with "sub" keystone at
:>the sub dc, and want to deploy one "master" keystone at headquarter
:>dc. We want to manage all users, roles and tenants etc on the
:>"master" keystone, however we want the end-user can authenticate
:>with the "sub" keystone where he or she is locate.
:
:
:Use LDAP for the users, don't keep them in Keystone.
:
:Replicate roles, projects etc from master to sub.
:
:Use Fernet tokens.  Replicate revocation events both ways.

I'm hearing conflicting advice about the suitibility of Fernet tokens
for production use.

I like the idea. I did get them to work in kilo trivially for CLI, but
Horizon was unhappy for reasons I didn't fully investigate as I heard
they 'weren't quite ready in kilo' so I defered further investigation
to next cycle.

Though honestly if you're building somthing new right now starting
with Liberty is probably the right thing anyway by the time you're
done PoC it will be released.

-Jon



------------------------------

Message: 13
Date: Mon, 28 Sep 2015 14:06:00 -0600
From: Matt Fischer <matt at mattfischer.com>
To: Jonathan Proulx <jon at csail.mit.edu>
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] "Master" keystone and "sub"
	keystone
Message-ID:
	<CAHr1CO9sSjwb6ug-9D9K2Zt8Y6WWxQON1ZPecWojqZkMstPV+A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, Sep 28, 2015 at 1:46 PM, Jonathan Proulx <jon at csail.mit.edu> wrote:

> On Mon, Sep 28, 2015 at 03:31:54PM -0400, Adam Young wrote:
> :On 09/26/2015 11:19 PM, RunnerCheng wrote:
> :>Hi All,
> :>I'm a newbie of keystone, and I'm doing some research about it
> :>recently. I have a question about how to deploy it. The scenario is
> :>on below:
> :>
> :>One comany has one headquarter dc and 5 sub dc locate in different
> :>cities. We want to deploy separate OpenStack with "sub" keystone at
> :>the sub dc, and want to deploy one "master" keystone at headquarter
> :>dc. We want to manage all users, roles and tenants etc on the
> :>"master" keystone, however we want the end-user can authenticate
> :>with the "sub" keystone where he or she is locate.
> :
> :
> :Use LDAP for the users, don't keep them in Keystone.
> :
> :Replicate roles, projects etc from master to sub.
> :
> :Use Fernet tokens.  Replicate revocation events both ways.
>
> I'm hearing conflicting advice about the suitibility of Fernet tokens
> for production use.
>
> I like the idea. I did get them to work in kilo trivially for CLI, but
> Horizon was unhappy for reasons I didn't fully investigate as I heard
> they 'weren't quite ready in kilo' so I defered further investigation
> to next cycle.
>
> Though honestly if you're building somthing new right now starting
> with Liberty is probably the right thing anyway by the time you're
> done PoC it will be released.
>
> -Jon


We're using them in prod, generally happy except with Validation
performance. For Horizon we run off of master anyway but you have to pull
in some code from Liberty or it won't work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150928/e3e01f80/attachment-0001.html>

------------------------------

Message: 14
Date: Mon, 28 Sep 2015 16:20:56 -0400
From: Jonathan Proulx <jon at csail.mit.edu>
To: Matt Fischer <matt at mattfischer.com>
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] "Master" keystone and "sub"
	keystone
Message-ID: <20150928202056.GP24467 at csail.mit.edu>
Content-Type: text/plain; charset=us-ascii

On Mon, Sep 28, 2015 at 02:06:00PM -0600, Matt Fischer wrote:
:On Mon, Sep 28, 2015 at 1:46 PM, Jonathan Proulx <jon at csail.mit.edu> wrote:

:> I'm hearing conflicting advice about the suitibility of Fernet tokens
:> for production use.
:>
:> I like the idea. I did get them to work in kilo trivially for CLI, but
:> Horizon was unhappy for reasons I didn't fully investigate as I heard
:> they 'weren't quite ready in kilo' so I defered further investigation
:> to next cycle.
:>
:> Though honestly if you're building somthing new right now starting
:> with Liberty is probably the right thing anyway by the time you're
:> done PoC it will be released.
:>
:> -Jon
:
:
:We're using them in prod, generally happy except with Validation
:performance. For Horizon we run off of master anyway but you have to pull
:in some code from Liberty or it won't work.

Thanks that's actually very good to know.  I have a recent master
version of Horizon that I hope to move to production soon, so if it's
all Horizon issues I may make the move to Fernet in production sooner
rather than later.

-Jon



------------------------------

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/35fd7a08/attachment.html>

From itzshamail at gmail.com  Tue Sep 29 05:15:26 2015
From: itzshamail at gmail.com (Shamail Tahir)
Date: Tue, 29 Sep 2015 01:15:26 -0400
Subject: [Openstack-operators] [Large Deployments Team][Tags] Ops Tag
	for "Scale"
In-Reply-To: <20150928140354.GB24467@csail.mit.edu>
References: <3BD405F9-839F-4AAD-AA0F-04E573B14FAE@gmail.com>
 <1443312603-sup-6878@fewbar.com>
 <CALrdpTXaGohT4pW5fi6dKyy5Zhyv3GgjTfhSD0jtE9KHwjBfWA@mail.gmail.com>
 <C02C2797-18C4-42E8-9CA6-01578C6ADD1C@godaddy.com>
 <20150928140354.GB24467@csail.mit.edu>
Message-ID: <CALrdpTVGgsqd7dC_UOJM1caDapYzO-r8P0xc9g9d0bgKoBkgbg@mail.gmail.com>

Thanks for the additional data-points on the granularity that we might need
to address scale (component rather than project level) along with
additional clarification on drivers (scale equivalent to resource being
available versus needing additional resources).  As mentioned earlier,
deployment options (types of infrastructure, services, and their
configuration) also play a vital part in the 'scale' of a service.  This is
a great starting point to the conversation.

On Mon, Sep 28, 2015 at 10:03 AM, Jonathan D. Proulx <jon at csail.mit.edu>
wrote:

> On Sun, Sep 27, 2015 at 06:15:58PM +0000, Kris G. Lindgren wrote:
>
> >For Example, we (Godaddy) use neutron for networking, however
> >we do not use tunneling of any type and we do not create virtual
> >routers or private networks and we do not rely on dhcp (we use
> >config-drive to set instance ip configuration).
>
> This is an important thing to consider.  Even at my <100 node scale I
> don't use neutron L3 so even if a site reports using a project it's
> hard to say what parts tehy are using or how they modefied it to mak
> eit 'scale' as this could include leaving large pieces that don't
> scale on the floor...
>
> -Jon
>
>
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/3150b858/attachment.html>

From pandey.preeti1 at tcs.com  Tue Sep 29 12:07:23 2015
From: pandey.preeti1 at tcs.com (Pandey Preeti1/KOL/TCS)
Date: Tue, 29 Sep 2015 17:37:23 +0530 (IST)
Subject: [Openstack-operators] Openstack-AngularJS related queries
Message-ID: <53e822e1-be0f-4e61-9a63-59a10ce3ba9b@inmumzm03.tcsin.com>

Hi ,
     I want to know what is the use of creating manifest.json file in openstack?
How the data is fetched from all the files and passed to the dynamically created .js file in /static/dashboard/js directory. If I make any changes in the dynamically created .js files instead of actual files why are the changes getting reflected in the dashboard? Any changes made in the actual files are not getting reflected.
[Note: All the changes are made in the launch instance tab (angularJS) ]

With Regards,
Preeti Pandey
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/947acf19/attachment.html>

From sgordon at redhat.com  Tue Sep 29 12:47:19 2015
From: sgordon at redhat.com (Steve Gordon)
Date: Tue, 29 Sep 2015 08:47:19 -0400 (EDT)
Subject: [Openstack-operators] [nfv][telcowg] Telco Working Group meeting
	schedule
In-Reply-To: <816915853.59493929.1443530498525.JavaMail.zimbra@redhat.com>
Message-ID: <142156967.59496233.1443530839928.JavaMail.zimbra@redhat.com>

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


From mgagne at internap.com  Tue Sep 29 16:31:42 2015
From: mgagne at internap.com (=?UTF-8?Q?Mathieu_Gagn=c3=a9?=)
Date: Tue, 29 Sep 2015 12:31:42 -0400
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The future
 of Cinder API v1
In-Reply-To: <CAPWkaSUZBAjzk_0je2KEM4DFjyvxRYAaTGvfwbkAKosOKGLUnA@mail.gmail.com>
References: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
 <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>
 <CEC673AD-DE02-4B70-8691-68A57A037CCE@gmail.com>
 <DA353AC8-CAE0-448D-9072-63C1246542D5@vmware.com>
 <CAPWkaSUZBAjzk_0je2KEM4DFjyvxRYAaTGvfwbkAKosOKGLUnA@mail.gmail.com>
Message-ID: <560ABCEE.7010408@internap.com>

On 2015-09-28 11:43 PM, John Griffith wrote:
> 
> 
> On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker <mvoelker at vmware.com
> <mailto:mvoelker at vmware.com>> wrote:
> 
>     FWIW, the most popular client libraries in the last user survey[1]
>     other than OpenStack?s own clients were: libcloud (48 respondents),
>     jClouds (36 respondents), Fog (34 respondents), php-opencloud (21
>     respondents), DeltaCloud (which has been retired by Apache and
>     hasn?t seen a commit in two years, but 17 respondents are still
>     using it), pkgcloud (15 respondents), and OpenStack.NET (14
>     respondents).  Of those:
> 
>     * libcloud appears to support the nova-volume API but not the cinder
>     API:
>     https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251
> 
>     * jClouds appears to support only the v1 API:
>     https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds
> 
>     * Fog also appears to only support the v1 API:
>     https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99
> 
>     * php-opencloud appears to only support the v1 API:
>     https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html
> 
>     * DeltaCloud I honestly haven?t looked at since it?s thoroughly
>     dead, but I can?t imagine it supports v2.
> 
>     * pkgcloud has beta-level support for Cinder but I think it?s v1
>     (may be mistaken):
>     https://github.com/pkgcloud/pkgcloud/#block-storage----beta and
>     https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage
> 
>     * OpenStack.NET does appear to support v2:
>     http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm
> 
>     Now, it?s anyone?s guess as to whether or not users of those client
>     libraries actually try to use them for volume operations or not
>     (anecdotally I know a few clouds I help support are using client
>     libraries that only support v1), and some users might well be using
>     more than one library or mixing in code they wrote themselves.  But
>     most of the above that support cinder do seem to rely on v1.  Some
>     management tools also appear to still rely on the v1 API (such as
>     RightScale:
>     http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html
>     ).  From that perspective it might be useful to keep it around a
>     while longer and disable it by default.  Personally I?d probably
>     lean that way, especially given that folks here on the ops list are
>     still reporting problems too.
> 
>     That said, v1 has been deprecated since Juno, and the Juno release
>     notes said it was going to be removed [2], so there?s a case to be
>     made that there?s been plenty of fair warning too I suppose.
> 
>     [1]
>     http://superuser.openstack.org/articles/openstack-application-developers-share-insights
>     [2] https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7
> 
>     At Your Service,
> 
>     Mark T. Voelker
> 
> 
> 
>     > On Sep 28, 2015, at 7:17 PM, Sam Morrison <sorrison at gmail.com
>     <mailto:sorrison at gmail.com>> wrote:
>     >
>     > Yeah we?re still using v1 as the clients that are packaged with
>     most distros don?t support v2 easily.
>     >
>     > Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our
>     ?volume? endpoint to point to v2 (we have a volumev2 endpoint too)
>     and the client breaks.
>     >
>     > $ cinder list
>     > ERROR: OpenStack Block Storage API version is set to 1 but you are
>     accessing a 2 endpoint. Change its value through
>     --os-volume-api-version or env[OS_VOLUME_API_VERSION].
>     >
>     > Sam
>     >
>     >
>     >> On 29 Sep 2015, at 8:34 am, Matt Fischer <matt at mattfischer.com
>     <mailto:matt at mattfischer.com>> wrote:
>     >>
>     >> Yes, people are probably still using it. Last time I tried to use
>     V2 it didn't work because the clients were broken, and then it went
>     back on the bottom of my to do list. Is this mess fixed?
>     >>
>     >>
>     http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html
>     >>
>     >> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny <e0ne at e0ne.info
>     <mailto:e0ne at e0ne.info>> wrote:
>     >> Hi all,
>     >>
>     >> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2
>     API was introduced in Grizzly and v1 API is deprecated since Juno.
>     >>
>     >> After [1] is merged, Cinder API v1 is disabled in gates by
>     default. We've got a filed bug [2] to remove Cinder v1 API at all.
>     >>
>     >>
>     >> According to Deprecation Policy [3] looks like we are OK to
>     remote it. But I would like to ask Cinder API users if any still use
>     API v1.
>     >> Should we remove it at all Mitaka release or just disable by
>     default in the cinder.conf?
>     >>
>     >> AFAIR, only Rally doesn't support API v2 now and I'm going to
>     implement it asap.
>     >>
>     >> [1] https://review.openstack.org/194726
>     >> [2] https://bugs.launchpad.net/cinder/+bug/1467589
>     >> [3]
>     http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
>     >>
>     >> Regards,
>     >> Ivan Kolodyazhny
>     >>
> 
> 
> ?My opinion is that even though V1 has technically been deprecated for
> multiple cycles, V2 was never really viable until the Liberty release. 
> Between issues with V2 and other components, and then the version
> discovery issues that broke some things; I think we should reset the
> deprecation clock so to speak.
> 
> It was only in the last milestone of Liberty that folks finally got
> everything updated and talking V2.  Not to mention the patch to switch
> the default in devstack just landed (where everything uses it including
> Nova).
> 
> To summarize, absolutely NO to removing V1 in Mitaka, and I think
> resetting the deprecation clock is the most reasonable course of action
> here.
> 

I agree with John Griffith. I don't have any empirical evidences to back
my "feelings" on that one but it's true that we weren't enable to enable
Cinder v2 until now.

Which makes me wonder: When can we actually deprecate an API version? I
*feel* we are fast to jump on the deprecation when the replacement isn't
100% ready yet for several versions.

-- 
Mathieu


From matt at mattfischer.com  Tue Sep 29 16:36:52 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Tue, 29 Sep 2015 10:36:52 -0600
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The future
 of Cinder API v1
In-Reply-To: <560ABCEE.7010408@internap.com>
References: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
 <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>
 <CEC673AD-DE02-4B70-8691-68A57A037CCE@gmail.com>
 <DA353AC8-CAE0-448D-9072-63C1246542D5@vmware.com>
 <CAPWkaSUZBAjzk_0je2KEM4DFjyvxRYAaTGvfwbkAKosOKGLUnA@mail.gmail.com>
 <560ABCEE.7010408@internap.com>
Message-ID: <CAHr1CO-HoRr+zoccf1YvQ5EnAtO_CPfNwWAoe0akynj2Ra7xxA@mail.gmail.com>

>
>
>
> I agree with John Griffith. I don't have any empirical evidences to back
> my "feelings" on that one but it's true that we weren't enable to enable
> Cinder v2 until now.
>
> Which makes me wonder: When can we actually deprecate an API version? I
> *feel* we are fast to jump on the deprecation when the replacement isn't
> 100% ready yet for several versions.
>
> --
> Mathieu
>


I don't think it's too much to ask that versions can't be deprecated until
the new version is 100% working, passing all tests, and the clients (at
least python-xxxclients) can handle it without issues. Ideally I'd like to
also throw in the criteria that devstack, rally, tempest, and other
services are all using and exercising the new API.

I agree that things feel rushed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/f3065a99/attachment.html>

From mvoelker at vmware.com  Tue Sep 29 17:32:45 2015
From: mvoelker at vmware.com (Mark Voelker)
Date: Tue, 29 Sep 2015 17:32:45 +0000
Subject: [Openstack-operators] [openstack-dev] [cinder] [all] The future
 of Cinder API v1
In-Reply-To: <CAHr1CO-HoRr+zoccf1YvQ5EnAtO_CPfNwWAoe0akynj2Ra7xxA@mail.gmail.com>
References: <CAGocpaHXaAP9XkvpWy1RAwWt_v+H-x8xyY6EJh1Q+xG31GbJjw@mail.gmail.com>
 <CAHr1CO9dhtr+7dNzV9S9Z7sKpXK_k4c4pZtQUd6jnGMX4t3JYA@mail.gmail.com>
 <CEC673AD-DE02-4B70-8691-68A57A037CCE@gmail.com>
 <DA353AC8-CAE0-448D-9072-63C1246542D5@vmware.com>
 <CAPWkaSUZBAjzk_0je2KEM4DFjyvxRYAaTGvfwbkAKosOKGLUnA@mail.gmail.com>
 <560ABCEE.7010408@internap.com>
 <CAHr1CO-HoRr+zoccf1YvQ5EnAtO_CPfNwWAoe0akynj2Ra7xxA@mail.gmail.com>
Message-ID: <491F2677-6DFD-4FF8-BCA9-1169FF1841B2@vmware.com>


Mark T. Voelker



> On Sep 29, 2015, at 12:36 PM, Matt Fischer <matt at mattfischer.com> wrote:
> 
> 
> 
> I agree with John Griffith. I don't have any empirical evidences to back
> my "feelings" on that one but it's true that we weren't enable to enable
> Cinder v2 until now.
> 
> Which makes me wonder: When can we actually deprecate an API version? I
> *feel* we are fast to jump on the deprecation when the replacement isn't
> 100% ready yet for several versions.
> 
> --
> Mathieu
> 
> 
> I don't think it's too much to ask that versions can't be deprecated until the new version is 100% working, passing all tests, and the clients (at least python-xxxclients) can handle it without issues. Ideally I'd like to also throw in the criteria that devstack, rally, tempest, and other services are all using and exercising the new API.
> 
> I agree that things feel rushed.


FWIW, the TC recently created an assert:follows-standard-deprecation tag.  Ivan linked to a thread in which Thierry asked for input on it, but FYI the final language as it was approved last week [1] is a bit different than originally proposed.  It now requires one release plus 3 linear months of deprecated-but-still-present-in-the-tree as a minimum, and recommends at least two full stable releases for significant features (an entire API version would undoubtedly fall into that bucket).  It also requires that a migration path will be documented.  However to Matt?s point, it doesn?t contain any language that says specific things like:

In the case of major API version deprecation:
* $oldversion and $newversion must both work with [cinder|nova|whatever]client and openstackclient during the deprecation period.
* It must be possible to run $oldversion and $newversion concurrently on the servers to ensure end users don?t have to switch overnight. 
* Devstack uses $newversion by default.
* $newversion works in Tempest/Rally/whatever else.

What it *does* do is require that a thread be started here on openstack-operators [2] so that operators can provide feedback.  I would hope that feedback like ?I can?t get clients to use it so please don?t remove it yet? would be taken into account by projects, which seems to be exactly what?s happening in this case with Cinder v1.  =)

I?d hazard a guess that the TC would be interested in hearing about whether you think that plan is a reasonable one (and given that TC election season is upon us, candidates for the TC probably would too).

[1] https://review.openstack.org/#/c/207467/
[2] http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59

At Your Service,

Mark T. Voelker


>  
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


From jj at chef.io  Tue Sep 29 17:45:16 2015
From: jj at chef.io (JJ Asghar)
Date: Tue, 29 Sep 2015 12:45:16 -0500
Subject: [Openstack-operators] [openstack-operators][osops] Something other
 than NOOP in our jenkins tests
Message-ID: <560ACE2C.7090503@chef.io>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey All!

So this popped up today[1]. This seems like something that should be
leveraged in our gates/validations?

Any thoughts?


[1]: https://review.openstack.org/#/c/229046

- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCs4sAAoJEDZbxzMH0+jTadMP/As3hlY8C8WkyUh8o4G3ZVoQ
6aMHRv0Z47VzWESNkxYP1BPmcgnCa0X0XbEavYV2F1DRiZVFUsZYj5Qp2e/UDQOm
z2DjcemMRtYiMiTlVQC9T+VvuVhklmT1f7Vqmgod+P542aRd060zyhCToeup21zE
J3ZTP6m/OFtObrWi+MWq5VE1PlyRPpf9eJuM1IdLXqzcW//ER10KEjtY5QnAs+r2
/3tj60/wdgjrNxKqbwh+Wv9e0RAaI+5X1Ne74SZrYrR+RvrITMUHTngIYy6/eb2D
4XIH2JecFmrP/1hZyF9Q1gK1ZwYxLjiazDa9XDHjjNXt2r1rtdt45NRu7ZnxvJOa
LCAhzmMmik3dYYyuHUrhlRVbxq3bCiPBZJ9xRlxGJXGpT45We06pgqYDmQ1pHsns
trKVd+Brk0BrJCJPhOdJPhU2WKkthH6UGbXkLDsvMLTUBdr1g//uf6rIycd7/I2F
Z1a3naifa1i5NYZX+2qN8k660v3znNbCobCuwKiT7e2k+Ur4SjkXlNJZaGNq3kwV
8vNr/+0st5+IBQRAQWTlbSmuU7fjjEUGYvz+eoSGUnWpiqnKI0MzzSOcoeVJxggp
4/qgvxatdLgD7j4h/6+ysi4n2cZzEM/Jvnf/mu2tGyQcm+pp3DQvhVaVpO6FCawk
KrDEUrvLbwHS1dTcmhWV
=VrXg
-----END PGP SIGNATURE-----



From christian at berendt.io  Tue Sep 29 18:27:38 2015
From: christian at berendt.io (Christian Berendt)
Date: Tue, 29 Sep 2015 20:27:38 +0200
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <560ACE2C.7090503@chef.io>
References: <560ACE2C.7090503@chef.io>
Message-ID: <560AD81A.9030607@berendt.io>

On 09/29/2015 07:45 PM, JJ Asghar wrote:
> So this popped up today[1]. This seems like something that should be
> leveraged in our gates/validations?

I prepared review requests to enable checks on the gates for

* osops-tools-monitoring: https://review.openstack.org/#/c/229094/
* osops-tools-generic: https://review.openstack.org/#/c/229043/

Christian.

-- 
Christian Berendt
Cloud Solution Architect
Mail: berendt at b1-systems.de

B1 Systems GmbH
Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


From jj at chef.io  Tue Sep 29 18:52:52 2015
From: jj at chef.io (JJ Asghar)
Date: Tue, 29 Sep 2015 13:52:52 -0500
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <560AD81A.9030607@berendt.io>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
Message-ID: <560ADE04.9090902@chef.io>

Awesome! That works!

Best Regards, 
JJ Asghar 
c: 512.619.0722 t: @jjasghar irc: j^2 

On 9/29/15 1:27 PM, Christian Berendt wrote:
> On 09/29/2015 07:45 PM, JJ Asghar wrote:
>> So this popped up today[1]. This seems like something that should be
>> leveraged in our gates/validations?
>
> I prepared review requests to enable checks on the gates for
>
> * osops-tools-monitoring: https://review.openstack.org/#/c/229094/
> * osops-tools-generic: https://review.openstack.org/#/c/229043/
>
> Christian.
>



From maishsk at maishsk.com  Tue Sep 29 19:09:38 2015
From: maishsk at maishsk.com (Maish Saidel-Keesing)
Date: Tue, 29 Sep 2015 22:09:38 +0300
Subject: [Openstack-operators] [Election] [TC] TC Candidacy
Message-ID: <560AE1F2.2040300@maishsk.com>

Hello to you all.

I would like to propose myself as a candidate for the Technical 
Committee for
the upcoming term. The reasons for running in the last election [1]
are still relevant for this election of the TC.

Since the last election my involvement in OpenStack has increased with a
spotlight on the Operators aspect of the community:

     - Focusing on the ops-tags-team[2] helping to create tags with the 
intent of
        creating information relevant to Operators.
     - Helping to vet and review submissions to the OpenStack Planet[3] and
        contributing as a core in openstack-planet-core.
     - Participating in the Item Writing Committee of the first Foundation
        initiative for the inaugural OpenStack Certification Exam Program.

As an OpenStack community we have made some huge steps in the right 
direction,
and are bringing more and more of the Operator and User community into our
midst. Operators and Users should also be represented in the
Technical Committee.

It is my hope that the electorate accept that there is a huge benefit,
and also a clear need, to have representation from all aspects of 
OpenStack, not
only from the developer community. When this happens - the disconnect (and
sometimes tension) that we have between these different parts will cease 
to be
an issue and we as a community will continue to thrive and grow.
In order to finally bridge this gap, it is time to open the ranks, bring an
Operator into the TC and to become truly inclusive.

I humbly ask for your selection so that I may represent Operators in the
Technical Committee for the next term.

Thank you for your consideration.

Some more information about me:
OpenStack profile: https://www.openstack.org/community/members/profile/15265
Reviews: 
https://review.openstack.org/#/q/reviewer:%22Maish+Saidel-Keesing%22,n,z
IRC: maishsk
Blog: http://technodrone.blogspot.com

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-April/062372.html
[2] 
https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z
[3] https://wiki.openstack.org/wiki/AddingYourBlog

-- 
Best Regards,
Maish Saidel-Keesing


From joe at topjian.net  Tue Sep 29 19:43:56 2015
From: joe at topjian.net (Joe Topjian)
Date: Tue, 29 Sep 2015 13:43:56 -0600
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <560ADE04.9090902@chef.io>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
Message-ID: <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>

So this will require bash scripts to adhere to bashate before being
accepted? Is it possible to have the check as non-voting? Does this open
the door to having other file types be checked?

IMHO, it's more important for the OSOps project to foster collaboration and
contributions rather than worry about an accepted style.

As an example, yesterday's commits used hard-tabs:

https://review.openstack.org/#/c/228545/
https://review.openstack.org/#/c/228534/

I think we're going to see a lot of variation of styles coming in.

I don't want to come off as sounding ignorant or disrespectful to other
projects that have guidelines in place -- I fully understand and respect
those decisions.

Joe

On Tue, Sep 29, 2015 at 12:52 PM, JJ Asghar <jj at chef.io> wrote:

> Awesome! That works!
>
> Best Regards,
> JJ Asghar
> c: 512.619.0722 t: @jjasghar irc: j^2
>
> On 9/29/15 1:27 PM, Christian Berendt wrote:
> > On 09/29/2015 07:45 PM, JJ Asghar wrote:
> >> So this popped up today[1]. This seems like something that should be
> >> leveraged in our gates/validations?
> >
> > I prepared review requests to enable checks on the gates for
> >
> > * osops-tools-monitoring: https://review.openstack.org/#/c/229094/
> > * osops-tools-generic: https://review.openstack.org/#/c/229043/
> >
> > Christian.
> >
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/abfcd264/attachment.html>

From david.wahlstrom at gmail.com  Tue Sep 29 19:57:22 2015
From: david.wahlstrom at gmail.com (David Wahlstrom)
Date: Tue, 29 Sep 2015 12:57:22 -0700
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
 <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
Message-ID: <CAJ4zFrZYEcLoUmAmXNaHBFK-+XCwbzCVga9=WNUxAXsUqM_Gvw@mail.gmail.com>

I'm all for style checking.  We may also want to include some syntax
checking as well (bash -n <script>).  I personally believe that, so long as
the acceptance tests aren't overly strict, they provide a nice guide.

On Tue, Sep 29, 2015 at 12:43 PM, Joe Topjian <joe at topjian.net> wrote:

> So this will require bash scripts to adhere to bashate before being
> accepted? Is it possible to have the check as non-voting? Does this open
> the door to having other file types be checked?
>
> IMHO, it's more important for the OSOps project to foster collaboration
> and contributions rather than worry about an accepted style.
>
> As an example, yesterday's commits used hard-tabs:
>
> https://review.openstack.org/#/c/228545/
> https://review.openstack.org/#/c/228534/
>
> I think we're going to see a lot of variation of styles coming in.
>
> I don't want to come off as sounding ignorant or disrespectful to other
> projects that have guidelines in place -- I fully understand and respect
> those decisions.
>
> Joe
>
> On Tue, Sep 29, 2015 at 12:52 PM, JJ Asghar <jj at chef.io> wrote:
>
>> Awesome! That works!
>>
>> Best Regards,
>> JJ Asghar
>> c: 512.619.0722 t: @jjasghar irc: j^2
>>
>> On 9/29/15 1:27 PM, Christian Berendt wrote:
>> > On 09/29/2015 07:45 PM, JJ Asghar wrote:
>> >> So this popped up today[1]. This seems like something that should be
>> >> leveraged in our gates/validations?
>> >
>> > I prepared review requests to enable checks on the gates for
>> >
>> > * osops-tools-monitoring: https://review.openstack.org/#/c/229094/
>> > * osops-tools-generic: https://review.openstack.org/#/c/229043/
>> >
>> > Christian.
>> >
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
David W.
Unix, because every barista in Seattle has an MCSE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/cc6f986d/attachment.html>

From klindgren at godaddy.com  Tue Sep 29 20:29:39 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Tue, 29 Sep 2015 20:29:39 +0000
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
 <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
Message-ID: <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com>

If we are going to be stringent on formatting ? I would also like to see us be relatively consistent on arguments/env variables that are needed to make a script run.  Some pull in ENV vars, some source a rc file, some just say already source your rc file to start with, others accept command options.  It would be nice if we had a set of curated scripts that all worked in a similar fashion.

Also, to Joe's point. It would be nice if we had two place for scripts.  A "dumping ground" that people could share what they had.  And a curated one, where everything within the curated repo follows a standard set of conventions/guidelines.

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Joe Topjian
Date: Tuesday, September 29, 2015 at 1:43 PM
To: JJ Asghar
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
Subject: Re: [Openstack-operators] [openstack-operators][osops] Something other than NOOP in our jenkins tests

So this will require bash scripts to adhere to bashate before being accepted? Is it possible to have the check as non-voting? Does this open the door to having other file types be checked?

IMHO, it's more important for the OSOps project to foster collaboration and contributions rather than worry about an accepted style.

As an example, yesterday's commits used hard-tabs:

https://review.openstack.org/#/c/228545/
https://review.openstack.org/#/c/228534/

I think we're going to see a lot of variation of styles coming in.

I don't want to come off as sounding ignorant or disrespectful to other projects that have guidelines in place -- I fully understand and respect those decisions.

Joe

On Tue, Sep 29, 2015 at 12:52 PM, JJ Asghar <jj at chef.io<mailto:jj at chef.io>> wrote:
Awesome! That works!

Best Regards,
JJ Asghar
c: 512.619.0722<tel:512.619.0722> t: @jjasghar irc: j^2

On 9/29/15 1:27 PM, Christian Berendt wrote:
> On 09/29/2015 07:45 PM, JJ Asghar wrote:
>> So this popped up today[1]. This seems like something that should be
>> leveraged in our gates/validations?
>
> I prepared review requests to enable checks on the gates for
>
> * osops-tools-monitoring: https://review.openstack.org/#/c/229094/
> * osops-tools-generic: https://review.openstack.org/#/c/229043/
>
> Christian.
>


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/7c241bfd/attachment.html>

From jj at chef.io  Tue Sep 29 20:45:25 2015
From: jj at chef.io (JJ Asghar)
Date: Tue, 29 Sep 2015 15:45:25 -0500
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
 <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
 <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com>
Message-ID: <560AF865.80700@chef.io>

Seems reasonable.

If someone could put a "dumping ground" directory together that would
help. (with an uncurated script as an example)

So, i'm getting a feeling we should roll back the bashscript gate, and
go back to noop.

Thoughts?

Best Regards, 
JJ Asghar 
c: 512.619.0722 t: @jjasghar irc: j^2 

On 9/29/15 3:29 PM, Kris G. Lindgren wrote:
> If we are going to be stringent on formatting ? I would also like to
> see us be relatively consistent on arguments/env variables that are
> needed to make a script run.  Some pull in ENV vars, some source a rc
> file, some just say already source your rc file to start with, others
> accept command options.  It would be nice if we had a set of curated
> scripts that all worked in a similar fashion.
>
> Also, to Joe's point. It would be nice if we had two place for
> scripts.  A "dumping ground" that people could share what they had.
>  And a curated one, where everything within the curated repo follows a
> standard set of conventions/guidelines.  
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Joe Topjian
> Date: Tuesday, September 29, 2015 at 1:43 PM
> To: JJ Asghar
> Cc: "openstack-operators at lists.openstack.org
> <mailto:openstack-operators at lists.openstack.org>"
> Subject: Re: [Openstack-operators] [openstack-operators][osops]
> Something other than NOOP in our jenkins tests
>
> So this will require bash scripts to adhere to bashate before being
> accepted? Is it possible to have the check as non-voting? Does this
> open the door to having other file types be checked?
>
> IMHO, it's more important for the OSOps project to foster
> collaboration and contributions rather than worry about an accepted
> style.
>
> As an example, yesterday's commits used hard-tabs:
>
> https://review.openstack.org/#/c/228545/
> https://review.openstack.org/#/c/228534/
>
> I think we're going to see a lot of variation of styles coming in.
>
> I don't want to come off as sounding ignorant or disrespectful to
> other projects that have guidelines in place -- I fully understand and
> respect those decisions.
>
> Joe
>
> On Tue, Sep 29, 2015 at 12:52 PM, JJ Asghar <jj at chef.io
> <mailto:jj at chef.io>> wrote:
>
>     Awesome! That works!
>
>     Best Regards,
>     JJ Asghar
>     c: 512.619.0722 <tel:512.619.0722> t: @jjasghar irc: j^2
>
>     On 9/29/15 1:27 PM, Christian Berendt wrote:
>     > On 09/29/2015 07:45 PM, JJ Asghar wrote:
>     >> So this popped up today[1]. This seems like something that
>     should be
>     >> leveraged in our gates/validations?
>     >
>     > I prepared review requests to enable checks on the gates for
>     >
>     > * osops-tools-monitoring:
>     https://review.openstack.org/#/c/229094/
>     <https://review.openstack.org/#/c/229094/>
>     > * osops-tools-generic: https://review.openstack.org/#/c/229043/
>     <https://review.openstack.org/#/c/229043/>
>     >
>     > Christian.
>     >
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/0a2e9323/attachment.html>

From joe at topjian.net  Tue Sep 29 20:47:39 2015
From: joe at topjian.net (Joe Topjian)
Date: Tue, 29 Sep 2015 14:47:39 -0600
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
 <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
 <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com>
Message-ID: <CA+y7hvhjiGphQztiDH-3Y=8E1W9M1026UxnGZwoLNAaowtwsWw@mail.gmail.com>

+1

I like that idea. I think it also ties in nicely with both the Monitoring
and Tools WGs.

Some projects have a directory called "contrib" that contains contributed
items which might not be up to standard. Would that be a simple solution
for the "dumping ground"?



On Tue, Sep 29, 2015 at 2:29 PM, Kris G. Lindgren <klindgren at godaddy.com>
wrote:

> If we are going to be stringent on formatting ? I would also like to see
> us be relatively consistent on arguments/env variables that are needed to
> make a script run.  Some pull in ENV vars, some source a rc file, some just
> say already source your rc file to start with, others accept command
> options.  It would be nice if we had a set of curated scripts that all
> worked in a similar fashion.
>
> Also, to Joe's point. It would be nice if we had two place for scripts.  A
> "dumping ground" that people could share what they had.  And a curated one,
> where everything within the curated repo follows a standard set of
> conventions/guidelines.
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: Joe Topjian
> Date: Tuesday, September 29, 2015 at 1:43 PM
> To: JJ Asghar
> Cc: "openstack-operators at lists.openstack.org"
> Subject: Re: [Openstack-operators] [openstack-operators][osops] Something
> other than NOOP in our jenkins tests
>
> So this will require bash scripts to adhere to bashate before being
> accepted? Is it possible to have the check as non-voting? Does this open
> the door to having other file types be checked?
>
> IMHO, it's more important for the OSOps project to foster collaboration
> and contributions rather than worry about an accepted style.
>
> As an example, yesterday's commits used hard-tabs:
>
> https://review.openstack.org/#/c/228545/
> https://review.openstack.org/#/c/228534/
>
> I think we're going to see a lot of variation of styles coming in.
>
> I don't want to come off as sounding ignorant or disrespectful to other
> projects that have guidelines in place -- I fully understand and respect
> those decisions.
>
> Joe
>
> On Tue, Sep 29, 2015 at 12:52 PM, JJ Asghar <jj at chef.io> wrote:
>
>> Awesome! That works!
>>
>> Best Regards,
>> JJ Asghar
>> c: 512.619.0722 t: @jjasghar irc: j^2
>>
>> On 9/29/15 1:27 PM, Christian Berendt wrote:
>> > On 09/29/2015 07:45 PM, JJ Asghar wrote:
>> >> So this popped up today[1]. This seems like something that should be
>> >> leveraged in our gates/validations?
>> >
>> > I prepared review requests to enable checks on the gates for
>> >
>> > * osops-tools-monitoring: https://review.openstack.org/#/c/229094/
>> > * osops-tools-generic: https://review.openstack.org/#/c/229043/
>> >
>> > Christian.
>> >
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/ccf253b1/attachment.html>

From jj at chef.io  Tue Sep 29 20:57:17 2015
From: jj at chef.io (JJ Asghar)
Date: Tue, 29 Sep 2015 15:57:17 -0500
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <CA+y7hvhjiGphQztiDH-3Y=8E1W9M1026UxnGZwoLNAaowtwsWw@mail.gmail.com>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
 <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
 <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com>
 <CA+y7hvhjiGphQztiDH-3Y=8E1W9M1026UxnGZwoLNAaowtwsWw@mail.gmail.com>
Message-ID: <560AFB2D.6070503@chef.io>

Seems solid Joe!

Best Regards, 
JJ Asghar 
c: 512.619.0722 t: @jjasghar irc: j^2 

On 9/29/15 3:47 PM, Joe Topjian wrote:
> +1
>
> I like that idea. I think it also ties in nicely with both the
> Monitoring and Tools WGs.
>
> Some projects have a directory called "contrib" that contains
> contributed items which might not be up to standard. Would that be a
> simple solution for the "dumping ground"?
>
>
>
> On Tue, Sep 29, 2015 at 2:29 PM, Kris G. Lindgren
> <klindgren at godaddy.com <mailto:klindgren at godaddy.com>> wrote:
>
>     If we are going to be stringent on formatting ? I would also like
>     to see us be relatively consistent on arguments/env variables that
>     are needed to make a script run.  Some pull in ENV vars, some
>     source a rc file, some just say already source your rc file to
>     start with, others accept command options.  It would be nice if we
>     had a set of curated scripts that all worked in a similar fashion.
>
>     Also, to Joe's point. It would be nice if we had two place for
>     scripts.  A "dumping ground" that people could share what they
>     had.  And a curated one, where everything within the curated repo
>     follows a standard set of conventions/guidelines.  
>
>     ___________________________________________________________________
>     Kris Lindgren
>     Senior Linux Systems Engineer
>     GoDaddy
>
>     From: Joe Topjian
>     Date: Tuesday, September 29, 2015 at 1:43 PM
>     To: JJ Asghar
>     Cc: "openstack-operators at lists.openstack.org
>     <mailto:openstack-operators at lists.openstack.org>"
>     Subject: Re: [Openstack-operators] [openstack-operators][osops]
>     Something other than NOOP in our jenkins tests
>
>     So this will require bash scripts to adhere to bashate before
>     being accepted? Is it possible to have the check as non-voting?
>     Does this open the door to having other file types be checked?
>
>     IMHO, it's more important for the OSOps project to foster
>     collaboration and contributions rather than worry about an
>     accepted style.
>
>     As an example, yesterday's commits used hard-tabs:
>
>     https://review.openstack.org/#/c/228545/
>     https://review.openstack.org/#/c/228534/
>
>     I think we're going to see a lot of variation of styles coming in.
>
>     I don't want to come off as sounding ignorant or disrespectful to
>     other projects that have guidelines in place -- I fully understand
>     and respect those decisions.
>
>     Joe
>
>     On Tue, Sep 29, 2015 at 12:52 PM, JJ Asghar <jj at chef.io
>     <mailto:jj at chef.io>> wrote:
>
>         Awesome! That works!
>
>         Best Regards,
>         JJ Asghar
>         c: 512.619.0722 <tel:512.619.0722> t: @jjasghar irc: j^2
>
>         On 9/29/15 1:27 PM, Christian Berendt wrote:
>         > On 09/29/2015 07:45 PM, JJ Asghar wrote:
>         >> So this popped up today[1]. This seems like something that
>         should be
>         >> leveraged in our gates/validations?
>         >
>         > I prepared review requests to enable checks on the gates for
>         >
>         > * osops-tools-monitoring:
>         https://review.openstack.org/#/c/229094/
>         > * osops-tools-generic: https://review.openstack.org/#/c/229043/
>         >
>         > Christian.
>         >
>
>
>         _______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         <mailto:OpenStack-operators at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/b1a737d5/attachment.html>

From salman.toor at it.uu.se  Tue Sep 29 23:31:59 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Tue, 29 Sep 2015 23:31:59 +0000
Subject: [Openstack-operators] Multi region,
	different behavior from different platforms
Message-ID: <99B4809311BF4340B95D0F3720EAC0BB29AD4E9A@COLUMBA00.user.uu.se>

Hi,

I am trying to configure a multi region setup. I have one region setup on CentOS and second region on Ubuntu. Glance clients on different platforms are giving different outputs.

Ubuntu Trusty:
------------------


root at u-mn01:~/openstack# glance --version

0.15.0

root at u-mn01:~/openstack# glance --os-region-name=HPC2N image-list

+----+------+-------------+------------------+------+--------+

| ID | Name | Disk Format | Container Format | Size | Status |

+----+------+-------------+------------------+------+--------+

+----+------+-------------+------------------+------+--------+

root at u-mn01:~/openstack# glance --os-region-name=regionOne image-list

public endpoint for image service in regionOne region not found

------------------------------


CentOS 7.1

---------------


[root at controller: ~] # glance --version

0.17.0

[root at controller: ~] # glance --os-region-name=HPC2N image-list

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| ID                                   | Name                                  | Disk Format | Container Format | Size       | Status |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7                               | qcow2       | bare             | 1004994560 | active |

| 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn)         | qcow2       | bare             | 268829184  | active |

| 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)          | qcow2       | bare             | 288752128  | active |

| 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) | qcow2       | bare             | 258474496  | active |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

[root at controller: ~] # glance --os-region-name=regionOne image-list

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| ID                                   | Name                                  | Disk Format | Container Format | Size       | Status |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7                               | qcow2       | bare             | 1004994560 | active |

| 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn)         | qcow2       | bare             | 268829184  | active |

| 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)          | qcow2       | bare             | 288752128  | active |

| 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) | qcow2       | bare             | 258474496  | active |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+


MAC Laptop

---------------

Salmans-MBP:~ salmantoor$ glance --version

1.0.0

Salmans-MBP:~ salmantoor$ glance --os-region-name=regionOne image-list

+--------------------------------------+---------------------------------------+

| ID                                   | Name                                  |

+--------------------------------------+---------------------------------------+

| 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7                               |

| 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn)         |

| 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)          |

| 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) |

+--------------------------------------+---------------------------------------+

Salmans-MBP:~ salmantoor$ glance --os-region-name=HPC2N image-list

+----+------+

| ID | Name |

+----+------+

+----+------+


Horizon

----------

regionOne everything is working fine.

HPC2N -> Error: Invalid service catalog service: image


So only Mac laptop is giving correct behavior. CentOS Client implementation i think ignores the regions at all. Whereas Ubuntu has some problem with regionOne.


regionOne is hosting following services:

Keystone, glance, neutron, compute, cinder and swift


HPC2N currently only have Glance (will add more service once we figure it out whats happening in the system).


I am using Kilo release. Can someone give a hint whats happening here or how should I approach this problem?


Regards..

Salman.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/3091b5a9/attachment.html>

From klindgren at godaddy.com  Tue Sep 29 23:33:55 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Tue, 29 Sep 2015 23:33:55 +0000
Subject: [Openstack-operators] [ops] Operator Local Patches
Message-ID: <9FFC2E05-79FC-4876-A2B9-FD1C2BE1269D@godaddy.com>

Hello All,

We have some pretty good contributions of local patches on the etherpad.  We are going through right now and trying to group patches that multiple people are carrying and patches that people may not be carrying but solves a problem that they are running into.  If you can take some time and either add your own local patches that you have to the ether pad or add +1's next to the patches that are laid out, it would help us immensely.

The etherpad can be found at: https://etherpad.openstack.org/p/operator-local-patches

Thanks for your help!

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Tuesday, September 22, 2015 at 4:21 PM
To: openstack-operators
Subject: Re: Operator Local Patches

Hello all,

Friendly reminder: If you have local patches and haven't yet done so, please contribute to the etherpad at: https://etherpad.openstack.org/p/operator-local-patches

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Friday, September 18, 2015 at 4:35 PM
To: openstack-operators
Cc: Tom Fifield
Subject: Operator Local Patches

Hello Operators!

During the ops meetup in Palo Alto were we talking about sessions for Tokyo. A session that I purposed, that got a bunch of +1's,  was about local patches that operators were carrying.  From my experience this is done to either implement business logic,  fix assumptions in projects that do not apply to your implementation, implement business requirements that are not yet implemented in openstack, or fix scale related bugs.  What I would like to do is get a working group together to do the following:

1.) Document local patches that operators have (even those that are in gerrit right now waiting to be committed upstream)
2.) Figure out commonality in those patches
3.) Either upstream the common fixes to the appropriate projects or figure out if a hook can be added to allow people to run their code at that specific point
4.) ????
5.) Profit

To start this off, I have documented every patch, along with a description of what it does and why we did it (where needed), that GoDaddy is running [1].  What I am asking is that the operator community please update the etherpad with the patches that you are running, so that we have a good starting point for discussions in Tokyo and beyond.

[1] - https://etherpad.openstack.org/p/operator-local-patches
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/5242a229/attachment-0001.html>

From jj at chef.io  Tue Sep 29 23:37:58 2015
From: jj at chef.io (JJ Asghar)
Date: Tue, 29 Sep 2015 18:37:58 -0500
Subject: [Openstack-operators] [ops] Operator Local Patches
In-Reply-To: <9FFC2E05-79FC-4876-A2B9-FD1C2BE1269D@godaddy.com>
References: <9FFC2E05-79FC-4876-A2B9-FD1C2BE1269D@godaddy.com>
Message-ID: <560B20D6.8020409@chef.io>

Just spit balling here....

But wouldn't the way you deploy/patch these patches be good for the
OSOps tools? I bet there is some overlap and having a discussion around
how to get those patches _out_ would be a good topic?

(Probably for the Tools WG, but worth mentioning here)

Best Regards, 
JJ Asghar 
c: 512.619.0722 t: @jjasghar irc: j^2 

On 9/29/15 6:33 PM, Kris G. Lindgren wrote:
> Hello All,
>
> We have some pretty good contributions of local patches on the
> etherpad.  We are going through right now and trying to group patches
> that multiple people are carrying and patches that people may not be
> carrying but solves a problem that they are running into.  If you can
> take some time and either add your own local patches that you have to
> the ether pad or add +1's next to the patches that are laid out, it
> would help us immensely.
>
> The etherpad can be found
> at: https://etherpad.openstack.org/p/operator-local-patches
>
> Thanks for your help!
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: "Kris G. Lindgren"
> Date: Tuesday, September 22, 2015 at 4:21 PM
> To: openstack-operators
> Subject: Re: Operator Local Patches
>
> Hello all,
>
> Friendly reminder: If you have local patches and haven't yet done so,
> please contribute to the etherpad
> at: https://etherpad.openstack.org/p/operator-local-patches
>
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
> From: "Kris G. Lindgren"
> Date: Friday, September 18, 2015 at 4:35 PM
> To: openstack-operators
> Cc: Tom Fifield
> Subject: Operator Local Patches
>
> Hello Operators!
>
> During the ops meetup in Palo Alto were we talking about sessions for
> Tokyo. A session that I purposed, that got a bunch of +1's,  was about
> local patches that operators were carrying.  From my experience this
> is done to either implement business logic,  fix assumptions in
> projects that do not apply to your implementation, implement business
> requirements that are not yet implemented in openstack, or fix scale
> related bugs.  What I would like to do is get a working group together
> to do the following:
>
> 1.) Document local patches that operators have (even those that are in
> gerrit right now waiting to be committed upstream)
> 2.) Figure out commonality in those patches
> 3.) Either upstream the common fixes to the appropriate projects or
> figure out if a hook can be added to allow people to run their code at
> that specific point
> 4.) ????
> 5.) Profit
>
> To start this off, I have documented every patch, along with a
> description of what it does and why we did it (where needed), that
> GoDaddy is running [1].  What I am asking is that the operator
> community please update the etherpad with the patches that you are
> running, so that we have a good starting point for discussions in
> Tokyo and beyond.
>
> [1] - https://etherpad.openstack.org/p/operator-local-patches
> ___________________________________________________________________
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/61bb73ab/attachment.html>

From mordred at inaugust.com  Tue Sep 29 23:44:38 2015
From: mordred at inaugust.com (Monty Taylor)
Date: Tue, 29 Sep 2015 19:44:38 -0400
Subject: [Openstack-operators] Multi region,
 different behavior from different platforms
In-Reply-To: <99B4809311BF4340B95D0F3720EAC0BB29AD4E9A@COLUMBA00.user.uu.se>
Message-ID: <f180dc92-d484-4365-a269-8160fe5c9587@email.android.com>

You have a very old glance client on both centos and Ubuntu. You want 1.0 everywhere you're going to use it as a client.

On Sep 29, 2015 7:31 PM, Salman Toor <salman.toor at it.uu.se> wrote:
>
> Hi,?
>
> I am trying to configure a multi region setup. I have one region setup on CentOS and second region on Ubuntu. Glance clients on different platforms are giving different outputs.?
>
> Ubuntu Trusty:
> ------------------
>
> root at u-mn01:~/openstack# glance --version?
>
> 0.15.0
>
> root at u-mn01:~/openstack# glance --os-region-name=HPC2N image-list
>
> +----+------+-------------+------------------+------+--------+
>
> | ID | Name | Disk Format | Container Format | Size | Status |
>
> +----+------+-------------+------------------+------+--------+
>
> +----+------+-------------+------------------+------+--------+
>
> root at u-mn01:~/openstack# glance --os-region-name=regionOne image-list
>
> public endpoint for image service in regionOne region not found
>
> ------------------------------
>
>
> CentOS 7.1
>
> ---------------
>
>
> [root at controller: ~] # glance --version
>
> 0.17.0
>
> [root at controller: ~] # glance --os-region-name=HPC2N image-list
>
> +--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+
>
> | ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Disk Format | Container Format | Size ? ? ? | Status |
>
> +--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+
>
> | 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | qcow2 ? ? ? | bare ? ? ? ? ? ? | 1004994560 | active |
>
> | 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn) ? ? ? ? | qcow2 ? ? ? | bare ? ? ? ? ? ? | 268829184? | active |
>
> | 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)? ? ? ? ? | qcow2 ? ? ? | bare ? ? ? ? ? ? | 288752128? | active |
>
> | 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) | qcow2 ? ? ? | bare ? ? ? ? ? ? | 258474496? | active |
>
> +--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+
>
> [root at controller: ~] # glance --os-region-name=regionOne image-list
>
> +--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+
>
> | ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Disk Format | Container Format | Size ? ? ? | Status |
>
> +--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+
>
> | 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | qcow2 ? ? ? | bare ? ? ? ? ? ? | 1004994560 | active |
>
> | 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn) ? ? ? ? | qcow2 ? ? ? | bare ? ? ? ? ? ? | 268829184? | active |
>
> | 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)? ? ? ? ? | qcow2 ? ? ? | bare ? ? ? ? ? ? | 288752128? | active |
>
> | 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) | qcow2 ? ? ? | bare ? ? ? ? ? ? | 258474496? | active |
>
> +--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+
>
>
> MAC Laptop
>
> ---------------
>
> Salmans-MBP:~ salmantoor$ glance --version?
>
> 1.0.0
>
> Salmans-MBP:~ salmantoor$ glance --os-region-name=regionOne image-list
>
> +--------------------------------------+---------------------------------------+
>
> | ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>
> +--------------------------------------+---------------------------------------+
>
> | 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>
> | 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn) ? ? ? ? |
>
> | 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)? ? ? ? ? |
>
> | 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) |
>
> +--------------------------------------+---------------------------------------+
>
> Salmans-MBP:~ salmantoor$ glance --os-region-name=HPC2N image-list
>
> +----+------+
>
> | ID | Name |
>
> +----+------+
>
> +----+------+
>
>
> Horizon
>
> ----------
>
> regionOne everything is working fine.
>
> HPC2N ->?Error:?Invalid service catalog service: image
>
>
> So only Mac laptop is giving correct behavior. CentOS Client implementation i think ignores the regions at all. Whereas Ubuntu has some problem with regionOne.?
>
>
> regionOne is hosting following services:
>
> Keystone, glance, neutron, compute, cinder and swift
>
>
> HPC2N currently only have Glance (will add more service once we figure it out whats happening in the system).
>
>
> I am using Kilo release. Can someone give a hint whats happening here or how should I approach this problem?
>
>
> Regards..
>
> Salman.?
>
>
>
>
>
>

From klindgren at godaddy.com  Tue Sep 29 23:46:47 2015
From: klindgren at godaddy.com (Kris G. Lindgren)
Date: Tue, 29 Sep 2015 23:46:47 +0000
Subject: [Openstack-operators] [ops] Operator Local Patches
In-Reply-To: <560B20D6.8020409@chef.io>
References: <9FFC2E05-79FC-4876-A2B9-FD1C2BE1269D@godaddy.com>
 <560B20D6.8020409@chef.io>
Message-ID: <F13FBCBC-6A8A-4409-A826-AC1F0093DBAF@godaddy.com>

I was specifically leaving off that part of the convo for someone/somewhere else to pick up.

I was soley trying to focus on what changes operators have made to openstack locally.   Find some sort of commonality/lacking functionality in those patches.  Then either submit those patches to the upstream projects, or gets hooks added into the projects, by working with the PTL's of those projects.

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: JJ Asghar
Reply-To: "jj at chef.io<mailto:jj at chef.io>"
Date: Tuesday, September 29, 2015 at 5:37 PM
To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>"
Subject: Re: [Openstack-operators] [ops] Operator Local Patches

Just spit balling here....

But wouldn't the way you deploy/patch these patches be good for the OSOps tools? I bet there is some overlap and having a discussion around how to get those patches _out_ would be a good topic?

(Probably for the Tools WG, but worth mentioning here)

Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2

On 9/29/15 6:33 PM, Kris G. Lindgren wrote:
Hello All,

We have some pretty good contributions of local patches on the etherpad.  We are going through right now and trying to group patches that multiple people are carrying and patches that people may not be carrying but solves a problem that they are running into.  If you can take some time and either add your own local patches that you have to the ether pad or add +1's next to the patches that are laid out, it would help us immensely.

The etherpad can be found at: https://etherpad.openstack.org/p/operator-local-patches

Thanks for your help!

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Tuesday, September 22, 2015 at 4:21 PM
To: openstack-operators
Subject: Re: Operator Local Patches

Hello all,

Friendly reminder: If you have local patches and haven't yet done so, please contribute to the etherpad at: https://etherpad.openstack.org/p/operator-local-patches

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren"
Date: Friday, September 18, 2015 at 4:35 PM
To: openstack-operators
Cc: Tom Fifield
Subject: Operator Local Patches

Hello Operators!

During the ops meetup in Palo Alto were we talking about sessions for Tokyo. A session that I purposed, that got a bunch of +1's,  was about local patches that operators were carrying.  From my experience this is done to either implement business logic,  fix assumptions in projects that do not apply to your implementation, implement business requirements that are not yet implemented in openstack, or fix scale related bugs.  What I would like to do is get a working group together to do the following:

1.) Document local patches that operators have (even those that are in gerrit right now waiting to be committed upstream)
2.) Figure out commonality in those patches
3.) Either upstream the common fixes to the appropriate projects or figure out if a hook can be added to allow people to run their code at that specific point
4.) ????
5.) Profit

To start this off, I have documented every patch, along with a description of what it does and why we did it (where needed), that GoDaddy is running [1].  What I am asking is that the operator community please update the etherpad with the patches that you are running, so that we have a good starting point for discussions in Tokyo and beyond.

[1] - <https://etherpad.openstack.org/p/operator-local-patches> https://etherpad.openstack.org/p/operator-local-patches
___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/043a46a8/attachment.html>

From sorrison at gmail.com  Wed Sep 30 01:58:49 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Wed, 30 Sep 2015 11:58:49 +1000
Subject: [Openstack-operators] Neutron DHCP failover bug
Message-ID: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>

Hi All,

We are running Kilo and have come across this bug https://bugs.launchpad.net/neutron/+bug/1410067 <https://bugs.launchpad.net/neutron/+bug/1410067>

Pretty easy to replicate, have 2 network nodes, shutdown 1 of them and DHCP etc. moves over to the new host fine. Except doing a port-show on the DHCP port shows it still on the old host and in state BUILD.
Everything works but the DB is in the wrong state.

Just wondering if anyone else sees this and if so if they know the associated fix in Liberty that addresses this.

Cheers,
Sam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/860a1894/attachment.html>

From tom at openstack.org  Wed Sep 30 03:24:17 2015
From: tom at openstack.org (Tom Fifield)
Date: Wed, 30 Sep 2015 11:24:17 +0800
Subject: [Openstack-operators] Tokyo Ops Design Summit Tracks - Agenda on
	Sched
Message-ID: <560B55E1.5050604@openstack.org>

  Hi all,

The agenda for Tokyo design summit's ops track is now on sched (buy 
Thierry wine if you see him):

https://mitakadesignsummit.sched.org/overview/type/ops

* Note that we have some unallocated slots (marked "TBC"). In order to 
help out our software development community who are short of slots, 
unless we can find something with a burning need to fill them, I propose 
we hand the slots back. Your thoughts welcome!


Regards,



Tom


From john at dewey.ws  Wed Sep 30 05:48:06 2015
From: john at dewey.ws (John Dewey)
Date: Tue, 29 Sep 2015 22:48:06 -0700
Subject: [Openstack-operators] Neutron DHCP failover bug
In-Reply-To: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>
References: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>
Message-ID: <etPan.560b7796.64d32ddf.c6dd@JODEWEY-M-D867>

Why not run neutron dhcp agents on both nodes??

On September 29, 2015 at 7:04:57 PM, Sam Morrison (sorrison at gmail.com) wrote:

Hi All,

We are running Kilo and have come across this bug?https://bugs.launchpad.net/neutron/+bug/1410067

Pretty easy to replicate, have 2 network nodes, shutdown 1 of them and DHCP etc. moves over to the new host fine. Except doing a port-show on the DHCP port shows it still on the old host and in state BUILD.
Everything works but the DB is in the wrong state.

Just wondering if anyone else sees this and if so if they know the associated fix in Liberty that addresses this.

Cheers,
Sam

_______________________________________________  
OpenStack-operators mailing list  
OpenStack-operators at lists.openstack.org  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150929/c8834b06/attachment.html>

From salman.toor at it.uu.se  Wed Sep 30 08:09:38 2015
From: salman.toor at it.uu.se (Salman Toor)
Date: Wed, 30 Sep 2015 08:09:38 +0000
Subject: [Openstack-operators] Multi region,
 different behavior from different platforms
In-Reply-To: <f180dc92-d484-4365-a269-8160fe5c9587@email.android.com>
References: <f180dc92-d484-4365-a269-8160fe5c9587@email.android.com>
Message-ID: <642FD058-3DFD-4465-A49B-ED90C2942AE4@it.uu.se>

Thats strange

How come some of the packages are from 2015 and some from very old distribution?


[root at glance: ~] #  rpm -qa | grep glance
python-glance-store-0.4.0-1.el7.noarch
openstack-glance-2015.1.1-1.el7.noarch
python-glanceclient-0.17.0-2.el7.noarch
python-glance-2015.1.1-1.el7.noarch

root at u-mn01:~# dpkg -l | grep '^ii' | grep glance
ii  glance                              1:2015.1.1-0ubuntu2~cloud3       all          OpenStack Image Registry and Delivery Service - Daemons
ii  glance-api                          1:2015.1.1-0ubuntu2~cloud3       all          OpenStack Image Registry and Delivery Service - API
ii  glance-common                       1:2015.1.1-0ubuntu2~cloud3       all          OpenStack Image Registry and Delivery Service - Common
ii  glance-registry                     1:2015.1.1-0ubuntu2~cloud3       all          OpenStack Image Registry and Delivery Service - Registry
ii  python-glance                       1:2015.1.1-0ubuntu2~cloud3       all          OpenStack Image Registry and Delivery Service - Python library
ii  python-glance-store                 0.4.0-0ubuntu1~cloud0            all          OpenStack Image Service store library - Python 2.x
ii  python-glanceclient                 1:0.15.0-0ubuntu1~cloud0         all          Client library for Openstack glance server.


For installation I have followed OpenStack installation guide for kilo?

/Salman.


On 30 Sep 2015, at 01:44, Monty Taylor <mordred at inaugust.com<mailto:mordred at inaugust.com>> wrote:

You have a very old glance client on both centos and Ubuntu. You want 1.0 everywhere you're going to use it as a client.

On Sep 29, 2015 7:31 PM, Salman Toor <salman.toor at it.uu.se<mailto:salman.toor at it.uu.se>> wrote:

Hi,

I am trying to configure a multi region setup. I have one region setup on CentOS and second region on Ubuntu. Glance clients on different platforms are giving different outputs.

Ubuntu Trusty:
------------------

root at u-mn01:~/openstack# glance --version

0.15.0

root at u-mn01:~/openstack# glance --os-region-name=HPC2N image-list

+----+------+-------------+------------------+------+--------+

| ID | Name | Disk Format | Container Format | Size | Status |

+----+------+-------------+------------------+------+--------+

+----+------+-------------+------------------+------+--------+

root at u-mn01:~/openstack# glance --os-region-name=regionOne image-list

public endpoint for image service in regionOne region not found

------------------------------


CentOS 7.1

---------------


[root at controller: ~] # glance --version

0.17.0

[root at controller: ~] # glance --os-region-name=HPC2N image-list

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| ID                                   | Name                                  | Disk Format | Container Format | Size       | Status |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7                               | qcow2       | bare             | 1004994560 | active |

| 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn)         | qcow2       | bare             | 268829184  | active |

| 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)          | qcow2       | bare             | 288752128  | active |

| 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) | qcow2       | bare             | 258474496  | active |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

[root at controller: ~] # glance --os-region-name=regionOne image-list

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| ID                                   | Name                                  | Disk Format | Container Format | Size       | Status |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+

| 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7                               | qcow2       | bare             | 1004994560 | active |

| 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn)         | qcow2       | bare             | 268829184  | active |

| 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)          | qcow2       | bare             | 288752128  | active |

| 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) | qcow2       | bare             | 258474496  | active |

+--------------------------------------+---------------------------------------+-------------+------------------+------------+--------+


MAC Laptop

---------------

Salmans-MBP:~ salmantoor$ glance --version

1.0.0

Salmans-MBP:~ salmantoor$ glance --os-region-name=regionOne image-list

+--------------------------------------+---------------------------------------+

| ID                                   | Name                                  |

+--------------------------------------+---------------------------------------+

| 40a87571-1715-43c6-8723-cb6c11b532b2 | CentOS7                               |

| 2ac6a89e-6385-4f30-a861-f5d06f33fa45 | Ubuntu 14.10 (Utopic Unicorn)         |

| 94a2b0b2-6ca4-4b6c-bd5e-b79faef02533 | Ubuntu 15.10 (Wily Werewolf)          |

| 99f4625e-f425-472d-8e21-7aa9c3db1c3e | Ubuntu Server 14.04 LTS (Trusty Tahr) |

+--------------------------------------+---------------------------------------+

Salmans-MBP:~ salmantoor$ glance --os-region-name=HPC2N image-list

+----+------+

| ID | Name |

+----+------+

+----+------+


Horizon

----------

regionOne everything is working fine.

HPC2N -> Error: Invalid service catalog service: image


So only Mac laptop is giving correct behavior. CentOS Client implementation i think ignores the regions at all. Whereas Ubuntu has some problem with regionOne.


regionOne is hosting following services:

Keystone, glance, neutron, compute, cinder and swift


HPC2N currently only have Glance (will add more service once we figure it out whats happening in the system).


I am using Kilo release. Can someone give a hint whats happening here or how should I approach this problem?


Regards..

Salman.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/489b96c1/attachment.html>

From christian at berendt.io  Wed Sep 30 09:19:08 2015
From: christian at berendt.io (Christian Berendt)
Date: Wed, 30 Sep 2015 11:19:08 +0200
Subject: [Openstack-operators] [openstack-operators][osops] Something
 other than NOOP in our jenkins tests
In-Reply-To: <560AF865.80700@chef.io>
References: <560ACE2C.7090503@chef.io> <560AD81A.9030607@berendt.io>
 <560ADE04.9090902@chef.io>
 <CA+y7hviAB89MZY6CFEVmBYtOm5T3Rw-vmEYonFziVfD5nSJ51g@mail.gmail.com>
 <3CDB7099-A017-4F28-891E-4A0C54BF139C@godaddy.com> <560AF865.80700@chef.io>
Message-ID: <560BA90C.7010900@berendt.io>

On 09/29/2015 10:45 PM, JJ Asghar wrote:
> If someone could put a "dumping ground" directory together that would
> help. (with an uncurated script as an example)

If you want to have a directory in the repositories that should not be 
checked simply extend the bashate environment.

I prepared patches to not check a contrib directory with bashate:

* osops-tools-generic: https://review.openstack.org/#/c/229315/
* osops-tools-monitoring: https://review.openstack.org/229316

> So, i'm getting a feeling we should roll back the bashscript gate, and
> go back to noop.

The jobs on the gates are not yet active.

Christian.

-- 
Christian Berendt
Cloud Solution Architect
Mail: berendt at b1-systems.de

B1 Systems GmbH
Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


From sean at dague.net  Wed Sep 30 11:11:21 2015
From: sean at dague.net (Sean Dague)
Date: Wed, 30 Sep 2015 07:11:21 -0400
Subject: [Openstack-operators] [gate] devstack / grenade branching day -
	minor snafu
Message-ID: <560BC359.9090907@dague.net>

FYI, we've got a bit of a gate snafu this morning in cutting the
devstack / grenade branches for stable/liberty, as devstack-gate did not
yet have the support for stable/liberty in it.

That patch is up at - https://review.openstack.org/#/c/229363/

With any luck this all gets resolved in the next couple of hours. But
things are going to be a bit rocky until that bit lands.

	-Sean

-- 
Sean Dague
http://dague.net


From clayton at oneill.net  Wed Sep 30 11:48:29 2015
From: clayton at oneill.net (Clayton O'Neill)
Date: Wed, 30 Sep 2015 07:48:29 -0400
Subject: [Openstack-operators] Neutron DHCP failover bug
In-Reply-To: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>
References: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>
Message-ID: <CADg-rOWk9x+8Lh-7_4o5c+0JETZBty8ED88qQMiJqK3Wd+o6Vg@mail.gmail.com>

We've seen similar issues with three network nodes, 2 dhcp agents per and
automatic failover.  We were seeing spurious failovers on a regular basis
and we'd end up finding out about it because an instance would fail to get
a lease.  When we investigated, usually see the issue you describe.
Automatic failover is on by default in Kilo, so it makes this bug much
worse.  We ended up turning off automatic failover because of this issue.
There are other fixes for failover in Liberty that were never back ported
to Kilo.

On Tue, Sep 29, 2015 at 9:58 PM, Sam Morrison <sorrison at gmail.com> wrote:

> Hi All,
>
> We are running Kilo and have come across this bug
> https://bugs.launchpad.net/neutron/+bug/1410067
>
> Pretty easy to replicate, have 2 network nodes, shutdown 1 of them and
> DHCP etc. moves over to the new host fine. Except doing a port-show on the
> DHCP port shows it still on the old host and in state BUILD.
> Everything works but the DB is in the wrong state.
>
> Just wondering if anyone else sees this and if so if they know the
> associated fix in Liberty that addresses this.
>
> Cheers,
> Sam
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/2e8f5a0f/attachment.html>

From sgordon at redhat.com  Wed Sep 30 12:02:28 2015
From: sgordon at redhat.com (Steve Gordon)
Date: Wed, 30 Sep 2015 08:02:28 -0400 (EDT)
Subject: [Openstack-operators] [nfv][telcowg] Telco Working Group
 meeting	schedule
In-Reply-To: <142156967.59496233.1443530839928.JavaMail.zimbra@redhat.com>
References: <142156967.59496233.1443530839928.JavaMail.zimbra@redhat.com>
Message-ID: <117685662.60352062.1443614548679.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Steve Gordon" <sgordon at redhat.com>
> To: openstack-operators at lists.openstack.org, "OpenStack Development Mailing List (not for usage questions)"
> 
> 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

Hi all,

I was not able to find a backup facilitator so today's meeting is cancelled, I have updated the schedule on the wiki.

Thanks,

Steve


From davidoj at siminn.is  Wed Sep 30 13:14:46 2015
From: davidoj at siminn.is (=?iso-8859-1?Q?Dav=ED=F0_=D6rn_J=F3hannsson?=)
Date: Wed, 30 Sep 2015 13:14:46 +0000
Subject: [Openstack-operators] OpenStack Architecture, horizon and keystone
Message-ID: <1443618886868.31541@siminn.is>

I just recently joined a team in charge of implementing OpenStack deployment which I'm trying to grasp the design of.

One problem I encountered is that the openstack environment is on a pretty closed network and I need to use ssh
tunnelling to be able to access horizon, so I started to look into fronting the service with a reverse proxy
(making it available throug, horizon.example.com/horizon), then I noticed the horizon UI needs to contact the
Identity service, which I also fronted with a reverse proxy (identity.example.com:5000/v2.0) and configured
OPENSTACK_HOST = identity.example.com in /etc/openstack-dashboard/local_settings.py

The reverse proxy proxies requests to http://control1:5000 so when the response is sent back from the api it includes
<link href="http://http://control1:5000/v2.0/" rel="self"/> which the client has no network access to and a possible solution
would be to edit the url in /etc/keystone/keystone.conf then it dawned on me that we might have to re-think this design.

Possibly we are taking the wrong approach so I wanted to reach out to get some opinions on this matter since I'm new
to the architecture of OpenStack and haven't yet totally grasped how things are supposed to work together.?

Regards, Dav?d Johannsson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/a09bd06b/attachment.html>

From gvarghese at aqorn.com  Wed Sep 30 13:59:36 2015
From: gvarghese at aqorn.com (Geo Varghese)
Date: Wed, 30 Sep 2015 19:29:36 +0530
Subject: [Openstack-operators] patch-int port is not created in br-tun - kilo
Message-ID: <CADB-E-vJRpJXxVZWHNTq8EUtTS+tMYy7p-QRguP6xbb-NoK7aA@mail.gmail.com>

Hi Team,

I need a help with following issue

patch-int port is not created in br-tun. I am using kilo version of
openstack in ubuntu 14.04. It was working in icehouse ubuntu 12.04.

Its not created in both controller and compute.


root at Node4:~/compute# ovs-vsctl show
c1e3a6e9-5a11-4160-8903-e09de64eaa4f
    Bridge br-tun
        Port br-tun
            Interface br-tun
                type: internal
    Bridge br-int
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
    ovs_version: "2.3.2"


Guys, please give some inputs to fix this this issue. Is anything specific
needs to changed in any conf file?

Thanks again for great support from the group.


-- 
--
Regards,
Geo Varghese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/7e7208da/attachment.html>

From george.shuklin at gmail.com  Wed Sep 30 14:15:30 2015
From: george.shuklin at gmail.com (George Shuklin)
Date: Wed, 30 Sep 2015 17:15:30 +0300
Subject: [Openstack-operators] Live snapshots on the raw disks never ends
In-Reply-To: <CAJ4zFraKkU45PboJkeyYFfdBkC6aUxE1TSm98eVVfNSnNtL2DA@mail.gmail.com>
References: <5603F462.6050905@gmail.com>
 <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>
 <CAJ4zFraKkU45PboJkeyYFfdBkC6aUxE1TSm98eVVfNSnNtL2DA@mail.gmail.com>
Message-ID: <560BEE82.3010400@gmail.com>

Yes, we using swift as backend, and swift running as separate 
installation (own keystone, etc).

I can't find any logs about any problems with backend. They should be 
logged by glance?


On 09/29/2015 01:21 AM, David Wahlstrom wrote:
> George,
>
> What is your storage backend using (Gluster/ceph/local disk/etc)?  
> Some of the distributed backend drivers have bugs in them or mask the 
> real issue (such as watchers on objects).
>
> On Thu, Sep 24, 2015 at 8:11 AM, Kris G. Lindgren 
> <klindgren at godaddy.com <mailto:klindgren at godaddy.com>> wrote:
>
>     I believe I was talking to Josh Harlow (he's harlowja in
>     #openstack-operators on freenode) from Yahoo, about something like
>     this the other day.  He was saying that recently on a few
>     hypervisors they would randomly run into HV disks that were
>     completely full due to snapshots.  I have not personally ran into
>     this, so I can't be of more help.
>
>     ___________________________________________________________________
>     Kris Lindgren
>     Senior Linux Systems Engineer
>     GoDaddy
>
>
>
>
>
>     On 9/24/15, 7:02 AM, "George Shuklin" <george.shuklin at gmail.com
>     <mailto:george.shuklin at gmail.com>> wrote:
>
>     >Hello everyone.
>     >
>     >Is someone ever saw 'endless snapshot' problem? Some instances
>     (with raw
>     >disks and live snapshoting enabled) are stuck at image_uploading
>     forever.
>     >
>     >It looks like this:
>     >
>     >+--------------------------------------+----------------------------------------------------------+
>     >| Property                             | Value                  
>                                 |
>     >+--------------------------------------+----------------------------------------------------------+
>     >| status                               | ACTIVE                  
>                                |
>     >| updated                              | 2015-07-16T08:07:00Z  |
>     >| OS-EXT-STS:task_state                | image_uploading |
>     >| OS-EXT-SRV-ATTR:host                 | compute                
>                                   |
>     >| key_name                             | ses                    
>                               |
>     >| image                                | Ubuntu 14.04
>     (3736af94-b25e-4b8d-96fd-fd5949bbd81e)      |
>     >| OS-EXT-STS:vm_state                  | active                  
>                                |
>     >| OS-EXT-SRV-ATTR:instance_name        | instance-0000000d |
>     >| OS-SRV-USG:launched_at               |
>     2015-05-09T17:28:09.000000  |
>     >| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.lab.internal  |
>     >| flavor                               | flavor2 (2)             
>                                     |
>     >| id                                   |
>     f2365fe4-9b30-4c24-b7b9-f7fcb4165160  |
>     >| security_groups                      | [{u'name': u'default'}] 
>                                     |
>     >| OS-SRV-USG:terminated_at             | None                    
>                              |
>     >| user_id                              |
>     61096c639d674e4cb8bf487cec01432a  |
>     >| name                                 | non-test                
>                                  |
>     >| created                              | 2015-05-09T17:27:48Z  |
>     >...etc
>     >
>     >Any ideas why this happens? All logs are clear, no errors or
>     anything.
>     >And it happens at random so no 'debug' log available...
>     >
>     >_______________________________________________
>     >OpenStack-operators mailing list
>     >OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> -- 
> David W.
> Unix, because every barista in Seattle has an MCSE.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/37189d23/attachment.html>

From george.shuklin at gmail.com  Wed Sep 30 14:23:36 2015
From: george.shuklin at gmail.com (George Shuklin)
Date: Wed, 30 Sep 2015 17:23:36 +0300
Subject: [Openstack-operators] OpenStack Architecture,
 horizon and keystone
In-Reply-To: <1443618886868.31541@siminn.is>
References: <1443618886868.31541@siminn.is>
Message-ID: <560BF068.80307@gmail.com>

There is two approaches.

1) You make public endpoints and horizon public. White IP, resolvable 
FQDN for endpoints, etc.
2) You hide endpoints from user (boo... no api, no automation), but 
expose horizon.

Second case: horizon will sits as middleware between 'internal' networks 
where endpoints live, and outer world. Horizon may works fine even all 
endpoints are hidden from user. But wsgi part of the Horizon should be 
able to access endpoints.


On 09/30/2015 04:14 PM, Dav?? ?rn J?hannsson wrote:
> I just recently joined a team in charge of implementing OpenStack 
> deployment which I'm trying to grasp the design of.
>
> One problem I encountered is that the openstack environment is on a 
> pretty closed network and I need to use ssh
> tunnelling to be able to access horizon, so I started to look into 
> fronting the service with a reverse proxy
> (making it available throug, horizon.example.com/horizon), then I 
> noticed the horizon UI needs to contact the
> Identity service, which I also fronted with a reverse proxy 
> (identity.example.com:5000/v2.0) and configured
> OPENSTACK_HOST = identity.example.com in 
> /etc/openstack-dashboard/local_settings.py
>
> The reverse proxy proxies requests to http://control1:5000 so when the 
> response is sent back from the api it includes
> <link href="http://http://control1:5000/v2.0/" rel="self"/> which the 
> client has no network access to and a possible solution
> would be to edit the url in /etc/keystone/keystone.conf then it dawned 
> on me that we might have to re-think this design.
>
> Possibly we are taking the wrong approach so I wanted to reach out to 
> get some opinions on this matter since I'm new
> to the architecture of OpenStack and haven't yet totally grasped how 
> things are supposed to work together.?
>
> Regards, Dav?d Johannsson
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/456481a0/attachment.html>

From serverascode at gmail.com  Wed Sep 30 14:42:01 2015
From: serverascode at gmail.com (Curtis)
Date: Wed, 30 Sep 2015 08:42:01 -0600
Subject: [Openstack-operators] Live snapshots on the raw disks never ends
In-Reply-To: <560BEE82.3010400@gmail.com>
References: <5603F462.6050905@gmail.com>
 <464B5A2B-6EF7-4C47-8878-612FB120DF3B@godaddy.com>
 <CAJ4zFraKkU45PboJkeyYFfdBkC6aUxE1TSm98eVVfNSnNtL2DA@mail.gmail.com>
 <560BEE82.3010400@gmail.com>
Message-ID: <CAJ_JamBAinrzH5DRGuEnbkLxOp5DKLbV5k-aOwQysE8QKc8axA@mail.gmail.com>

On Wed, Sep 30, 2015 at 8:15 AM, George Shuklin
<george.shuklin at gmail.com> wrote:
> Yes, we using swift as backend, and swift running as separate installation
> (own keystone, etc).
>
> I can't find any logs about any problems with backend. They should be logged
> by glance?
>

I'd look for timeouts. Snapshots with raw disks and swift can take
time and end up timing out at loadbalancers, or perhaps even tokens.

Just a thought...

Thanks,
Curtis.

>
>
> On 09/29/2015 01:21 AM, David Wahlstrom wrote:
>
> George,
>
> What is your storage backend using (Gluster/ceph/local disk/etc)?  Some of
> the distributed backend drivers have bugs in them or mask the real issue
> (such as watchers on objects).
>
> On Thu, Sep 24, 2015 at 8:11 AM, Kris G. Lindgren <klindgren at godaddy.com>
> wrote:
>>
>> I believe I was talking to Josh Harlow (he's harlowja in
>> #openstack-operators on freenode) from Yahoo, about something like this the
>> other day.  He was saying that recently on a few hypervisors they would
>> randomly run into HV disks that were completely full due to snapshots.  I
>> have not personally ran into this, so I can't be of more help.
>>
>> ___________________________________________________________________
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy
>>
>>
>>
>>
>>
>> On 9/24/15, 7:02 AM, "George Shuklin" <george.shuklin at gmail.com> wrote:
>>
>> >Hello everyone.
>> >
>> >Is someone ever saw 'endless snapshot' problem? Some instances (with raw
>> >disks and live snapshoting enabled) are stuck at image_uploading forever.
>> >
>> >It looks like this:
>> >
>>
>> > >+--------------------------------------+----------------------------------------------------------+
>> >| Property                             | Value
>> > |
>>
>> > >+--------------------------------------+----------------------------------------------------------+
>> >| status                               | ACTIVE
>> > |
>> >| updated                              | 2015-07-16T08:07:00Z
>> > |
>> >| OS-EXT-STS:task_state                | image_uploading
>> > |
>> >| OS-EXT-SRV-ATTR:host                 | compute
>> > |
>> >| key_name                             | ses
>> > |
>> >| image                                | Ubuntu 14.04
>> > (3736af94-b25e-4b8d-96fd-fd5949bbd81e)      |
>> >| OS-EXT-STS:vm_state                  | active
>> > |
>> >| OS-EXT-SRV-ATTR:instance_name        | instance-0000000d
>> > |
>> >| OS-SRV-USG:launched_at               | 2015-05-09T17:28:09.000000
>> > |
>> >| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute.lab.internal
>> > |
>> >| flavor                               | flavor2 (2)
>> > |
>> >| id                                   |
>> > f2365fe4-9b30-4c24-b7b9-f7fcb4165160                     |
>> >| security_groups                      | [{u'name': u'default'}]
>> > |
>> >| OS-SRV-USG:terminated_at             | None
>> > |
>> >| user_id                              | 61096c639d674e4cb8bf487cec01432a
>> > |
>> >| name                                 | non-test
>> > |
>> >| created                              | 2015-05-09T17:27:48Z
>> > |
>> >...etc
>> >
>> >Any ideas why this happens? All logs are clear, no errors or anything.
>> >And it happens at random so no 'debug' log available...
>> >
>> >_______________________________________________
>> >OpenStack-operators mailing list
>> >OpenStack-operators at lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> --
> David W.
> Unix, because every barista in Seattle has an MCSE.
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Twitter: @serverascode
Blog: serverascode.com


From ignaziocassano at gmail.com  Wed Sep 30 16:35:30 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Wed, 30 Sep 2015 18:35:30 +0200
Subject: [Openstack-operators] telemetry secret
Message-ID: <CAB7j8cVLFNQCcTDdmxjDDDNvdrNiX8OsdBGvQ8a75Xh_Nz+qQg@mail.gmail.com>

Hi everyone, I reinstalled openstak kilo telemetry and I forgot to save my
old telemetry secret , so I created a new one and wrote it in
ceilometer.conf .
Is telemetry secret stored  in other places ?
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/3140ec74/attachment.html>

From mdorman at godaddy.com  Wed Sep 30 16:59:41 2015
From: mdorman at godaddy.com (Mike Dorman)
Date: Wed, 30 Sep 2015 16:59:41 +0000
Subject: [Openstack-operators] Neutron DHCP failover bug
In-Reply-To: <CADg-rOWk9x+8Lh-7_4o5c+0JETZBty8ED88qQMiJqK3Wd+o6Vg@mail.gmail.com>
References: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>
 <CADg-rOWk9x+8Lh-7_4o5c+0JETZBty8ED88qQMiJqK3Wd+o6Vg@mail.gmail.com>
Message-ID: <0EEE796D-DD9C-4E33-9277-292010C60FF9@godaddy.com>

We also run DHCP as active-active on both nodes and don?t do any failover at all.  Worst case, both DHCP agents respond to a client, but the lease info is the same from both, anyway.


From: Clayton O'Neill
Date: Wednesday, September 30, 2015 at 5:48 AM
To: Sam Morrison
Cc: OpenStack Operators
Subject: Re: [Openstack-operators] Neutron DHCP failover bug

We've seen similar issues with three network nodes, 2 dhcp agents per and automatic failover.  We were seeing spurious failovers on a regular basis and we'd end up finding out about it because an instance would fail to get a lease.  When we investigated, usually see the issue you describe.  Automatic failover is on by default in Kilo, so it makes this bug much worse.  We ended up turning off automatic failover because of this issue.  There are other fixes for failover in Liberty that were never back ported to Kilo.

On Tue, Sep 29, 2015 at 9:58 PM, Sam Morrison <sorrison at gmail.com<mailto:sorrison at gmail.com>> wrote:
Hi All,

We are running Kilo and have come across this bug https://bugs.launchpad.net/neutron/+bug/1410067

Pretty easy to replicate, have 2 network nodes, shutdown 1 of them and DHCP etc. moves over to the new host fine. Except doing a port-show on the DHCP port shows it still on the old host and in state BUILD.
Everything works but the DB is in the wrong state.

Just wondering if anyone else sees this and if so if they know the associated fix in Liberty that addresses this.

Cheers,
Sam


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/7d8edc15/attachment.html>

From chris.friesen at windriver.com  Wed Sep 30 17:13:36 2015
From: chris.friesen at windriver.com (Chris Friesen)
Date: Wed, 30 Sep 2015 11:13:36 -0600
Subject: [Openstack-operators] how to deal with always-growing
	notifications.info queue?
Message-ID: <560C1840.4000105@windriver.com>

Hi,

We've recently run into an issue where the notifications.info rabbitmq queue is 
perpetually growing, ultimately consuming significant amounts of memory.

How do others deal with this?  Do you always have a consumer draining the queue?

Chris


From james at agentultra.com  Wed Sep 30 17:23:41 2015
From: james at agentultra.com (James King)
Date: Wed, 30 Sep 2015 13:23:41 -0400
Subject: [Openstack-operators] how to deal with always-growing
	notifications.info queue?
In-Reply-To: <560C1840.4000105@windriver.com>
References: <560C1840.4000105@windriver.com>
Message-ID: <4EC1BB4D-3F4B-4F10-91AE-934B8E22075D@agentultra.com>

Yup. We periodically consume the queue. You can also turn off ceilometer reporting in the service publishing the notifications, iirc.

> On Sep 30, 2015, at 1:13 PM, Chris Friesen <chris.friesen at windriver.com> wrote:
> 
> Hi,
> 
> We've recently run into an issue where the notifications.info rabbitmq queue is perpetually growing, ultimately consuming significant amounts of memory.
> 
> How do others deal with this?  Do you always have a consumer draining the queue?
> 
> Chris
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



From mdorman at godaddy.com  Wed Sep 30 17:25:53 2015
From: mdorman at godaddy.com (Mike Dorman)
Date: Wed, 30 Sep 2015 17:25:53 +0000
Subject: [Openstack-operators] how to deal with always-growing
 notifications.info queue?
In-Reply-To: <560C1840.4000105@windriver.com>
References: <560C1840.4000105@windriver.com>
Message-ID: <B9511AB6-F132-4718-A712-0009F346E706@godaddy.com>

Yep.  If you don?t have ceilometer or something consuming those notifications, you can probably just turn off the feature so the messages aren?t sent in the first place.

Generally I think you should be able to disable it by setting [DEFAULT]/notification_driver to blank in each of the service config files.

Mike





On 9/30/15, 11:13 AM, "Chris Friesen" <chris.friesen at windriver.com> wrote:

>Hi,
>
>We've recently run into an issue where the notifications.info rabbitmq queue is 
>perpetually growing, ultimately consuming significant amounts of memory.
>
>How do others deal with this?  Do you always have a consumer draining the queue?
>
>Chris
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

From matt at mattfischer.com  Wed Sep 30 17:38:31 2015
From: matt at mattfischer.com (Matt Fischer)
Date: Wed, 30 Sep 2015 11:38:31 -0600
Subject: [Openstack-operators] how to deal with always-growing
 notifications.info queue?
In-Reply-To: <4EC1BB4D-3F4B-4F10-91AE-934B8E22075D@agentultra.com>
References: <560C1840.4000105@windriver.com>
 <4EC1BB4D-3F4B-4F10-91AE-934B8E22075D@agentultra.com>
Message-ID: <CAHr1CO90fKCNR6eaUm2gHSFan+ES2VUwuX1vjOvqgDc5pfEGqw@mail.gmail.com>

I'd recommend a few things. The first is you need to disable notifications
in your services including nova. You just set the notifications driver to
noop.  Second, you should have some monitoring in place that looks for
queues that go over a certain threshold. There's not a lot of queues that
should be sitting with a ton of unconsumed messages, we have Icinga checks
in place to warn us when a queue grows over 5k messages.

On Wed, Sep 30, 2015 at 11:23 AM, James King <james at agentultra.com> wrote:

> Yup. We periodically consume the queue. You can also turn off ceilometer
> reporting in the service publishing the notifications, iirc.
>
> > On Sep 30, 2015, at 1:13 PM, Chris Friesen <chris.friesen at windriver.com>
> wrote:
> >
> > Hi,
> >
> > We've recently run into an issue where the notifications.info rabbitmq
> queue is perpetually growing, ultimately consuming significant amounts of
> memory.
> >
> > How do others deal with this?  Do you always have a consumer draining
> the queue?
> >
> > Chris
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/a0a1bced/attachment.html>

From ignaziocassano at gmail.com  Wed Sep 30 19:14:38 2015
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Wed, 30 Sep 2015 21:14:38 +0200
Subject: [Openstack-operators] kilo ceilometer deployment mongodb
Message-ID: <CAB7j8cWE-DDLM8e0O8xELmm3hBL4yD_WseuTvgJ989SshfYPaQ@mail.gmail.com>

Hi all, I followed openstack.ork kilo deployment documentation to install
ceilometer for centos 7.
I presume there is some errors in documumentation because "mongo --host
......." command does not create the ceilometer db.
Must I create the db before launching the command ?
Regards
Ignazio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/80a05289/attachment.html>

From gvarghese at aqorn.com  Wed Sep 30 19:18:44 2015
From: gvarghese at aqorn.com (Geo Varghese)
Date: Thu, 1 Oct 2015 00:48:44 +0530
Subject: [Openstack-operators] [Openstack] patch-int port is not created
	in br-tun - kilo
In-Reply-To: <CAJCkLkRFArVt2Samjx80xuqkn4LNmf6Nvtx3cnpsRmEnC2S7KA@mail.gmail.com>
References: <CADB-E-vJRpJXxVZWHNTq8EUtTS+tMYy7p-QRguP6xbb-NoK7aA@mail.gmail.com>
 <CAJCkLkRFArVt2Samjx80xuqkn4LNmf6Nvtx3cnpsRmEnC2S7KA@mail.gmail.com>
Message-ID: <CADB-E-sVF8AiivcE=_QWH67oiZ7gDHNdZKHK_UJ40TWyYFgOYg@mail.gmail.com>

Hi Sinh,

Thanks for the update.

Its already started and showing up in command

neutron agent list

Not sure why the peer ports not created. Its created by plugin or l3-agent?

I am using ml2 plugin.


On Wed, Sep 30, 2015 at 11:51 PM, Sinh Lam <sinh.lam at verizondigitalmedia.com
> wrote:

> can you make sure the openvswitch plugin is started?
>
> looks like the bridges were made but not the peer ports and as far as i
> can tell that is brought up when you start the plugin.
>
> let me know if that helps.
>
> sinh
>
>
> On Wed, Sep 30, 2015 at 6:59 AM, Geo Varghese <gvarghese at aqorn.com> wrote:
>
>> Hi Team,
>>
>> I need a help with following issue
>>
>> patch-int port is not created in br-tun. I am using kilo version of
>> openstack in ubuntu 14.04. It was working in icehouse ubuntu 12.04.
>>
>> Its not created in both controller and compute.
>>
>>
>> root at Node4:~/compute# ovs-vsctl show
>> c1e3a6e9-5a11-4160-8903-e09de64eaa4f
>>     Bridge br-tun
>>         Port br-tun
>>             Interface br-tun
>>                 type: internal
>>     Bridge br-int
>>         fail_mode: secure
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>     ovs_version: "2.3.2"
>>
>>
>> Guys, please give some inputs to fix this this issue. Is anything
>> specific needs to changed in any conf file?
>>
>> Thanks again for great support from the group.
>>
>>
>> --
>> --
>> Regards,
>> Geo Varghese
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>


-- 
--
Regards,
Geo Varghese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151001/1066042e/attachment.html>

From amuller at redhat.com  Wed Sep 30 20:06:41 2015
From: amuller at redhat.com (Assaf Muller)
Date: Wed, 30 Sep 2015 16:06:41 -0400
Subject: [Openstack-operators] [Openstack] patch-int port is not created
 in br-tun - kilo
In-Reply-To: <CADB-E-sVF8AiivcE=_QWH67oiZ7gDHNdZKHK_UJ40TWyYFgOYg@mail.gmail.com>
References: <CADB-E-vJRpJXxVZWHNTq8EUtTS+tMYy7p-QRguP6xbb-NoK7aA@mail.gmail.com>
 <CAJCkLkRFArVt2Samjx80xuqkn4LNmf6Nvtx3cnpsRmEnC2S7KA@mail.gmail.com>
 <CADB-E-sVF8AiivcE=_QWH67oiZ7gDHNdZKHK_UJ40TWyYFgOYg@mail.gmail.com>
Message-ID: <CABARBAaUhA+ATfXMNpUh+B6MQ9K+RpGLM0TBCAR9Z432w1Qf-w@mail.gmail.com>

On Wed, Sep 30, 2015 at 3:18 PM, Geo Varghese <gvarghese at aqorn.com> wrote:

> Hi Sinh,
>
> Thanks for the update.
>
> Its already started and showing up in command
>
> neutron agent list
>
> Not sure why the peer ports not created. Its created by plugin or l3-agent?
>
> I am using ml2 plugin.
>

Restarting neutron-openvswitch-agent should re-create the patch ports.
Restarting the 'openvswitch' service would be one explanation why
the patch ports were deleted.


>
>
> On Wed, Sep 30, 2015 at 11:51 PM, Sinh Lam <
> sinh.lam at verizondigitalmedia.com> wrote:
>
>> can you make sure the openvswitch plugin is started?
>>
>> looks like the bridges were made but not the peer ports and as far as i
>> can tell that is brought up when you start the plugin.
>>
>> let me know if that helps.
>>
>> sinh
>>
>>
>> On Wed, Sep 30, 2015 at 6:59 AM, Geo Varghese <gvarghese at aqorn.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> I need a help with following issue
>>>
>>> patch-int port is not created in br-tun. I am using kilo version of
>>> openstack in ubuntu 14.04. It was working in icehouse ubuntu 12.04.
>>>
>>> Its not created in both controller and compute.
>>>
>>>
>>> root at Node4:~/compute# ovs-vsctl show
>>> c1e3a6e9-5a11-4160-8903-e09de64eaa4f
>>>     Bridge br-tun
>>>         Port br-tun
>>>             Interface br-tun
>>>                 type: internal
>>>     Bridge br-int
>>>         fail_mode: secure
>>>         Port br-int
>>>             Interface br-int
>>>                 type: internal
>>>     ovs_version: "2.3.2"
>>>
>>>
>>> Guys, please give some inputs to fix this this issue. Is anything
>>> specific needs to changed in any conf file?
>>>
>>> Thanks again for great support from the group.
>>>
>>>
>>> --
>>> --
>>> Regards,
>>> Geo Varghese
>>>
>>> _______________________________________________
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>>
>
>
> --
> --
> Regards,
> Geo Varghese
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150930/1bc598d4/attachment.html>

From gvarghese at aqorn.com  Wed Sep 30 20:34:15 2015
From: gvarghese at aqorn.com (Geo Varghese)
Date: Thu, 1 Oct 2015 02:04:15 +0530
Subject: [Openstack-operators] [Openstack] patch-int port is not created
	in br-tun - kilo
In-Reply-To: <CAJCkLkT568wzuyv_=eyKX2eJMGVbQOaMWQe_VrgSor6-b3KTbw@mail.gmail.com>
References: <CADB-E-vJRpJXxVZWHNTq8EUtTS+tMYy7p-QRguP6xbb-NoK7aA@mail.gmail.com>
 <CAJCkLkRFArVt2Samjx80xuqkn4LNmf6Nvtx3cnpsRmEnC2S7KA@mail.gmail.com>
 <CADB-E-sVF8AiivcE=_QWH67oiZ7gDHNdZKHK_UJ40TWyYFgOYg@mail.gmail.com>
 <CAJCkLkT568wzuyv_=eyKX2eJMGVbQOaMWQe_VrgSor6-b3KTbw@mail.gmail.com>
Message-ID: <CADB-E-vgic70NdYNyJsBORVBXeb7U3vQZfaMN8nzn2JAw7zgkg@mail.gmail.com>

Hi Sinh,

Thanks again for that information. Let me check with it.

On Thu, Oct 1, 2015 at 12:55 AM, Sinh Lam <sinh.lam at verizondigitalmedia.com>
wrote:

> here's my config of my ml2_conf.ini.
>
> [ml2]
>
> type_drivers=vlan
>
> tenant_network_types=vlan
>
> mechanism_drivers=openvswitch
>
> [ml2_type_flat]
>
> [ml2_type_vlan]
>
> network_vlan_ranges=Intnet1:100:3000
>
> [ml2_type_gre]
>
> [ml2_type_vxlan]
>
> [securitygroup]
>
>
> firewall_driver=neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>
> enable_security_group=True
>
> [ovs]
>
> use_veth_interconnection=True
>
> bridge_mappings=Intnet1:br-eth1
>
> When i switched from havana to juno, i had to specify
> use_veth_interconnection=True otherwise my peer ports wouldn't be
> physically created.  i know you're using patch ports but hope it helps.
>
> sinh
>
>
> On Wed, Sep 30, 2015 at 12:18 PM, Geo Varghese <gvarghese at aqorn.com>
> wrote:
>
>> Hi Sinh,
>>
>> Thanks for the update.
>>
>> Its already started and showing up in command
>>
>> neutron agent list
>>
>> Not sure why the peer ports not created. Its created by plugin or
>> l3-agent?
>>
>> I am using ml2 plugin.
>>
>>
>> On Wed, Sep 30, 2015 at 11:51 PM, Sinh Lam <
>> sinh.lam at verizondigitalmedia.com> wrote:
>>
>>> can you make sure the openvswitch plugin is started?
>>>
>>> looks like the bridges were made but not the peer ports and as far as i
>>> can tell that is brought up when you start the plugin.
>>>
>>> let me know if that helps.
>>>
>>> sinh
>>>
>>>
>>> On Wed, Sep 30, 2015 at 6:59 AM, Geo Varghese <gvarghese at aqorn.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I need a help with following issue
>>>>
>>>> patch-int port is not created in br-tun. I am using kilo version of
>>>> openstack in ubuntu 14.04. It was working in icehouse ubuntu 12.04.
>>>>
>>>> Its not created in both controller and compute.
>>>>
>>>>
>>>> root at Node4:~/compute# ovs-vsctl show
>>>> c1e3a6e9-5a11-4160-8903-e09de64eaa4f
>>>>     Bridge br-tun
>>>>         Port br-tun
>>>>             Interface br-tun
>>>>                 type: internal
>>>>     Bridge br-int
>>>>         fail_mode: secure
>>>>         Port br-int
>>>>             Interface br-int
>>>>                 type: internal
>>>>     ovs_version: "2.3.2"
>>>>
>>>>
>>>> Guys, please give some inputs to fix this this issue. Is anything
>>>> specific needs to changed in any conf file?
>>>>
>>>> Thanks again for great support from the group.
>>>>
>>>>
>>>> --
>>>> --
>>>> Regards,
>>>> Geo Varghese
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>> Post to     : openstack at lists.openstack.org
>>>> Unsubscribe :
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>
>>>>
>>>
>>
>>
>> --
>> --
>> Regards,
>> Geo Varghese
>>
>
>


-- 
--
Regards,
Geo Varghese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151001/4d25156e/attachment.html>

From gvarghese at aqorn.com  Wed Sep 30 20:35:04 2015
From: gvarghese at aqorn.com (Geo Varghese)
Date: Thu, 1 Oct 2015 02:05:04 +0530
Subject: [Openstack-operators] [Openstack] patch-int port is not created
 in br-tun - kilo
In-Reply-To: <CABARBAaUhA+ATfXMNpUh+B6MQ9K+RpGLM0TBCAR9Z432w1Qf-w@mail.gmail.com>
References: <CADB-E-vJRpJXxVZWHNTq8EUtTS+tMYy7p-QRguP6xbb-NoK7aA@mail.gmail.com>
 <CAJCkLkRFArVt2Samjx80xuqkn4LNmf6Nvtx3cnpsRmEnC2S7KA@mail.gmail.com>
 <CADB-E-sVF8AiivcE=_QWH67oiZ7gDHNdZKHK_UJ40TWyYFgOYg@mail.gmail.com>
 <CABARBAaUhA+ATfXMNpUh+B6MQ9K+RpGLM0TBCAR9Z432w1Qf-w@mail.gmail.com>
Message-ID: <CADB-E-t7CRKw3AivG0aA3AJ8WuhQxe8NzJfGSGEPyeK_BiCJ6w@mail.gmail.com>

Hi Assaf,

Thanks for that information. Let me check it again.

On Thu, Oct 1, 2015 at 1:36 AM, Assaf Muller <amuller at redhat.com> wrote:

>
>
> On Wed, Sep 30, 2015 at 3:18 PM, Geo Varghese <gvarghese at aqorn.com> wrote:
>
>> Hi Sinh,
>>
>> Thanks for the update.
>>
>> Its already started and showing up in command
>>
>> neutron agent list
>>
>> Not sure why the peer ports not created. Its created by plugin or
>> l3-agent?
>>
>> I am using ml2 plugin.
>>
>
> Restarting neutron-openvswitch-agent should re-create the patch ports.
> Restarting the 'openvswitch' service would be one explanation why
> the patch ports were deleted.
>
>
>>
>>
>> On Wed, Sep 30, 2015 at 11:51 PM, Sinh Lam <
>> sinh.lam at verizondigitalmedia.com> wrote:
>>
>>> can you make sure the openvswitch plugin is started?
>>>
>>> looks like the bridges were made but not the peer ports and as far as i
>>> can tell that is brought up when you start the plugin.
>>>
>>> let me know if that helps.
>>>
>>> sinh
>>>
>>>
>>> On Wed, Sep 30, 2015 at 6:59 AM, Geo Varghese <gvarghese at aqorn.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I need a help with following issue
>>>>
>>>> patch-int port is not created in br-tun. I am using kilo version of
>>>> openstack in ubuntu 14.04. It was working in icehouse ubuntu 12.04.
>>>>
>>>> Its not created in both controller and compute.
>>>>
>>>>
>>>> root at Node4:~/compute# ovs-vsctl show
>>>> c1e3a6e9-5a11-4160-8903-e09de64eaa4f
>>>>     Bridge br-tun
>>>>         Port br-tun
>>>>             Interface br-tun
>>>>                 type: internal
>>>>     Bridge br-int
>>>>         fail_mode: secure
>>>>         Port br-int
>>>>             Interface br-int
>>>>                 type: internal
>>>>     ovs_version: "2.3.2"
>>>>
>>>>
>>>> Guys, please give some inputs to fix this this issue. Is anything
>>>> specific needs to changed in any conf file?
>>>>
>>>> Thanks again for great support from the group.
>>>>
>>>>
>>>> --
>>>> --
>>>> Regards,
>>>> Geo Varghese
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>> Post to     : openstack at lists.openstack.org
>>>> Unsubscribe :
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>
>>>>
>>>
>>
>>
>> --
>> --
>> Regards,
>> Geo Varghese
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>


-- 
--
Regards,
Geo Varghese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151001/a9c1eafa/attachment.html>

From sorrison at gmail.com  Wed Sep 30 23:25:03 2015
From: sorrison at gmail.com (Sam Morrison)
Date: Thu, 1 Oct 2015 09:25:03 +1000
Subject: [Openstack-operators] Neutron DHCP failover bug
In-Reply-To: <etPan.560b7796.64d32ddf.c6dd@JODEWEY-M-D867>
References: <642F0BB6-3C55-48C6-9316-9900116129CF@gmail.com>
 <etPan.560b7796.64d32ddf.c6dd@JODEWEY-M-D867>
Message-ID: <2AFD6E95-A46E-4DC7-B94C-68F5149D81BF@gmail.com>


> On 30 Sep 2015, at 3:48 pm, John Dewey <john at dewey.ws> wrote:
> 
> Why not run neutron dhcp agents on both nodes? 

Yeah have tried this too.

We don?t do this due to metadata, DHCP adds a static route to the metadata agent (which is the same as the network node running DHCP). If the network node is down the instances loose metadata if they happened to get a lease from that DHCP server. With failover the IP address transfers to the other network node and metadata keeps working for all.

Make sense?

Sam


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151001/3900872c/attachment.html>

From gessau at cisco.com  Fri Sep 25 17:47:59 2015
From: gessau at cisco.com (Henry Gessau)
Date: Fri, 25 Sep 2015 17:47:59 -0000
Subject: [Openstack-operators] [neutron][horizon] Nice new Network Topology
	panel in Horizon
Message-ID: <560588CC.1040501@cisco.com>

It has been about three years in the making but now it is finally here.
A screenshot doesn't do it justice, so here is a short video overview:
https://youtu.be/PxFd-lJV0e4

Isn't that neat? I am sure you can see that it is a great improvement,
especially for larger topologies.

This new view will be part of the Liberty release of Horizon. I encourage you to
take a look at it with your own network topologies, play around with it, and
provide feedback. Please stop by the #openstack-horizon IRC channel if there are
issues you would like addressed.

Thanks to the folks who made this happen.