[Openstack-operators] Handling VM launch constraints from flavor/extra-specs and image properties

[Bhandaru, Malini K]

Hello OpenStack Operators!

Traditionally flavors are defined with additional properties specified on the 
extra specs. Our understanding is that there will typically be a few of these 
are billing denominations.

Image providers often time have hints, and sometime constraints on how to 
deploy the image, perhaps to optimize performance and in other cases meet some 
regulatory requirements.

When the flavor does not mention a property but an image does, how should it be 
resolved?
When both flavor and image specify a property, the flavor would take precedence.

We have a Nova blueprint that is a little stuck without your valued input.  
Please weigh in.
https://review.openstack.org/#/c/138937/

Regards
Malini


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

Re: [Openstack-operators] EXT4 as ephemeral disk

[Abel Lopez]

I was always a little bugged by that. Like, if you attach a new cinder volume, 
you have to 'newfs' it (Really showing my age there)
but if you have ephemeral disk, it already has a filesystem. I agree with 
Clint's latest comment that maybe the ephemeral disk should not have an FS 
already.

> On Jan 12, 2015, at 12:04 PM, Davanum Srinivas  wrote:
> 
> Hi,
> 
> Here's the original "bug" filed against Nova:
> https://bugs.launchpad.net/nova/+bug/1266262
> 
> There has been a lot of traffic on the mailing lists in the past and
> review churns on this topic:
> http://bit.ly/ext4-ephemeral
> 
> Based on the last thread, there are 2 reviews in progress:
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1266262,n,z
> 
> And the Nova core team suggested adding a blueprint (in the last Nova meeting)
> https://blueprints.launchpad.net/nova/+spec/ext4-as-ephemeral-disk
> 
> Please take a look to see if the changes in progress will work in your
> environment(s) and let us know
> 
> thanks,
> dims
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> ___
> 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] [Keystone] LDAP Identity Use Survey

[Morgan Fainberg]

The Keystone development team is looking for deployment feedback regarding the 
use of the LDAP Identity backend. The Identity backend only covers Users and 
Groups.

We are looking to get an idea of types (read-only, read-write, etc) and reasons 
for use of the LDAP backend. The answers to this survey will help us to 
prioritize updates, changes, and set direction for the the LDAP Identity 
backend.

http://goo.gl/forms/bzZT5KGqkv 

This survey is only meant to get information on the use of the LDAP Identity 
backend. Identity only contains User and Group information.

Cheers,
Morgan Fainberg___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] EXT4 as ephemeral disk

[Davanum Srinivas]

Hi,

Here's the original "bug" filed against Nova:
https://bugs.launchpad.net/nova/+bug/1266262

There has been a lot of traffic on the mailing lists in the past and
review churns on this topic:
http://bit.ly/ext4-ephemeral

Based on the last thread, there are 2 reviews in progress:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1266262,n,z

And the Nova core team suggested adding a blueprint (in the last Nova meeting)
https://blueprints.launchpad.net/nova/+spec/ext4-as-ephemeral-disk

Please take a look to see if the changes in progress will work in your
environment(s) and let us know

thanks,
dims

-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [Openstack-operators] Small openstack

[George Shuklin]

Wow. Real problem. I check it - it allows one tenant to interrupt 
traffic on other. I was not able to intercept TCP traffic, victim lost 
connection and TCP  was struggling with retransmissions, but it was not 
good.


But idea of 'no routers in software' is too appealing. I think I'll 
stick with this idea (and wait for fix). Plus, I think, OVS can provide 
some kind of excellent antispoofing mechanism (OVS can use nw_src/nw_dst 
for arp filtering) - if no fix will be available, I'll do some crude fix 
on neutron/nova with OVS (I don't really like etables).


On 01/09/2015 09:25 PM, Kris G. Lindgren wrote:

Also, If you are running this configuration you should be aware of the
following bug:

https://bugs.launchpad.net/neutron/+bug/1274034

And the corresponding fix: https://review.openstack.org/#/c/141130/

Basically - Neutron security group rules do nothing to protect against arp
spoofing/poisoning from vm's.  So its possible under a shared network
configuration for a vm to arp for another vm's ip address and temporarily
knock that vm offline.  The above commit - which is still a WIP adds
ebtable rules to allow neutron to filter protocols other than IP (eg arp).


  
Kris Lindgren

Senior Linux Systems Engineer
GoDaddy, LLC.



On 1/8/15, 9:50 AM, "Kris G. Lindgren"  wrote:



On 1/8/15, 4:34 AM, "Antonio Messina"  wrote:


On Thu, Jan 8, 2015 at 12:12 PM, gustavo panizzo (gfa) 
wrote:


On 01/08/2015 07:01 PM, Antonio Messina wrote:

On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa)

wrote:



i may be wrong as i haven't tested that on juno, but in icehouse and
havana
i've setup external/provider networks one for each tenant


Ah, ok, this is the point. What I would like to have instead is

