date:20160602

Re: [Openstack-operators] Uptime and SLA's

2016-06-02 Thread Melvin Hillsman

Really appreciate the feedback.

> On Jun 2, 2016, at 6:51 PM, Bak, Ryan M  wrote:
> 
> Melvin,
> 
> The Monasca wiki (https://wiki.openstack.org/wiki/Monasca) has a lot of 
> information on architecture, as well as links to several talks given at 
> summits over the past couple years.  That’s probably your best bet for 
> general information and understanding.  There isn’t any single install guide 
> that I’m aware of, but you can bring up a working Monasca stack in Devstack 
> (https://github.com/openstack/monasca-api/tree/master/devstack) and take a 
> look at that, and there is also a puppet module for Monasca setup available 
> here: https://github.com/openstack/puppet-monasca.  Even if you’re not using 
> puppet that will give you a sense of what you’ll need and how to set 
> everything up.
> 
> Monasca can definitely run in an HA configuration.  In production we run 
> three load balanced nodes in each region with the api stack (monasca-api, 
> monasca-persister, monasca-thresh, kafka and storm).  We also have a separate 
> cluster of nodes in each region running Vertica for our backend, and we use 
> Kafka to replicate the data across regions so that the data is global.  If 
> you want a diagram of our setup, you can find one in our talk from the Austin 
> summit 
> (https://www.youtube.com/watch?v=uBapdsOpND4&feature=youtu.be&t=17m53s).  
> Feel free to reach out here or on the Monasca IRC channel if you run into any 
> difficulties setting up Monasca, or have any other questions.
> 
> -Ryan Bak
> 
> From: Melvin Hillsman 
> Date: Thursday, June 2, 2016 at 4:58 PM
> To: Matt Fischer , "Kingshott, Daniel" 
> 
> Cc: OpenStack Operators 
> Subject: Re: [Openstack-operators] Uptime and SLA's
> Resent-From: Ryan Bak 
> 
> Hey Matt,
> 
> I am looking into Monasca and would like to know your recommendation for 
> resources regarding a) understanding and b) installing the project; 
> especially since there is no install guide on the project wiki. Additionally, 
> can you shed some light on whether this setup would run behind a loadbalancer 
> in an HA configuration; I am looking at using three servers which will house 
> a “stack”/“toolchain” for such activities.
> 
> Kind regards,
> --
> Melvin Hillsman
> Ops Technical Lead
> OpenStack Innovation Center
> mrhills...@gmail.com
> phone: (210) 312-1267
> mobile: (210) 413-1659
> Learner | Ideation | Belief | Responsibility | Command
> http://osic.org
> 
> From: Matt Fischer
> Date: Thursday, June 2, 2016 at 5:29 PM
> To: "Kingshott, Daniel"
> Cc: OpenStack Operators
> Subject: Re: [Openstack-operators] Uptime and SLA's
> 
> We do this a few different ways, some of which may meet your needs.
> 
> For API calls we measure a simple, quick, and impactless call for each 
> service (like heat stack-list) and we monitor East from West and vice versa. 
> The goal here is nothing added to the DBs, so nothing like neutron 
> net-create. The downside here is that some of these calls work even when the 
> service isn't 100% healthy so keep that in mind.
> 
> Then we also have a set of "what would a user do" calls like "spin up a VM 
> and attach a FIP and ssh in" or "create and delete a volume". These run less 
> often. 
> 
> Finally we have a reference cloud application that uses our LBaaS, GSLB, HA 
> routers, and multiple front-end/back-end nodes. This has the highest 
> expectation of uptime and is used as an example for our customers of how you 
> can run an app with "more nines" than the underlying infra.
> 
> On any of these, especially the first two I mentioned, time series data is 
> super useful. It's good to know that your create volume times (for example) 
> are 40% slower after your deploy. We use Monasca and Grafana for that.
> 
> 
>> On Thu, Jun 2, 2016 at 2:37 PM, Kingshott, Daniel 
>>  wrote:
>> We¹re currently in the process of writing up an internal SLA for our
>> openstack cloud, I¹d be interested to hear what others have done and what
>> metrics folks are capturing.
>> 
>> My initial thoughts are success / fail spawning instances, creating and
>> attaching volumes, API availability and so on.
>> 
>> Can anyone on the list share their insights?
>> 
>> Thanks,
>> 
>> Dan
>> 
>> 
>> Daniel Kingshott
>> Cloud Dude
>> (425) 623 4359 - Cell
>> 
>> Best Buy Co. Inc.
>> Technology Development Center
>> 1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> ___ OpenStack-operators mailing 
> list OpenStack-operators@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Uptime and SLA's

2016-06-02 Thread Kingshott, Daniel

Thank you for your responses, I appreciate the insight.

Dan

Daniel Kingshott
Cloud Dude
(425) 623 4359 - Cell
 
Best Buy Co. Inc.
Technology Development Center
1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA





From:  "Bak, Ryan M" 
Date:  Thursday, June 2, 2016 at 4:51 PM
To:  Melvin Hillsman , Matt Fischer
, "Kingshott, Daniel" 
Cc:  OpenStack Operators 
Subject:  Re: [Openstack-operators] Uptime and SLA's


Melvin,

The Monasca wiki (https://wiki.openstack.org/wiki/Monasca) has a lot of
information on architecture, as well as links to several talks given at
summits over the past couple years.  That’s probably your
 best bet for general information and understanding.  There isn’t any
single install guide that I’m aware of, but you can bring up a working
Monasca stack in Devstack
(https://github.com/openstack/monasca-api/tree/master/devstack)
 and take a look at that, and there is also a puppet module for Monasca
setup available here: https://github.com/openstack/puppet-monasca.  Even
if you’re not using puppet that will give you a sense
 of what you’ll need and how to set everything up.

Monasca can definitely run in an HA configuration.  In production we run
three load balanced nodes in each region with the api stack (monasca-api,
monasca-persister, monasca-thresh, kafka and storm).  We also have a
separate cluster of nodes in each region
 running Vertica for our backend, and we use Kafka to replicate the data
across regions so that the data is global.  If you want a diagram of our
setup, you can find one in our talk from the Austin summit
(https://www.youtube.com/watch?v=uBapdsOpND4&feature=youtu.be&t=17m53s).
  Feel free to reach out here or on the Monasca IRC channel if you run
into any difficulties setting up Monasca, or have any other questions.

-Ryan Bak

From: Melvin Hillsman 
Date: Thursday, June 2, 2016 at 4:58 PM
To: Matt Fischer , "Kingshott, Daniel"

Cc: OpenStack Operators 
Subject: Re: [Openstack-operators] Uptime and SLA's
Resent-From: Ryan Bak 


Hey Matt,

I am looking into Monasca and would like to know your recommendation for
resources regarding a) understanding and b) installing the project;
especially since there is no install guide on the project wiki.
Additionally, can you shed some light on whether
 this setup would run behind a loadbalancer in an HA configuration; I am
looking at using three servers which will house a “stack”/“toolchain” for
such activities.

Kind regards,
--
Melvin HillsmanOps Technical Lead
OpenStack Innovation centermrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Commandhttp://osic.org






From: Matt Fischer
Date: Thursday, June 2, 2016 at 5:29 PM
To: "Kingshott, Daniel"
Cc: OpenStack Operators
Subject: Re: [Openstack-operators] Uptime and SLA's


We do this a few different ways, some of which may meet your needs.

For API calls we measure a simple, quick, and impactless call for each
service (like heat stack-list) and we monitor East from West and vice
versa. The goal here is nothing added to the DBs, so nothing like neutron
net-create. The downside here is that
 some of these calls work even when the service isn't 100% healthy so keep
that in mind.

Then we also have a set of "what would a user do" calls like "spin up a VM
and attach a FIP and ssh in" or "create and delete a volume". These run
less often. 

Finally we have a reference cloud application that uses our LBaaS, GSLB,
HA routers, and multiple front-end/back-end nodes. This has the highest
expectation of uptime and is used as an example for our customers of how
you can run an app with "more nines"
 than the underlying infra.

On any of these, especially the first two I mentioned, time series data is
super useful. It's good to know that your create volume times (for
example) are 40% slower after your deploy. We use Monasca and Grafana for
that.



On Thu, Jun 2, 2016 at 2:37 PM, Kingshott, Daniel
 wrote:

We¹re currently in the process of writing up an internal SLA for our
openstack cloud, I¹d be interested to hear what others have done and what
metrics folks are capturing.

My initial thoughts are success / fail spawning instances, creating and
attaching volumes, API availability and so on.

Can anyone on the list share their insights?

Thanks,

Dan


Daniel Kingshott
Cloud Dude
(425) 623 4359  - Cell

Best Buy Co. Inc.
Technology Development Center
1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA


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





___ OpenStack-operators
mailing list 
OpenStack-operators@lists.openstack.org

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

___

Re: [Openstack-operators] problem with DVR in Kilo and floating IPs

2016-06-02 Thread Daniel Russell

Hi,

We have seen this kind of behaviour and it was because the qrouter had the 
following rules :

-A neutron-postrouting-bottom -m comment --comment "Perform source NAT on 
outgoing traffic." -j neutron-l3-agent-snat
-A neutron-l3-agent-snat -j neutron-l3-agent-float-snat
-A neutron-l3-agent-float-snat -s /32 -j SNAT --to-source 


That meant that whenever traffic wasn’t going between instances in the same 
network (ie. Had to go through the router), it would NAT it to the floating IP 
even if the other server was in a directly connected network.

To see if this is happening for you, you could try adding a rule in your 
security groups to allow VM1s floating IP to access VM2 and/or vice versa.  You 
could also do a tcpdump on the router’s interfaces to the networks to see if 
you are getting some translation issues.

Regards,
Dan.


From: Gustavo Randich [mailto:gustavo.rand...@gmail.com]
Sent: Friday, 3 June 2016 7:40 AM
To: openstack-operators@lists.openstack.org; openst...@lists.openstack.org
Subject: [Openstack-operators] problem with DVR in Kilo and floating IPs

Hi,

Using DVR in Kilo, I've the following issue:

- VM1 is in tenant network 1 (fixed IP 10.97.2.4)
- VM2 is in tenant network 2 (fixed IP 10.97.0.4)
- a router connects both networks
- VM1 and VM2 both have floating IPs
- I can ping from VM1 to VM2 using fixed / internal IP
- I cannot SSH from VM1 to VM2 using fixed IP, because of 
"ssh_exchange_identification: read: Connection reset by peer"
- iperf output between both VMs using fixed IP is strange (see below)

If I remove floating IP in VM2 (target VM), SSH and iperf begin to work OK

The problem is not present with two VM1 in the *same* tenant network and both 
having floating IPs

Any ideas?

Thanks!




VM1# tracepath 10.97.0.4
 1?: [LOCALHOST] pmtu 1500
 1:  10.97.2.1 0.322ms
 1:  10.97.2.1 0.436ms
 2:  10.97.0.4 0.962ms reached
 Resume: pmtu 1500 hops 2 back 4

VM1# ping 10.97.0.4
PING 10.97.0.4 (10.97.0.4) 56(84) bytes of data.
64 bytes from 10.97.0.4: icmp_seq=1 ttl=61 time=1.23 ms
^C
--- 10.97.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.231/1.231/1.231/0.000 ms

VM1# ssh 10.97.0.4
ssh_exchange_identification: read: Connection reset by peer

VM1# iperf -c 10.97.0.4

Client connecting to 10.97.0.4, TCP port 5001
TCP window size: 85.0 KByte (default)

[  3] local 10.97.2.4 port 47014 connected with 10.97.0.4 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  0.00 ▒ ▒▒s  14746824734997131264 Bytes/sec





VM2# # iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[  4] local 10.97.0.4 port 5001 connected with 10.182.0.58 port 47014
[ ID] Interval   Transfer Bandwidth
[  4]  0.0- 0.0 sec  14.1 KBytes  9.36 Mbits/sec

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

Re: [Openstack-operators] problem with DVR in Kilo and floating IPs

2016-06-02 Thread Daniel Russell

Hi,

We have seen this kind of behaviour and it was because the qrouter had the 
following rules :

-A neutron-postrouting-bottom -m comment --comment "Perform source NAT on 
outgoing traffic." -j neutron-l3-agent-snat
-A neutron-l3-agent-snat -j neutron-l3-agent-float-snat
-A neutron-l3-agent-float-snat -s /32 -j SNAT --to-source 


That meant that whenever traffic wasn’t going between instances in the same 
network (ie. Had to go through the router), it would NAT it to the floating IP 
even if the other server was in a directly connected network.

To see if this is happening for you, you could try adding a rule in your 
security groups to allow VM1s floating IP to access VM2 and/or vice versa.  You 
could also do a tcpdump on the router’s interfaces to the networks to see if 
you are getting some translation issues.

Regards,
Dan.

From: Gustavo Randich [mailto:gustavo.rand...@gmail.com]
Sent: Friday, 3 June 2016 7:40 AM
To: openstack-operators@lists.openstack.org; openst...@lists.openstack.org
Subject: [Openstack-operators] problem with DVR in Kilo and floating IPs

Hi,

Using DVR in Kilo, I've the following issue:

- VM1 is in tenant network 1 (fixed IP 10.97.2.4)
- VM2 is in tenant network 2 (fixed IP 10.97.0.4)
- a router connects both networks
- VM1 and VM2 both have floating IPs
- I can ping from VM1 to VM2 using fixed / internal IP
- I cannot SSH from VM1 to VM2 using fixed IP, because of 
"ssh_exchange_identification: read: Connection reset by peer"
- iperf output between both VMs using fixed IP is strange (see below)

If I remove floating IP in VM2 (target VM), SSH and iperf begin to work OK

The problem is not present with two VM1 in the *same* tenant network and both 
having floating IPs

Any ideas?

Thanks!




VM1# tracepath 10.97.0.4
 1?: [LOCALHOST] pmtu 1500
 1:  10.97.2.1 0.322ms
 1:  10.97.2.1 0.436ms
 2:  10.97.0.4 0.962ms reached
 Resume: pmtu 1500 hops 2 back 4

VM1# ping 10.97.0.4
PING 10.97.0.4 (10.97.0.4) 56(84) bytes of data.
64 bytes from 10.97.0.4: icmp_seq=1 ttl=61 time=1.23 ms
^C
--- 10.97.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.231/1.231/1.231/0.000 ms

VM1# ssh 10.97.0.4
ssh_exchange_identification: read: Connection reset by peer

VM1# iperf -c 10.97.0.4

Client connecting to 10.97.0.4, TCP port 5001
TCP window size: 85.0 KByte (default)

[  3] local 10.97.2.4 port 47014 connected with 10.97.0.4 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  0.00 ▒ ▒▒s  14746824734997131264 Bytes/sec





VM2# # iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[  4] local 10.97.0.4 port 5001 connected with 10.182.0.58 port 47014
[ ID] Interval   Transfer Bandwidth
[  4]  0.0- 0.0 sec  14.1 KBytes  9.36 Mbits/sec

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

[Openstack-operators] oslo_messaging, rabbit, ssl and mitaka and xenial

2016-06-02 Thread Sam Morrison

Hi all,

We’ve been trying out some mitaka packages as well as some Xenial hosts and 
have been having some issues with rabbit and SSL.

If using rabbitMQ 3.6.x on Trusty I can’t get a mitaka host (oslo_messaging 
4.6.1, python-amqp 1.4.9) to connect to rabbit over SSL. 

If I use rabbitMQ 3.6.x on Xenial I can get it to work BUT I need to change 
some settings on rabbit to allow some weaker ciphers.

I had to add the following to rabbitmq.config (found on some random blog and 
haven’t investigated what exactly needed to change sorry)

{versions, ['tlsv1.2', 'tlsv1.1', tlsv1]},
{ciphers, 
["ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384",
   
"ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384", 
"ECDHE-ECDSA-DES-CBC3-SHA",
   
"ECDH-ECDSA-AES256-GCM-SHA384","ECDH-RSA-AES256-GCM-SHA384","ECDH-ECDSA-AES256-SHA384",
   
"ECDH-RSA-AES256-SHA384","DHE-DSS-AES256-GCM-SHA384","DHE-DSS-AES256-SHA256",
   
"AES256-GCM-SHA384","AES256-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256",
   
"ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-SHA256","ECDHE-RSA-AES128-SHA256",
   
"ECDH-ECDSA-AES128-GCM-SHA256","ECDH-RSA-AES128-GCM-SHA256","ECDH-ECDSA-AES128-SHA256",
   
"ECDH-RSA-AES128-SHA256","DHE-DSS-AES128-GCM-SHA256","DHE-DSS-AES128-SHA256",
   
"AES128-GCM-SHA256","AES128-SHA256","ECDHE-ECDSA-AES256-SHA",
   
"ECDHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA","ECDH-ECDSA-AES256-SHA",
   
"ECDH-RSA-AES256-SHA","AES256-SHA","ECDHE-ECDSA-AES128-SHA",
   
"ECDHE-RSA-AES128-SHA","DHE-DSS-AES128-SHA","ECDH-ECDSA-AES128-SHA",
   "ECDH-RSA-AES128-SHA","AES128-SHA"]},
{honor_cipher_order, true},


Is anyone else had a play with this and got it working where a mitaka host can 
talk to a rabbitmq server running on trusty?
The version or erlang is the difference here and I’m pretty sure that is where 
the change is.

Cheers,
Sam


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

Re: [Openstack-operators] Uptime and SLA's

2016-06-02 Thread Melvin Hillsman

Hey Matt,

I am looking into Monasca and would like to know your recommendation for 
resources regarding a) understanding and b) installing the project; especially 
since there is no install guide on the project wiki. Additionally, can you shed 
some light on whether this setup would run behind a loadbalancer in an HA 
configuration; I am looking at using three servers which will house a 
“stack”/“toolchain” for such activities.

Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center
mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org

From:  Matt Fischer
Date:  Thursday, June 2, 2016 at 5:29 PM
To:  "Kingshott, Daniel"
Cc:  OpenStack Operators
Subject:  Re: [Openstack-operators] Uptime and SLA's

We do this a few different ways, some of which may meet your needs.

For API calls we measure a simple, quick, and impactless call for each service 
(like heat stack-list) and we monitor East from West and vice versa. The goal 
here is nothing added to the DBs, so nothing like neutron net-create. The 
downside here is that some of these calls work even when the service isn't 100% 
healthy so keep that in mind.

Then we also have a set of "what would a user do" calls like "spin up a VM and 
attach a FIP and ssh in" or "create and delete a volume". These run less often. 

Finally we have a reference cloud application that uses our LBaaS, GSLB, HA 
routers, and multiple front-end/back-end nodes. This has the highest 
expectation of uptime and is used as an example for our customers of how you 
can run an app with "more nines" than the underlying infra.

On any of these, especially the first two I mentioned, time series data is 
super useful. It's good to know that your create volume times (for example) are 
40% slower after your deploy. We use Monasca and Grafana for that.


On Thu, Jun 2, 2016 at 2:37 PM, Kingshott, Daniel 
 wrote:
We¹re currently in the process of writing up an internal SLA for our
openstack cloud, I¹d be interested to hear what others have done and what
metrics folks are capturing.

My initial thoughts are success / fail spawning instances, creating and
attaching volumes, API availability and so on.

Can anyone on the list share their insights?

Thanks,

Dan


Daniel Kingshott
Cloud Dude
(425) 623 4359 - Cell

Best Buy Co. Inc.
Technology Development Center
1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA


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

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

Re: [Openstack-operators] Uptime and SLA's

2016-06-02 Thread Matt Fischer

We do this a few different ways, some of which may meet your needs.

For API calls we measure a simple, quick, and impactless call for each
service (like heat stack-list) and we monitor East from West and vice
versa. The goal here is nothing added to the DBs, so nothing like neutron
net-create. The downside here is that some of these calls work even when
the service isn't 100% healthy so keep that in mind.

Then we also have a set of "what would a user do" calls like "spin up a VM
and attach a FIP and ssh in" or "create and delete a volume". These run
less often.

Finally we have a reference cloud application that uses our LBaaS, GSLB, HA
routers, and multiple front-end/back-end nodes. This has the highest
expectation of uptime and is used as an example for our customers of how
you can run an app with "more nines" than the underlying infra.

On any of these, especially the first two I mentioned, time series data is
super useful. It's good to know that your create volume times (for example)
are 40% slower after your deploy. We use Monasca and Grafana for that.

On Thu, Jun 2, 2016 at 2:37 PM, Kingshott, Daniel <
daniel.kingsh...@bestbuy.com> wrote:

> We¹re currently in the process of writing up an internal SLA for our
> openstack cloud, I¹d be interested to hear what others have done and what
> metrics folks are capturing.
>
> My initial thoughts are success / fail spawning instances, creating and
> attaching volumes, API availability and so on.
>
> Can anyone on the list share their insights?
>
> Thanks,
>
> Dan
>
>
> Daniel Kingshott
> Cloud Dude
> (425) 623 4359 - Cell
>
> Best Buy Co. Inc.
> Technology Development Center
> 1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] problem with DVR in Kilo and floating IPs

2016-06-02 Thread Gustavo Randich

Hi,

Using DVR in Kilo, I've the following issue:

- VM1 is in tenant network 1 (fixed IP 10.97.2.4)
- VM2 is in tenant network 2 (fixed IP 10.97.0.4)
- a router connects both networks
- VM1 and VM2 both have floating IPs
- I can ping from VM1 to VM2 using fixed / internal IP
- I cannot SSH from VM1 to VM2 using fixed IP, because of
"ssh_exchange_identification: read: Connection reset by peer"
- iperf output between both VMs using fixed IP is strange (see below)


If I remove floating IP in VM2 (target VM), SSH and iperf begin to work OK

The problem is not present with two VM1 in the *same* tenant network and
both having floating IPs

Any ideas?

Thanks!





VM1# tracepath 10.97.0.4
 1?: [LOCALHOST] pmtu 1500
 1:  10.97.2.1 0.322ms
 1:  10.97.2.1 0.436ms
 2:  10.97.0.4 0.962ms reached
 Resume: pmtu 1500 hops 2 back 4

VM1# ping 10.97.0.4
PING 10.97.0.4 (10.97.0.4) 56(84) bytes of data.
64 bytes from 10.97.0.4: icmp_seq=1 ttl=61 time=1.23 ms
^C
--- 10.97.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.231/1.231/1.231/0.000 ms

VM1# ssh 10.97.0.4
ssh_exchange_identification: read: Connection reset by peer

VM1# iperf -c 10.97.0.4

Client connecting to 10.97.0.4, TCP port 5001
TCP window size: 85.0 KByte (default)

[  3] local 10.97.2.4 port 47014 connected with 10.97.0.4 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  0.00 ▒ ▒▒s  14746824734997131264 Bytes/sec





VM2# # iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

[  4] local 10.97.0.4 port 5001 connected with 10.182.0.58 port 47014
[ ID] Interval   Transfer Bandwidth
[  4]  0.0- 0.0 sec  14.1 KBytes  9.36 Mbits/sec
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

2016-06-02 Thread Edgar Magana

Hello,

I think we need to increase the cap for real operators and not vendors but I 
have not attended the Ops meetups WG meetings so I do not know all the context 
about it.

BTW. DO we have a place and date for the next mid-cycle one?

Edgar

On 6/2/16, 1:16 PM, "Melvin Hillsman"  wrote:

>Apologies,
>
>* On a side note, can we decide on a [email-subject-tag] to help filter these 
>in [Openstack-operators]
>* Suggestion: [ops-meetups-team]
>
>For the delay that is since rain and Houston, TX fight a lot and rain is 
>winning these days unfortunately. I was tasked with submitting to the ML a 
>request to discuss how do we handle the waiting list for those who are not 
>able to attend the Ops Midcycle due to the cap. Looking at EventBrite [ 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eventbrite.com_support_articles_en-5FUS_How-5FTo_how-2Dto-2Dset-2Dup-2Dan-2Devent-2Dwaitlist-3Flg-3Den-5FUS&d=CwIGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng&s=nw_xXhA2xGfTOF5BCsJDlFzdMK7SbxZIyNcY0HqN0Bg&e=
>  ] if we are going to do a waitlist, this looks like a great option where 
>basically we get details about the attendees we need and the waitlist is 
>automatically created once the cap is hit.
>
>Playing devil’s advocate, my only apprehension to this process is should the 
>waitlist be large, and there is a significant reason for someone who attended 
>a previous Ops Midcycle to need to attend the next, how would that be handled? 
>I am sure there are other potential issues that can be identified.
>
>Kind regards,
>--
>Melvin Hillsman
>Ops Technical Lead
>OpenStack Innovation Center 
>mrhills...@gmail.com
>phone: (210) 312-1267
>mobile: (210) 413-1659
>Learner | Ideation | Belief | Responsibility | Command
>https://urldefense.proofpoint.com/v2/url?u=http-3A__osic.org&d=CwIGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng&s=pu6FOfWP0tAP8vf2pfzIrBPY1jdEnfIjOcI4ZUUA5dU&e=
> 
>
>
>
>
>
>
>
>On 6/1/16, 11:33 PM, "Tom Fifield"  wrote:
>
>>Hello all,
>>
>>Thank you very much to the dozen of you who participated in our second 
>>meeting. We had some fantastic discussion, summarised below (the meeting 
>>overview can be found at [3] and the full log at [4]).
>>
>>
>>==Next Meeting==
>>Unless there is further discussion, this the next meeting is at:
>>
>>==> Tuesday, 14 of Jun at 1400 UTC[1] in #openstack-operators
>>
>>[2] will be kept up to date with information about the meeting time and 
>>agenda
>>
>>
>>==August Meetup==
>>Since there really isn't a lot of time left and we have proposals 
>>already, we decided for this time we would not do the open call.
>>So, gfa, shintano and I will be working behind the scenes with Bestbuy 
>>(Seattle) and Bloomberg (NYC) a little bit to get further details on 
>>their venues - we will report to the group as soon as we have some 
>>progress so we can make a decision for the August meetup.
>>
>>
>>
>>==Meetup size==
>>We had a great discussion on meetup size and it's looking like 150-200 
>>is the proposal, please participate in Matt Jarvis' thread at:
>>
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_pipermail_openstack-2Doperators_2016-2DJune_010607.html&d=CwIGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng&s=x-Ny3jYrVkAxC5Ma-R7qRPQaTq_j3-TL5AF1WT6Z-48&e=
>> 
>>
>>
>>
>>
>>==Waitlist management==
>>There was a good proposal on how to manage the waitlist (give those that 
>>missed out first go at the next one). mrhillsman will write that up and 
>>send it through to the list shortly.
>>
>>
>>
>>
>>Regards,
>>
>>
>>Tom
>>
>>
>>[1] 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.timeanddate.com_worldclock_fixedtime.html-3Fmsg-3DOps-2BMeetups-2BTeam-26iso-3D20160614T22-26p1-3D241&d=CwIGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng&s=_tbRGlaHlXJZc78QnSYGEx_TAvFkkpOAswKsr6wnUQA&e=
>> 
>>
>>[2] 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Ops-5FMeetups-5FTeam-23Meeting-5FInformation&d=CwIGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng&s=3GqOnGDbijK8PjA-WRrrZdpx5PavL8UmOBJ4E6izO0M&e=
>> 
>>
>>[3] 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__eavesdrop.openstack.org_meetings_ops-5Fmeetups-5Fteam_2016_ops-5Fmeetups-5Fteam.2016-2D05-2D31-2D14.01.html&d=CwIGaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=Izi115xT_K7kOrj3J8Dp44KcJDfJFyu8Tb_oYoroJng&s=WbHrH47xBUdxEDDBapu5uqcHGEur4HZBdORgXqXIPMY&e=
>> 
>>
>>[4] 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__eavesdrop.openstack.org_meetings_

[Openstack-operators] Uptime and SLA's

2016-06-02 Thread Kingshott, Daniel

We¹re currently in the process of writing up an internal SLA for our
openstack cloud, I¹d be interested to hear what others have done and what
metrics folks are capturing.

My initial thoughts are success / fail spawning instances, creating and
attaching volumes, API availability and so on.

Can anyone on the list share their insights?

Thanks,

Dan


Daniel Kingshott
Cloud Dude
(425) 623 4359 - Cell
 
Best Buy Co. Inc.
Technology Development Center
1000 Denny Way | 8th Floor | Seattle, WA | 98109 | USA


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

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

2016-06-02 Thread Melvin Hillsman

Apologies,

* On a side note, can we decide on a [email-subject-tag] to help filter these 
in [Openstack-operators]
* Suggestion: [ops-meetups-team]

For the delay that is since rain and Houston, TX fight a lot and rain is 
winning these days unfortunately. I was tasked with submitting to the ML a 
request to discuss how do we handle the waiting list for those who are not able 
to attend the Ops Midcycle due to the cap. Looking at EventBrite [ 
https://www.eventbrite.com/support/articles/en_US/How_To/how-to-set-up-an-event-waitlist?lg=en_US
 ] if we are going to do a waitlist, this looks like a great option where 
basically we get details about the attendees we need and the waitlist is 
automatically created once the cap is hit.

Playing devil’s advocate, my only apprehension to this process is should the 
waitlist be large, and there is a significant reason for someone who attended a 
previous Ops Midcycle to need to attend the next, how would that be handled? I 
am sure there are other potential issues that can be identified.

Kind regards,
--
Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center 
mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
Learner | Ideation | Belief | Responsibility | Command
http://osic.org







On 6/1/16, 11:33 PM, "Tom Fifield"  wrote:

>Hello all,
>
>Thank you very much to the dozen of you who participated in our second 
>meeting. We had some fantastic discussion, summarised below (the meeting 
>overview can be found at [3] and the full log at [4]).
>
>
>==Next Meeting==
>Unless there is further discussion, this the next meeting is at:
>
>==> Tuesday, 14 of Jun at 1400 UTC[1] in #openstack-operators
>
>[2] will be kept up to date with information about the meeting time and 
>agenda
>
>
>==August Meetup==
>Since there really isn't a lot of time left and we have proposals 
>already, we decided for this time we would not do the open call.
>So, gfa, shintano and I will be working behind the scenes with Bestbuy 
>(Seattle) and Bloomberg (NYC) a little bit to get further details on 
>their venues - we will report to the group as soon as we have some 
>progress so we can make a decision for the August meetup.
>
>
>
>==Meetup size==
>We had a great discussion on meetup size and it's looking like 150-200 
>is the proposal, please participate in Matt Jarvis' thread at:
>
>http://lists.openstack.org/pipermail/openstack-operators/2016-June/010607.html
>
>
>
>
>==Waitlist management==
>There was a good proposal on how to manage the waitlist (give those that 
>missed out first go at the next one). mrhillsman will write that up and 
>send it through to the list shortly.
>
>
>
>
>Regards,
>
>
>Tom
>
>
>[1] 
>http://www.timeanddate.com/worldclock/fixedtime.html?msg=Ops+Meetups+Team&iso=20160614T22&p1=241
>
>[2] https://wiki.openstack.org/wiki/Ops_Meetups_Team#Meeting_Information
>
>[3] 
>http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-05-31-14.01.html
>
>[4] 
>http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-05-31-14.01.log.html
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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

Re: [Openstack-operators] [User-committee] [recognition] AUC Recognition WG Meeting Today (6/2/16)

2016-06-02 Thread Matt Jarvis

+1 :)

On 2 June 2016 at 17:40, Edgar Magana  wrote:

> I love to see the AUC instead of the Non-ATC one!!!  Kudos!
>
>
>
> Edgar
>
>
>
> *From: *Shamail Tahir 
> *Date: *Thursday, June 2, 2016 at 9:23 AM
> *To: *openstack-operators ,
> user-committee 
> *Subject: *[Openstack-operators] [recognition] AUC Recognition WG Meeting
> Today (6/2/16)
>
>
>
> Hi everyone,
>
>
>
> The AUC (Active User Contributor) Recognition WG will be meeting today and
> the agenda has been posted on our wiki[1].
>
>
>
> Meeting information:
>
> Date: 6/2
>
> Time: 1900 UTC
>
> IRC Channel: #openstack-meeting-3
>
>
>
> [1] *https://wiki.openstack.org/wiki/AUCRecognition#Meeting_Information
> *
>
>
>
> --
>
> Thanks,
>
> Shamail Tahir
>
> t: @ShamailXD
>
> tz: Eastern Time
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [recognition] AUC Recognition WG Meeting Today (6/2/16)

2016-06-02 Thread Edgar Magana

I love to see the AUC instead of the Non-ATC one!!!  Kudos!

Edgar

From: Shamail Tahir 
Date: Thursday, June 2, 2016 at 9:23 AM
To: openstack-operators , 
user-committee 
Subject: [Openstack-operators] [recognition] AUC Recognition WG Meeting Today 
(6/2/16)

Hi everyone,


The AUC (Active User Contributor) Recognition WG will be meeting today and the 
agenda has been posted on our wiki[1].


Meeting information:
Date: 6/2
Time: 1900 UTC
IRC Channel: #openstack-meeting-3


[1] 
https://wiki.openstack.org/wiki/AUCRecognition#Meeting_Information

--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [recognition] AUC Recognition WG Meeting Today (6/2/16)

2016-06-02 Thread Shamail Tahir

Hi everyone,

The AUC (Active User Contributor) Recognition WG will be meeting today and
the agenda has been posted on our wiki[1].

Meeting information:
Date: 6/2
Time: 1900 UTC
IRC Channel: #openstack-meeting-3

[1] *https://wiki.openstack.org/wiki/AUCRecognition#Meeting_Information
*

-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Collecting our wiki use cases

2016-06-02 Thread Thierry Carrez


Thanks to everyone who helped collecting wiki use cases on that etherpad.

I tried to categorize the various use cases and I think they fit in 4 
categories:


1/ Things that are already in the process of being moved to reference 
websites or documentation


That would be the main "portal" page with its links to all the other 
websites, the 'How To Contribute' stuff, the information about 
elections, release naming, User committee governance...


2/ Things that should probably be published elsewhere

Sprints, IRC channels, Mailing lists, Board meeting information, 
Successbot & Statusbot logging pages...


3/ "Cheap websites" for teams, working groups and some events

That is the bulk of the remaining use cases. The wiki makes for an easy 
and immediate way to publish information about a specific team or 
working group, including specific processes, self-service team signup, 
additional meeting information... They also work well as quick-and-basic 
websites for community-led events like the Design Summit or Ops Meetups.


4/ "Etherpad on steroids" - ephemeral slightly richer documents

...where the wiki is used for building very ephemeral documents like 
meeting agendas, newsletter drafts, sharing pictures



While I think we should continue the effort on (1) and (2), we need a 
long-term wiki-like solution for (3).


One interesting aspect of (3) is that all of the content there is 
clearly linked to a team of people. So it could easily be that team's 
duty to keep those pages limited in number and updated, reducing the 
nasty side-effects of stale pages. If the tool supports it, teams could 
use ACLs and/or have to vet the creation of new pages under their 
ownership, reducing the spam aspect. One issue with MediaWiki (compared 
to some other wikis or light publication platforms) is that it's 
essentially flat, so this "ownership" concept (which helps with keeping 
spam and staleness under control) is not really baked in.


That leaves (4), where using the wiki leads to stale pages with no real 
author or maintainer being returned in Google searches. I'd argue that 
unless the document is clearly owned by a team, permanent and maintained 
up to date, the wiki should not be used. We have etherpads, we have 
pastebins, we could add others similar tools if those are not sufficient 
as ephemeral collaborative scratchpads. If we keep that category under a 
wiki-like platform, that should at least be under some /tmp special 
category that we would clean up aggressively.



Another learning of this exercise is that while some teams definitely 
rely on the wiki, we have a finite number of cases to handle. So a rip 
and replace approach is not completely out of question, if we find a 
better tool and decide that selective content-copy is cleaner and faster 
than general cleanup + bulk migration.


For the immediate future (Newton) we'll likely focus on completing (1), 
find solutions for (2), and research potential tools for (3) and (4).


Thanks again for the feedback!

--
Thierry Carrez (ttx)

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

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

2016-06-02 Thread Sean Dague

On 05/23/2016 10:24 AM, Tim Bell wrote:
>  
> 
> Quick warning for those who are dependent on the "user_id:%(user_id)s"
> syntax for limiting actions by user. According to 
> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
> apparently not intended according to the bug report feedback. The
> behavior has changed from v2 to v2.1 and the old syntax no longer works.
> 
>  
> 
> There can be security implications also so I’d recommend those using
> this current v2 feature to review the bug to understand the potential
> impacts as clouds enable v2.1.

Here is the proposed nova-spec on limited changes we're considering
bringing back in. The setup language is flowery, because I was in a
flowery mood yesterday. :)

Comments are welcomed there - https://review.openstack.org/#/c/324068/

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [Openstack-operators] Uptime and SLA's

Re: [Openstack-operators] Uptime and SLA's

Re: [Openstack-operators] problem with DVR in Kilo and floating IPs

Re: [Openstack-operators] problem with DVR in Kilo and floating IPs

[Openstack-operators] oslo_messaging, rabbit, ssl and mitaka and xenial

Re: [Openstack-operators] Uptime and SLA's

Re: [Openstack-operators] Uptime and SLA's

[Openstack-operators] problem with DVR in Kilo and floating IPs

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

[Openstack-operators] Uptime and SLA's

Re: [Openstack-operators] Ops Meetups Team - Next Meeting Coordinates and News

Re: [Openstack-operators] [User-committee] [recognition] AUC Recognition WG Meeting Today (6/2/16)

Re: [Openstack-operators] [recognition] AUC Recognition WG Meeting Today (6/2/16)

[Openstack-operators] [recognition] AUC Recognition WG Meeting Today (6/2/16)

Re: [Openstack-operators] Collecting our wiki use cases

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

16 matches

Site Navigation

Mail list logo

Footer information