1) one big external network with routable, private IPs, to be used by
*any*
 tenant (where any tenant can plug ports)


neutron net-create --shared should do the trick

I guess the problem is that I was creating *external* _and_ *shared*
network, but if I don't want to use floating IPs from that network I
probably don't need the network to be external, right?

Correct.  We have our "external networks" (private ip) only configured as
shared so any vm from any tenant can create a port on it.  External means
it's meant to be plugged into a router/l3 agent.



3) small external networks dedicated to a tenant


neutron net-create --tenant-id X-XX


i've made that mix (also add tenantn networks) in my lab running
icehouse
(2014.1.2) worked fine, i've upgraded it to juno but i haven't test
that yet

Thank you, I will test it further.


do you run more than one l3 agent? are you floating ips configured on
br-ex?
i think if you fix the policy.json on nova you should get it working

I currently have only 1 l3-agent running, but it's suboptimal. I would
like to have L3-HA for the floating IPs and DVR for the shared and
tenant networks, but as far as I know it's not currently supported. I
plan to deploy the production cloud after Kilo release, and crossing
my fingers...

Floating IPs are currently configured on br-ex.

You have floating ips working under this configuration?

If so then that means you are using the neutron router as the gateway for
all of your vm's and not the gateway provided by your network device.  As
soon as you created a router and attached the the shared network to it the
router got configured with the gateway address that you configured in your
network.  You may want to make sure that you don¹t have traffic flapping
between your real network gateway and your neutron gateway on your l3
router.

The reason why floating ip's won't work under this configuration (using a
real network device for the gateway) is the fact that the floating ip is
applied at the router as a nat so the traffic flows like: Client (4.2.2.1)
-> floating ip (8.8.8.8) -> external port on router -> The router changes
the destination IP from the floating ip to the private IP of the vm
(172.23.2.40) and send the traffic out to the vm via the routers
connection on the shared network.  The VM responds to the client traffic
which is not in its subnet directly to the default gateway (172.23.0.1).
The gateway (if it is a neutron gateway) will then undo the nat and send
the traffic back to the client.

Where this breaks down with a physical network gateway is when the traffic

>from the VM is sent to the real network gateway - the gateway doesn't know

anything about the nat and does not re-map the vm ip to the floating ip.
IE The client ip never gets changed to the floating ip and sent back to
the client IP.  The Response would be seen as coming directly from
172.23.2.40, instead of 8.8.8.8.  So you will never establish a tcp
connection.

If you have this working somehow - please let me know.  When we attempted
to run this configuration we ran into the above issues with floating ips
when using a real gateway on a network device.

Note: this is also why you need to create your shared n

Re: [Openstack-operators] (no subject)

[David Moreau Simard]

For monitoring, there seems to be a lot of buzz/interest about the new Monasca 
project (https://wiki.openstack.org/wiki/Monasca) but you're probably going to 
get as many different solutions are there are products.
You can have a look at the etherpad from the Paris Ops summit session on 
monitoring to give you an idea: 
https://etherpad.openstack.org/p/kilo-summit-ops-monitoring

We've found Shinken to be able to scale pretty well and cope without too much 
problems to the thousands of services we're throwing at it. We use Graphite for 
data collection and Grafana for data visualization.

For logging, the Openstack Infra team uses the ELK stack (Elastic search, 
Logstash, Kibana) for collecting/aggregating/visualizing/searching logs: 
http://ci.openstack.org/logstash.html

I'll let the other operators chime in on the security side of things.
--
David Moreau Simard

From: Zeeshan Ali Shah mailto:zas...@kth.se>>
Date: Monday, January 12, 2015 at 6:57 AM
To: 
"openstack-operators@lists.openstack.org"
 
mailto:openstack-operators@lists.openstack.org>>
Subject: [Openstack-operators] (no subject)

Hi All,

What is the suggestion to monitor (resource, security) of a large scale OS 
deployment.

1) For Resource :
I tried Nagios and Zabbix they are good at certain extent but is there any 
other suggestion ?


2) For Security /logging etc, i am planning to use Ossec and  Elastic search . 
any suggestion for here ?


--

Regards

Zeeshan Ali Shah
System Administrator - PDC HPC
PhD researcher (IT security)
Kungliga Tekniska Hogskolan
+46 8 790 9115
http://www.pdc.kth.se/members/zashah
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] (no subject)

[Zeeshan Ali Shah]

Hi All,

What is the suggestion to monitor (resource, security) of a large scale OS
deployment.

1) For Resource :
I tried Nagios and Zabbix they are good at certain extent but is there any
other suggestion ?


2) For Security /logging etc, i am planning to use Ossec and  Elastic
search . any suggestion for here ?


-- 

Regards

Zeeshan Ali Shah
System Administrator - PDC HPC
PhD researcher (IT security)
Kungliga Tekniska Hogskolan
+46 8 790 9115
http://www.pdc.kth.se/members/zashah
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators