Re: [Openstack] [Swift] Intermittent error 403 "Access was denied to this resource"

[Chmouel Boudjnah]

On Tue, Jun 4, 2013 at 2:41 PM, Andrii Loshkovskyi
 wrote:
> Thank you for answer.
>
> Chmouel, do you mean the auth_token on Keystone or swift proxy server?
>
> from /etc/keystone/keystone.conf
>
> [filter:token_auth]
> paste.filter_factory = keystone.middleware:TokenAuthMiddleware.factory
>
> from /etc/swift/proxy-server.conf
>
> [filter:authtoken]
> paste.filter_factory = keystone.middleware.auth_token:filter_factory
> ...
> memcache_servers = 127.0.0.1:11211

in here, remove that line and use cache=swift.cache make sure you
configure the cache middleware properly.

> Further debugging proved that hosts without memcached don't return the error
> 403. I'm still investigating what service can return such error body
> message.
>

well you probably want to have caching...

>
>
> On Tue, Jun 4, 2013 at 12:55 PM, Chmouel Boudjnah 
> wrote:
>>
>> I have seen this when keystone is too busy for validating tokens.
>> getting keystone behind apache or scaling up keystone make things a
>> better (and make sure you are using swift memcache connection in
>> auth_token).
>>
>>
>> Chmouel.
>>
>> On Mon, Jun 3, 2013 at 8:15 PM, Andrii Loshkovskyi
>>  wrote:
>> > Hello,
>> >
>> > I would appreciate if you help me to troubleshoot the following issue:
>> >
>> > I am having error 403 intermittenly when listing containers in swift.
>> > Sometimes the error appears a few times per hour, sometimes once per
>> > day.
>> > Basically, it's possible to reproduce the error with a simple curl
>> > command:
>> >
>> > curl --get -v -H 'X-Auth-Token: ef644...'
>> > http://swift-proxy.example.com:8080/v1/AUTH_323d0...
>> > 
>> > 403 Forbidden
>> > Access was denied to this resource.
>> > 
>> >
>> > The token and swift proxy endpoint are all correct as most of the time
>> > the
>> > command works.
>> >
>> > A few words about infrastructure: I use swift 1.7.4 and several swift
>> > proxies. Users are authenticated via Keystone. Tokens are cached with
>> > memcached on swift proxy servers.
>> >
>> > I did a lot of tests to figure out what service generates such error:
>> >
>> > - same issue happens with each swift proxy server, with or without
>> > memcached
>> > enabled
>> > - it happens with different users and in different tenants
>> > - I downloaded sources of swift and Keystone and grepped on that error.
>> > There are some HTTPForbidden values returned in code but no one with the
>> > body 'Access denied to this resource'
>> > - I tried monitoring traffic with tcpdump to catch the error and
>> > understand
>> > who's sending it but with no success yet
>> > - the issue might be related to swift ACL rules but I haven't set any
>> > read/write permissions for containers
>> > - set debug logs for swift proxy but nothing has been found yet
>> >
>> > Please help me to understand how this error is returned. Thank you for
>> > your
>> > time.
>> >
>> >
>> > --
>> > Kind regards,
>> > Andrii Loshkovskyi
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>
>
>
>
> --
> Kind regards,
> Andrii Loshkovskyi
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting DevStack networking working

[Christopher Armstrong]

On Tue, Jun 4, 2013 at 5:02 PM, Christopher Armstrong <
chris.armstr...@rackspace.com> wrote:

> On Tue, Jun 4, 2013 at 2:44 PM, Christopher Armstrong <
> chris.armstr...@rackspace.com> wrote:
>
>> On Tue, Jun 4, 2013 at 2:28 PM, Sean Dague  wrote:
>>
>>> If you are running on recent Ubuntu it appears that you basically need
>>> MULTI_HOST=True set for guest routing to work. Otherwise vhost_net corrupts
>>> the checksums of the dhcp packets, and you're kind of done.
>>>
>>> Been trying to narrow this down as far as possible the last couple of
>>> days (as I have some environments where this works, and some where it
>>> doesn't), but I still don't have a specific narrow work around for it other
>>> than turning on MULTI_HOST.
>>>
>>> -Sean
>>>
>>>
>> I am indeed using Ubuntu 13.04. Does setting MULTI_HOST imply the need to
>> configure other things? I'll give it a try. If it doesn't seem to work, I
>> can try on a 12.04.
>>
>
>
> Now on an Ubuntu 12.04 install if I try to run devstack with quantum I
> can't route to the guests.
>
>
Sorry, this was just due to a brainfart. I'm actually in exactly the same
situation of being able to route in but not out on the guests in 12.04, so
I guess I'm not running into the same bug you mentioned. It's relieving to
get back to a "known" state :-) But now I guess I have a lot of learning to
do to figure out how to debug the outbound routing.

-- 
IRC: radix
Christopher Armstrong
Rackspace
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] A strange quantum agent-list.

[Sam Su]

Hi,

I installed a Grizzly Quantum server node and a Quantum network node based
on Ubuntu 12.04, it can works.

When I used CML quantum agent-list, I got the strange result as below:
*root@nnode01:~# quantum agent-list*
*
+--++---+---++
*
*| id
|  agent_type |   host
 | alive | admin_state_up |*
*
+--++---+---++
*
*| 0e541238-2e3d-4e51-8bde-ecc9831d8498  | Open vSwitch agent |
nnode01.ctrl.cloud.huawei.com  | :-)| True   |*
*| 47ac932f-5f87-4e8f-b6d2-1fe06aaa2b16   | L3 agent
| nnode01| xxx   | True
  |*
*| 498a10dd-76af-49b0-89a2-3a1e481183e4   | DHCP agent|
nnode01.ctrl.cloud.huawei.com| :-) | True   |*
*| 551690c1-25bb-410a-a6a6-75264335fb18   | Open vSwitch agent | nnode01
 | xxx   | True   |*
*| 7c2a1c43-513d-48f9-9ffe-fd69c0c0da2f  | Open vSwitch agent   |
abc.ctrl.cloud.huawei.com | xxx   | True   |*
*| b0b62895-432a-49b7-b806-427715860c37 | DHCP agent|
nnode01| xxx   | True
|*
*| babfd8ef-a349-4faa-aa1d-4c80a216c00c  | L3 agent
  | nnode01.ctrl.cloud.huawei.com| :-) | True   |*
*| bf1a0bf9-9269-4224-b212-9339a89666b7   | Open vSwitch agent   | abc
 | :-) | True
|*
*
+--++---+---++
*

Every host get two records in the agent list, the only difference is the
field "host" and the field "alive".

As my understanding, each host should only get one record in the agent-list
table.

I am wondering how to just get one record per host.

If need more info, please let me know.

Much appreciated for any hints.

Thanks,
Sam
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting DevStack networking working

[Christopher Armstrong]

On Tue, Jun 4, 2013 at 2:44 PM, Christopher Armstrong <
chris.armstr...@rackspace.com> wrote:

> On Tue, Jun 4, 2013 at 2:28 PM, Sean Dague  wrote:
>
>> If you are running on recent Ubuntu it appears that you basically need
>> MULTI_HOST=True set for guest routing to work. Otherwise vhost_net corrupts
>> the checksums of the dhcp packets, and you're kind of done.
>>
>> Been trying to narrow this down as far as possible the last couple of
>> days (as I have some environments where this works, and some where it
>> doesn't), but I still don't have a specific narrow work around for it other
>> than turning on MULTI_HOST.
>>
>> -Sean
>>
>>
> I am indeed using Ubuntu 13.04. Does setting MULTI_HOST imply the need to
> configure other things? I'll give it a try. If it doesn't seem to work, I
> can try on a 12.04.
>


Now on an Ubuntu 12.04 install if I try to run devstack with quantum I
can't route to the guests.

-- 
IRC: radix
Christopher Armstrong
Rackspace
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Quantum : explanation needed about l3-agent et dhcp-agent (because not working)

[Benoit ML]

Hello,

I try to deploy an openstack grizzly plate-forme from redhat rdo, in a
multi-node setup.

Well recently support of  net namespace was added to rhel 6.4 through the
rdo repo.
(One quick note : be carefull about vswitch from rdo, it doesnt support gre
tunnel).

So can somebody explain me how works l3-agent and dhcp-agent please ?

I have understand :
- For a routeur or a dhcp network : quantum create a namespace
- In this namespace dnsmasq is launched on the interface
- a peer is created trourgh a "tap" and "ns" interface
- the tap interface is pushed into the ovs bridge

My probleme is when a VM start the network can't get any dhcp server  :(

I have tested :
- Openvswitch hypervisor : OK ! With manually configure the IP inside the
VMs, they can see each other.

- Tunnel GRE :  OK !  On the network node, i see, with tcpdump on the gre
interface, the dhcp request from the VM.

- NameSpace : They exist and  an interface "ns-" is present with an IP

- dnsmasq : Inside the namespace the dnsmasq daemon listen on the
interface, so it s seems ok !

- Openvswitch "tap" : well the tap is in the bridge ...

- Link between  tap interface and namespace interface : i see the command
line in the quantum agent log ... but how to test it ?? dunno ..

=>> Well but with tcpdump i didn't see any request on the namespace
interface ... and of course any dhcp respond ..

Thank you in advance !!
-- 
--
Benoit
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting DevStack networking working

[Christopher Armstrong]

On Tue, Jun 4, 2013 at 2:28 PM, Sean Dague  wrote:

> If you are running on recent Ubuntu it appears that you basically need
> MULTI_HOST=True set for guest routing to work. Otherwise vhost_net corrupts
> the checksums of the dhcp packets, and you're kind of done.
>
> Been trying to narrow this down as far as possible the last couple of days
> (as I have some environments where this works, and some where it doesn't),
> but I still don't have a specific narrow work around for it other than
> turning on MULTI_HOST.
>
> -Sean
>
>
I am indeed using Ubuntu 13.04. Does setting MULTI_HOST imply the need to
configure other things? I'll give it a try. If it doesn't seem to work, I
can try on a 12.04.


--
IRC: radix
Christopher Armstrong
Rackspace
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting DevStack networking working

[Sean Dague]

If you are running on recent Ubuntu it appears that you basically need 
MULTI_HOST=True set for guest routing to work. Otherwise vhost_net 
corrupts the checksums of the dhcp packets, and you're kind of done.


Been trying to narrow this down as far as possible the last couple of 
days (as I have some environments where this works, and some where it 
doesn't), but I still don't have a specific narrow work around for it 
other than turning on MULTI_HOST.


-Sean

On 06/04/2013 01:52 PM, Christopher Armstrong wrote:

Hi all!

I've been struggling the past couple of days on getting a working
DevStack so I can start contributing to the Heat project. The problems
I've been running into are largely networking related. I've tried a
number of combinations, like using latest git checkouts vs
stable/grizzly for the various projects, and nova-network vs quantum.

The two common behaviors I'm seeing are

1. if I use nova-network, I can't route to the guest VMs at all, with
private or public IP
2. if I use quantum, I can route into the guest VMs, and they can route
to each other, but I can't route out to the Internet (via tthe host
network).

#2 is really close to working, and I wonder if it's just the thing to be
expected. If that's the case, what should I be doing to get the VMs to
be able to route to the outside world? For what it's worth, I followed
the instructions at https://wiki.openstack.org/wiki/QuantumDevstack to
get quantum-on-devstack working. I'm using the single-node setup.

I hope to start contributing a lot to the OpenStack project soon!

--
IRC: radix
Christopher Armstrong
Rackspace



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp




--
Sean Dague
http://dague.net

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] VM Issues on Grizzly Install on Ubuntu 12.04

[Darragh O'Reilly]

Hi Farhan,


it might be an option to push out the lower mtu size using DHCP (option 26) 
http://tools.ietf.org/html/rfc2132#section-5


I was able to get dnsmasq to do that without changing any code.
You may wish to try the following in your test environment to see
if your instances request and use option 26 by default.

Create a /etc/quantum/dnsmasq.conf with these lines:
# push out mtu of 1454 bytes to clients 
dhcp-option=26,1454
# logging options for debugging
log-dhcp
log-facility=/var/log/quantum/dnsmasq.log
 
Then add this line to /etc/quantum/dhcp_agent.ini 
dnsmasq_config_file = /etc/quantum/dnsmasq.conf

and restart the dhcp agent.

Now the DHCP client on the instance needs to request and use this option.
You will see this when it requests it:

# grep mtu /var/log/quantum/dnsmasq.log | cut -c 48-
requested options: 15:domain-name, 26:mtu, 28:broadcast, 42:ntp-server
sent size:  2 option: 26:mtu  05:ae

FYI, here is what Cisco say about mtu when using VXLAN 
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/guide_c07-702975.html#wp989


Darragh.

- Original Message -
> From: Darragh O'Reilly 
> To: Farhan Patwa ; Rahul Sharma 
> 
> Cc: OpenStack Maillist 
> Sent: Thursday, 30 May 2013, 20:47
> Subject: Re: [Openstack] VM Issues on Grizzly Install on Ubuntu 12.04
> 
> Hi Farhan and Rahul,
> 
> I think this issue would only be seen by people using the OVS plugin in 
> a multinode setup with GRE tunnels and doing more than simple ping and ssh 
> access. It seems some sites like github.com are either ignoring or not 
> receiving 
> the "destination unreachable - need fragmentation" ICMP to prevent DoS 
> attackes.
> 
> Yes - cloud-init/metadata could run a script that sets the mtu.
> 
> An alternative workaound is to increase the mtu to 1546 on the interfaces on 
> the 
> network node and the computes nodes that have the GRE tunnel endpoint IPs. 
> Then 
> the instances can stay at their default 1500. This may be a more practical 
> way 
> as long as all the hardware between the endpoints can cope with this mtu size.
> 
> I can't say if this is a bug yet, but it needs to be documented.
>   
> Darragh.
> 
>> 
>>  From: Farhan Patwa 
>> To: Rahul Sharma ; Darragh O'Reilly 
>  
>> Cc: OpenStack Maillist  
>> Sent: Thursday, 30 May 2013, 15:54
>> Subject: Re: [Openstack] VM Issues on Grizzly Install on Ubuntu 12.04
>> 
>> 
>> 
>> Hi Darragh,
>> Thanks a lot for your suggestion. It solved the issue for me also.
>> I also had the same issue on a Folsom install done by following the user 
> guide:
>> http://docs.openstack.org/folsom/basic-install/content/index.html
>> At that time I thought it was an issue with my setup and so I decided to 
> upgrade to Grizzly.
>> 
>> 
>> Wouldn't this be an issue that everyone doing a plain openstack install 
> would face? Its hard to imagine why it has not been noticed before.
>> 
>> 
>> Is there a way I can add the changing of the MTU to the meta data so that it 
> automatically applies to new Vms?
>> 
>> 
>> Thanks again Darragh for all your time and help.
>> 
>> 
>> -Farhan.
>> 
>> From: Rahul Sharma 
>> Date: Thursday, May 30, 2013 12:57 AM
>> To: Darragh O'Reilly 
>> Cc: Farhan Patwa , OpenStack Maillist 
> 
>> Subject: Re: [Openstack] VM Issues on Grizzly Install on Ubuntu 12.04
>> 
>> 
>> 
>> Hi Darragh, 
>>  
>> Even I am facing the same issue of request getting timed out and even 
> updates getting hanged up for very long time. I followed your step of 
> reducing 
> the MTU size from 1500 to 1454 and now everything works fine. I tried this on 
> Ubuntu instances.
>>  
>> This seems to be an issue with the Grizzly release. I had already started 
> email-thread earlier for this but was unable to find the root cause. Here is 
> the 
> link to it:-
>> 
>> https://lists.launchpad.net/openstack/msg23993.html
>> 
>> 
>> Thank you for your suggestion of reducing the MTU size as it solved the 
> problem. You must file a bug for this so that this issue can be tracked.
>> 
>> 
>> Thanks and Regards
>> Rahul Sharma
>> 
>> 
>> 
>> 
>> On Thu, May 30, 2013 at 2:23 AM, Darragh O'Reilly 
>  wrote:
>> 
>> Hi Farhan,
>>> 
>>> I was able to reproduce this with curl from the cirros 0.3.1 that 
> supports ssl.
>>> 
>>> cirros$ curl -L github.com  # -L follow redirects
>>> 
>>> it just hangs and I get these ICMPs on the netnode's physical nic. 
>>> 
>>> 20:33:10.811485 IP (tos 0xc0, ttl 63, id 13647, offset 0, flags [none], 
> proto ICMP (1), length 576)
>>>     192.168.101.2 > 204.232.175.90: ICMP 192.168.101.2 unreachable - 
> need to frag (mtu 1454), length 556
>>> IP (tos 0x0, ttl 51, id 54729, offset 0, flags [DF], proto TCP (6), 
> length 1500)
>>>     204.232.175.90.443 > 192.168.101.2.41237: Flags [.], seq 1:1449, 
> ack 225, win 7, options [nop,nop,TS val 4208725487 ecr 171322], length 1448
>>> 
>>> So I reduced the mtu from the default 1500 to 1454 on the instance and 
> now 'curl -L github.com' works
>>> 
>>> cirr

[Openstack] Getting DevStack networking working

[Christopher Armstrong]

Hi all!

I've been struggling the past couple of days on getting a working DevStack
so I can start contributing to the Heat project. The problems I've been
running into are largely networking related. I've tried a number of
combinations, like using latest git checkouts vs stable/grizzly for the
various projects, and nova-network vs quantum.

The two common behaviors I'm seeing are

1. if I use nova-network, I can't route to the guest VMs at all, with
private or public IP
2. if I use quantum, I can route into the guest VMs, and they can route to
each other, but I can't route out to the Internet (via tthe host network).

#2 is really close to working, and I wonder if it's just the thing to be
expected. If that's the case, what should I be doing to get the VMs to be
able to route to the outside world? For what it's worth, I followed the
instructions at https://wiki.openstack.org/wiki/QuantumDevstack to get
quantum-on-devstack working. I'm using the single-node setup.

I hope to start contributing a lot to the OpenStack project soon!

--
IRC: radix
Christopher Armstrong
Rackspace
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] External gateway for a particular tenant

[Razique Mahroua]

Hi guys, I'm currently setting up a VPN site-to-site for a customer.I've been able to setup the network (I'm running in VLAN mode)...BUT I'd like now to have my instances to use the router (that's a physical equipment) as a gateway instead of the dnsmasq/bridge IP for that network.I found that thread : https://lists.launchpad.net/openstack/msg11953.htmlbut that would means all the network would have their gateway updated. Is there a solution for a network? Meanwhile I had to setup a default gateway within the instances and it's workingcheers guysRazique
Razique Mahroua - Nuage & Corazique.mahr...@gmail.comTel : +33 9 72 37 94 15

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] how to config nova-schedule

[Nguyễn Quốc Vũ]

Hi all,

I'm new to openstack, I read the manual to study about it's scheduling.

I find that there are other schedulers (chance, multi, and simple
scheduler). How can I config to change the schedule in nova?

By default there is "compute_scheduler_driver =
nova.scheduler.filter_scheduler.FilterScheduler" in nova.conf file. It will
call host_manager to apply all the filters (RetryFilter,
AvailabilityZoneFilter, RamFilter,...) is defined in there right? and so we
just change those filters if we want to archive our requires?

I just try to find how to allocate an instance. For example, we want to
create 2 instances both are require lot of CPU, it will be allocated in two
different hosts. In case of one is require CPU, and another one is just
require I/O, it will be allocated in the same host. Any idea?

thanks,

-- 
Regards,
Nguyen Quoc Vu
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Cinder] Re: Multiple machines hosting cinder-volumes with Folsom ?

[Sylvain Bauza]

Hi Anne,

Thanks for the quick reply.

Le 04/06/2013 16:00, Anne Gentle a écrit :


If that's all a bit too much, we can work on it from your blog entry, 
I've created this doc bug to track the work: 
https://bugs.launchpad.net/openstack-manuals/+bug/1187400. Feel free 
to assign yourself.

Thanks!
Anne





I will do by my own, it's a great opportunity for me to deliver a first 
rock in my Openstack garden :-)


-Sylvain

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Swift performance issues with requests

[Rick Jones]

On 06/04/2013 02:45 AM, Klaus Schürmann wrote:

Hi Rick,

I found the problem. I placed a hardware balancer in front of the proxy server.
The balancer lost some packets because of a faulty network interface.
Your tip was excellent.


I'm glad it helped.  Looking back I see that my math on the cumulative 
time for successive retransmissions of TCP SYNs was completely wrong - 3 
+ 6 + 12 isn't 17, but 21... :)


rick



Thanks
Klaus

-Ursprüngliche Nachricht-
Von: Rick Jones [mailto:rick.jon...@hp.com]
Gesendet: Freitag, 31. Mai 2013 19:17
An: Klaus Schürmann
Cc: openstack@lists.launchpad.net
Betreff: Re: [Openstack] Swift performance issues with requests

On 05/31/2013 04:55 AM, Klaus Schürmann wrote:

May 31 10:33:08 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 
31/May/2013/08/33/08 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 - 
Wget/1.12%20%28linux-gnu%29 provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 
- 283354 - txd4a3a4bf3f384936a0bc14dbffddd275 - 0.1020 -
May 31 10:33:26 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 31/May/2013/08/33/26 GET 
/v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 - Wget/1.12%20%28linux-gnu%29 
provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - txd8c6b34b8e41460bb2c5f3f4b6def0ef - 17.7330 -   
<<


Something I forgot to mention, which was the basis for my TCP
retransmissions guess.  Depending on your kernel revision, the initial
TCP retransmission timeout is 3 seconds, and it will double each time -
eg 3, 6, 12.  As it happens, the cumulative time for that is 17
seconds...  So, the 17 seconds and change would be consistent with a
transient problem in establishing a TCP connection.  Of course, it could
just be a coincidence.

Later kernels - I  forget where in the 3.X stream exactly - have the
initial retransmission timeout of 1 second.  In that case the timeouts
would go 1, 2, 4, 8, etc...

rick




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Cinder] Re: Multiple machines hosting cinder-volumes with Folsom ?

[Anne Gentle]

On Mon, Jun 3, 2013 at 2:47 AM, Sylvain Bauza wrote:

>  Thanks Jerome for the clarification.
> I just posted out a blogpost for adding a Second volume to Cinder in
> Folsom [3]. Maybe it could be merged with the official Folsom Ubuntu Cinder
> documentation ? There is only H/A aspects that are mentioned by now.
>
> Someone from the documentation team ? Could you please point me out some
> materials for committing a new doc for that ?
>
>
Hi Sylvain,
Would love to have an update for clarity. Since it affects just the
stable/folsom branch of openstack-manuals, and there was no separate Block
Storage Admin manual at that point in time, you'll want to update the
Volumes chapter within the Compute Admin manual. To do so, follow the
instructions on http://wiki.openstack.org/Documentation/HowTo. As an
outline of the steps:
Git clone the openstack-manuals repository.
Checkout a new branch based on remotes/origin/stable/folsom.
Make your edits in
https://github.com/openstack/openstack-manuals/blob/stable/folsom/doc/src/docbkx/openstack-compute-admin/computevolumes.xml
.
Git commit, git review, we'll review the patch and publish.

If that's all a bit too much, we can work on it from your blog entry, I've
created this doc bug to track the work:
https://bugs.launchpad.net/openstack-manuals/+bug/1187400. Feel free to
assign yourself.
Thanks!
Anne




>  Thanks,
> -Sylvain
>
> [3] :
> http://sbauza.wordpress.com/2013/06/03/adding-a-second-cinder-volume-with-folsom/
>
>
> Le 31/05/2013 14:26, Jérôme Gallard a écrit :
>
> Hi Sylvain,
>
>  Great to know that you found how to solve your issue.
>
>  Thanks for reporting that you found the Grizzly doc confusing.
>  In fact, the Grizzly release introduced the multi-backend feature. This
> feature allows to have more than one backend on a same compute (ie, to be
> able to have several cinder-volume running on a same compute). This feature
> is not available in Folsom: you can only run one cinder-volume per compute
> (in that case, if you want to manage several backends, you have to have
> several computes).
>
>  Thanks a lot for your remarks,
> Jérôme
>
>
> On Fri, May 31, 2013 at 1:55 PM, Sylvain Bauza  > wrote:
>
>>  Thanks but it didn't match my needs. I already know how to deploy
>> Cinder on a single host, my point was more relative to deploying a second
>> Cinder-volume instance, and if yes, what to do.
>>
>> Nevermind, I successed in deploying a second Cinder-volume, just by
>> looking at the packages and the confs. It's pretty straightforward, so I'm
>> not surprised it wasn't documented. Nevertheless, I think that the Grizzly
>> doc I mentioned [1] is confusing : by looking at it, I was thinking Cinder
>> was unable to have two distinct volumes with Folsom release. Maybe updating
>> the folsom branch for Cinder documentation, precising it *is* possible, is
>> worth a try ?
>>
>> Anyway, I'm documenting out the process in my own (new) blog. Keep tuned,
>> I'll post the URL out there.
>>
>> -Sylvain
>>
>>
>>
>> Le 31/05/2013 11:39, Jérôme Gallard a écrit :
>>
>> Hi Sylvain,
>>
>>  Maybe the folsom documentation for cinder will help you:
>>
>> http://docs.openstack.org/folsom/openstack-compute/install/apt/content/osfolubuntu-cinder.html
>>
>>
>>  Regards,
>> Jérôme
>>
>>
>> On Fri, May 31, 2013 at 9:21 AM, Sylvain Bauza <
>> sylvain.ba...@digimind.com> wrote:
>>
>>> Putting openstack-ops@ in the loop :-)
>>>
>>> Le 30/05/2013 17:26, Sylvain Bauza a écrit :
>>>
>>>  Le 30/05/2013 15:25, Sylvain Bauza a écrit :

> Hi,
>
> It sounds quite unclear for me about the possibility *in Folsom* to
> have two distinct Cinder hosts having each one LVM backend called
> cinder-volumes ?
>
> As per the doc [1], I would say the answer is no, but could you please
> confirm ?
>
> If so, do you have any idea on how to trick a nearly full LVM
> cinder-volumes VG ? (I can't hardly add a new disk for adding a second 
> PV).
>
> Thanks,
> -Sylvain
>
> [1] :
> http://docs.openstack.org/grizzly/openstack-block-storage/admin/content/multi_backend.html
>

 Replying to myself. As per [2], it seems having a multiple
 cinder-volume setup in Folsom is achiveable. Could someone from Cinder
 confirm that this setup is OK ?

 [2] : https://lists.launchpad.net/openstack/msg21825.html

>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
P

Re: [Openstack] configure devstack to get cinder volume events/meters from ceilometer

[Julien Danjou]

On Tue, Jun 04 2013, Swann Croiset wrote:

> the exchange used to send notifications need to match between Cinder and
> Ceilometer configurations.
> since ceilometer has 'cinder' as default and cinder has 'openstack' as
> default
>
> try to set in cinder.conf:
> control_exchange=cinder

This is bug in Cinder. One should check if it's reported already, it
would be trivial to fix…

-- 
Julien Danjou
/* Free Software hacker * freelance consultant
   http://julien.danjou.info */


signature.asc
Description: PGP signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] dnsmasq default lease time

[Rami Vaknin]

Hi,

The default dnsmasq lease time of 2 mins flood my /var/log/messages file 
with dhcp requests and acks, do you guys think that there is a good 
reason for the default lease time to be so low? do you think we better 
change the default to be a higher value?


--

Thanks,

Rami Vaknin, QE @ Red Hat, TLV, IL.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] configure devstack to get cinder volume events/meters from ceilometer

[Swann Croiset]

the exchange used to send notifications need to match between Cinder and 
Ceilometer configurations.
since ceilometer has 'cinder' as default and cinder has 'openstack' as 
default


try to set in cinder.conf:
control_exchange=cinder


And i don't know what is usage audit here ...



Le 04/06/2013 10:08, Anshul Gangwar a écrit :
I have already added 
notification_driver=cinder.openstack.common.notifier.rpc_notifier and 
restarted cinder-volume service.


How can I enable usage audit ?

I have already tried things which I have described in my previous 
query https://lists.launchpad.net/openstack/msg24112.html




*From:* Julien Danjou 
*To:* Anshul Gangwar 
*Cc:* "openstack@lists.launchpad.net" 
*Sent:* Tuesday, 4 June 2013 1:31 PM
*Subject:* Re: [Openstack] configure devstack to get cinder volume 
events/meters from ceilometer


On Tue, Jun 04 2013, Anshul Gangwar wrote:

> I want to receive cinder volume meters from ceilometer.  What 
changes shall i make in localrc file of devstack to acheive this?


You need:

notification_driver=cinder.openstack.common.notifier.rpc_notifier

and usage audit enabled and running.

--
Julien Danjou
-- Free Software hacker - freelance consultant
-- http://julien.danjou.info 



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



--
Swann Croiset
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 74 70

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Swift] Intermittent error 403 "Access was denied to this resource"

[Andrii Loshkovskyi]

Thank you for answer.

Chmouel, do you mean the auth_token on Keystone or swift proxy server?

from /etc/keystone/keystone.conf

[filter:token_auth]
paste.filter_factory = keystone.middleware:TokenAuthMiddleware.factory

from /etc/swift/proxy-server.conf

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
...
memcache_servers = 127.0.0.1:11211

Further debugging proved that hosts without memcached don't return the
error 403. I'm still investigating what service can return such error body
message.



On Tue, Jun 4, 2013 at 12:55 PM, Chmouel Boudjnah wrote:

> I have seen this when keystone is too busy for validating tokens.
> getting keystone behind apache or scaling up keystone make things a
> better (and make sure you are using swift memcache connection in
> auth_token).
>
>
> Chmouel.
>
> On Mon, Jun 3, 2013 at 8:15 PM, Andrii Loshkovskyi
>  wrote:
> > Hello,
> >
> > I would appreciate if you help me to troubleshoot the following issue:
> >
> > I am having error 403 intermittenly when listing containers in swift.
> > Sometimes the error appears a few times per hour, sometimes once per day.
> > Basically, it's possible to reproduce the error with a simple curl
> command:
> >
> > curl --get -v -H 'X-Auth-Token: ef644...'
> > http://swift-proxy.example.com:8080/v1/AUTH_323d0...
> > 
> > 403 Forbidden
> > Access was denied to this resource.
> > 
> >
> > The token and swift proxy endpoint are all correct as most of the time
> the
> > command works.
> >
> > A few words about infrastructure: I use swift 1.7.4 and several swift
> > proxies. Users are authenticated via Keystone. Tokens are cached with
> > memcached on swift proxy servers.
> >
> > I did a lot of tests to figure out what service generates such error:
> >
> > - same issue happens with each swift proxy server, with or without
> memcached
> > enabled
> > - it happens with different users and in different tenants
> > - I downloaded sources of swift and Keystone and grepped on that error.
> > There are some HTTPForbidden values returned in code but no one with the
> > body 'Access denied to this resource'
> > - I tried monitoring traffic with tcpdump to catch the error and
> understand
> > who's sending it but with no success yet
> > - the issue might be related to swift ACL rules but I haven't set any
> > read/write permissions for containers
> > - set debug logs for swift proxy but nothing has been found yet
> >
> > Please help me to understand how this error is returned. Thank you for
> your
> > time.
> >
> >
> > --
> > Kind regards,
> > Andrii Loshkovskyi
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>



-- 
Kind regards,
Andrii Loshkovskyi
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Keystone] Policy settings not working correctly

[Heiko Krämer]

Heyho guys :)

I've a little problem with policy settings in keystone. I've create a
new rule in my policy-file and restarts keystone but keystone i don't
have privileges.

Example:


keystone user-create --name kadmin --pw lala
keystone user-role-add --

keystone role-list --user kadmin --role KeystoneAdmin --tenant admin

+--+--+
|id| name |
+--+--+
| 3f5c0af585db46aeaec49da28900de28 |KeystoneAdmin |
| dccfed0bd790420bbf1982686cbf7e31 | KeystoneServiceAdmin |


cat /etc/keystone/policy.json

{
"admin_required": [["role:admin"], ["is_admin:1"]],
"owner" : [["user_id:%(user_id)s"]],
"admin_or_owner": [["rule:admin_required"], ["rule:owner"]],
"admin_or_kadmin": [["rule:admin_required"], ["role:KeystoneAdmin"]],

"default": [["rule:admin_required"]],
[.]
"identity:list_users": [["rule:admin_or_kadmin"]],
[]



keystone user-list
Unable to communicate with identity service: {"error": {"message": "You
are not authorized to perform the requested action: admin_required",
"code": 403, "title": "Not Authorized"}}. (HTTP 403)


In log file i see:
DEBUG [keystone.policy.backends.rules] enforce admin_required:
{'tenant_id': u'b33bf3927d4e449a98cec4a883148110', 'user_id':
u'46a6a9e429db483f8346f0259e99d6a5', u'roles': [u'KeystoneAdmin']}




Why does keystone enforce /admin_required/ rule instead of the defined
rule (/admin_or_kadmin/).



Keystone conf:
[...]

# Path to your policy definition containing identity actions
policy_file = policy.json
[..]
[policy]
driver = keystone.policy.backends.rules.Policy




Any have an idea ?

Thx and greetings
Heiko

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Swift] Intermittent error 403 "Access was denied to this resource"

[Chmouel Boudjnah]

I have seen this when keystone is too busy for validating tokens.
getting keystone behind apache or scaling up keystone make things a
better (and make sure you are using swift memcache connection in
auth_token).


Chmouel.

On Mon, Jun 3, 2013 at 8:15 PM, Andrii Loshkovskyi
 wrote:
> Hello,
>
> I would appreciate if you help me to troubleshoot the following issue:
>
> I am having error 403 intermittenly when listing containers in swift.
> Sometimes the error appears a few times per hour, sometimes once per day.
> Basically, it's possible to reproduce the error with a simple curl command:
>
> curl --get -v -H 'X-Auth-Token: ef644...'
> http://swift-proxy.example.com:8080/v1/AUTH_323d0...
> 
> 403 Forbidden
> Access was denied to this resource.
> 
>
> The token and swift proxy endpoint are all correct as most of the time the
> command works.
>
> A few words about infrastructure: I use swift 1.7.4 and several swift
> proxies. Users are authenticated via Keystone. Tokens are cached with
> memcached on swift proxy servers.
>
> I did a lot of tests to figure out what service generates such error:
>
> - same issue happens with each swift proxy server, with or without memcached
> enabled
> - it happens with different users and in different tenants
> - I downloaded sources of swift and Keystone and grepped on that error.
> There are some HTTPForbidden values returned in code but no one with the
> body 'Access denied to this resource'
> - I tried monitoring traffic with tcpdump to catch the error and understand
> who's sending it but with no success yet
> - the issue might be related to swift ACL rules but I haven't set any
> read/write permissions for containers
> - set debug logs for swift proxy but nothing has been found yet
>
> Please help me to understand how this error is returned. Thank you for your
> time.
>
>
> --
> Kind regards,
> Andrii Loshkovskyi
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Swift performance issues with requests

[Klaus Schürmann]

Hi Rick,

I found the problem. I placed a hardware balancer in front of the proxy server. 
The balancer lost some packets because of a faulty network interface.
Your tip was excellent.

Thanks
Klaus

-Ursprüngliche Nachricht-
Von: Rick Jones [mailto:rick.jon...@hp.com] 
Gesendet: Freitag, 31. Mai 2013 19:17
An: Klaus Schürmann
Cc: openstack@lists.launchpad.net
Betreff: Re: [Openstack] Swift performance issues with requests

On 05/31/2013 04:55 AM, Klaus Schürmann wrote:
> May 31 10:33:08 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 
> 31/May/2013/08/33/08 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 
> - Wget/1.12%20%28linux-gnu%29 
> provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - 
> txd4a3a4bf3f384936a0bc14dbffddd275 - 0.1020 -
> May 31 10:33:26 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 
> 31/May/2013/08/33/26 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 
> - Wget/1.12%20%28linux-gnu%29 
> provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - 
> txd8c6b34b8e41460bb2c5f3f4b6def0ef - 17.7330 -   <<

Something I forgot to mention, which was the basis for my TCP 
retransmissions guess.  Depending on your kernel revision, the initial 
TCP retransmission timeout is 3 seconds, and it will double each time - 
eg 3, 6, 12.  As it happens, the cumulative time for that is 17 
seconds...  So, the 17 seconds and change would be consistent with a 
transient problem in establishing a TCP connection.  Of course, it could 
just be a coincidence.

Later kernels - I  forget where in the 3.X stream exactly - have the 
initial retransmission timeout of 1 second.  In that case the timeouts 
would go 1, 2, 4, 8, etc...

rick

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [OSSA 2013-013] Keystone client local information disclosure (CVE-2013-2013)

[Thierry Carrez]

Robert Collins wrote:
> What if we were to always do a release after a security advisory?

We don't do a server "stable release" after each security advisory as it
doesn't significantly help spreading the fix, but I agree that for
client libraries (where the PyPI releases are the main form of
downstream consumption of the fix) it makes sense to tag and trigger a
new PyPI release after each security advisory.

These were the first advisories on client libraries, but with Keystone
middleware being shipped within python-keystoneclient, I expect more in
the future.

-- 
Thierry Carrez (ttx)
OpenStack Vulnerability Management Team

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] configure devstack to get cinder volume events/meters from ceilometer

[Anshul Gangwar]

I have already added 
notification_driver=cinder.openstack.common.notifier.rpc_notifier and restarted 
cinder-volume service.

How can I enable usage audit ?

I have already tried things which I have described in my previous query  
https://lists.launchpad.net/openstack/msg24112.html





 From: Julien Danjou 
To: Anshul Gangwar  
Cc: "openstack@lists.launchpad.net"  
Sent: Tuesday, 4 June 2013 1:31 PM
Subject: Re: [Openstack] configure devstack to get cinder volume events/meters 
from ceilometer
 

On Tue, Jun 04 2013, Anshul Gangwar wrote:

> I want to receive cinder volume meters from ceilometer.  What changes shall i 
> make in localrc file of devstack to acheive this?

You need:

notification_driver=cinder.openstack.common.notifier.rpc_notifier

and usage audit enabled and running.

-- 
Julien Danjou
-- Free Software hacker - freelance consultant
-- http://julien.danjou.info___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] configure devstack to get cinder volume events/meters from ceilometer

[Julien Danjou]

On Tue, Jun 04 2013, Anshul Gangwar wrote:

> I want to receive cinder volume meters from ceilometer.  What changes shall i 
> make in localrc file of devstack to acheive this?

You need:

notification_driver=cinder.openstack.common.notifier.rpc_notifier

and usage audit enabled and running.

-- 
Julien Danjou
-- Free Software hacker - freelance consultant
-- http://julien.danjou.info


signature.asc
Description: PGP signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack "I" release naming

[Thierry Carrez]

The poll closed a few minutes ago, the results are in:

1. Icehouse: 102
2. Ichang:73
3. Inverness: 58

The *next* release cycle for OpenStack, starting in November 2013 after
we conclude the current release cycle ("Havana") will therefore be
called "Icehouse" !

https://launchpad.net/~openstack/+poll/i-release-naming

Thanks to all participants to the poll.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Quantum] second tenant's several VMs' floating ip can't be accessed.

[Salvatore Orlando]

Good job guys.
I reckon we might make users' life easier if we change naming strategy for
default security groups to 'default-$tenant_id'
On the other hand this is not a priority since as an admin user I guess you
can already get that information properly choosing the fields to display.

Salvatore


On 4 June 2013 09:23, Li, Leon  wrote:

> Aaron,
>
> ** **
>
> It really works after I add the icmp rule for my second tenant. Thanks for
> your help!
>
> ** **
>
> Leon
>
> ** **
>
> *From:* Aaron Rosen [mailto:aro...@nicira.com]
> *Sent:* 2013年6月4日 10:37
>
> *To:* Li, Leon
> *Cc:* openstack-operat...@lists.openstack.org;
> openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> *Subject:* Re: [Openstack] [Quantum] second tenant's several VMs'
> floating ip can't be accessed.
>
> ** **
>
> You are probably running quantum commands as an admin user that's why you
> got the error:
> Multiple security_group matches found for name 'default', use an ID to be
> more specific.
>
> If you run quantum security-group-list
>
> and then:
>
> quantum security-group-rule-create --protocol icmp --direction ingress
>  
>
> ** **
>
> for each default security group. 
>
> ** **
>
> I'm guessing the security group for your second tenant does not have this
> rule as I don't see two icmp rules in the security-group-rule-list output
> you pasted. 
>
> ** **
>
> Aaron
>
> ** **
>
> ** **
>
> On Mon, Jun 3, 2013 at 7:05 PM, Li, Leon  wrote:
>
> Aaron,
>
>  
>
> Thanks for helping.
>
> Actually I already have had this rule:
>
> (quantum)  security-group-rule-list
>
>
> +--++---+--+--+--+
> 
>
> | id   | security_group | direction |
> protocol | remote_ip_prefix | remote_group |
>
>
> +--++---+--+--+--+
> 
>
> | 1a5867db-864b-4ae9-a423-092f3c25d710 | default| ingress
> |  |  | default  |
>
> | 5449c312-00ba-4625-813f-1d7f06bb8259 | default| ingress   |
> tcp  | 0.0.0.0/0|  |
>
> | 59166d99-0901-4c58-8bf3-ff46cfd4bb01 | default| egress
> |  |  |  |
>
> | 79708fb2-50b1-4c7b-82a5-5cd0275603ad | default| egress
> |  |  |  |
>
> | 940a2743-859a-444c-9c3c-0204995e87ba | default| ingress
> |  |  | default  |
>
> | a7812053-a913-4288-bbd3-c5f225f38d13 | default| ingress
> |  |  | default  |
>
> | b160a8cf-7ca0-4da6-b238-68315b199314 | default| egress
> |  |  |  |
>
> | bce886e7-74d2-46bc-aba6-5928a17b2c74 | default| ingress
> |  |  | default  |
>
> | c3ccbe23-5d44-4cbc-991d-a5df29aa5300 | default| ingress
> |  |  | default  |
>
> | c86af4d4-d6eb-4b15-a23c-1d84d8b27716 | default| egress
> |  |  |  |
>
> | c9b96941-c652-4b24-9162-4a1dcd999088 | default| ingress   |
> icmp | 0.0.0.0/0|  |
>
> | dd26aab7-7641-4ad8-ac53-fe443f41ab5f | default| ingress
> |  |  | default  |
>
> | f87eeaea-4b97-4995-968e-34f127d09bd3 | default| egress
> |  |  |  |
>
> | fc7d35d0-d2b6-4df1-a03b-ca28c5e5c487 | default| egress
> |  |  |  |
>
>
> +--++---+--+--+--+
> 
>
> (quantum) security-group-rule-create --protocol icmp --direction ingress
> default
>
> Multiple security_group matches found for name 'default', use an ID to be
> more specific.
>
> (quantum)
>
>  
>
> Actualy my first tenant’s several VMs don’t have network issue. Can ping
> their’s floating IP from Internet.
>
> However my second tenant’s several VMs have same network issue: can ping
> Internet from vm, but can’t ping their floating IP from Internet.
>
>  
>
> Leon
>
>  
>
> *From:* Aaron Rosen [mailto:aro...@nicira.com]
> *Sent:* 2013年6月4日 9:03
> *To:* Li, Leon
> *Cc:* openstack-operat...@lists.openstack.org;
> openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> *Subject:* Re: [Openstack] [Quantum] second tenant VM's floating ip can't
> be accessed.
>
>  
>
> Hi Li, 
>
>  
>
> If you can ping out to the internet from your second vm but not back in
> it's most likely related to security groups. 
>
>  
>
> I'd try running: quantum security-group-rule-create --protocol icmp
> --direction ingress default 
>
>  
>
> and see if that allows ping fro

Re: [Openstack] [Quantum] second tenant's several VMs' floating ip can't be accessed.

[Li, Leon]

Aaron,

It really works after I add the icmp rule for my second tenant. Thanks for your 
help!

Leon

From: Aaron Rosen [mailto:aro...@nicira.com]
Sent: 2013年6月4日 10:37
To: Li, Leon
Cc: openstack-operat...@lists.openstack.org; openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Quantum] second tenant's several VMs' floating ip 
can't be accessed.

You are probably running quantum commands as an admin user that's why you got 
the error:
Multiple security_group matches found for name 'default', use an ID to be more 
specific.

If you run quantum security-group-list

and then:

quantum security-group-rule-create --protocol icmp --direction ingress 


for each default security group.

I'm guessing the security group for your second tenant does not have this rule 
as I don't see two icmp rules in the security-group-rule-list output you pasted.

Aaron


On Mon, Jun 3, 2013 at 7:05 PM, Li, Leon 
mailto:leon@emc.com>> wrote:
Aaron,

Thanks for helping.
Actually I already have had this rule:
(quantum)  security-group-rule-list
+--++---+--+--+--+
| id   | security_group | direction | protocol 
| remote_ip_prefix | remote_group |
+--++---+--+--+--+
| 1a5867db-864b-4ae9-a423-092f3c25d710 | default| ingress   |  
|  | default  |
| 5449c312-00ba-4625-813f-1d7f06bb8259 | default| ingress   | tcp  
| 0.0.0.0/0|  |
| 59166d99-0901-4c58-8bf3-ff46cfd4bb01 | default| egress|  
|  |  |
| 79708fb2-50b1-4c7b-82a5-5cd0275603ad | default| egress|  
|  |  |
| 940a2743-859a-444c-9c3c-0204995e87ba | default| ingress   |  
|  | default  |
| a7812053-a913-4288-bbd3-c5f225f38d13 | default| ingress   |  
|  | default  |
| b160a8cf-7ca0-4da6-b238-68315b199314 | default| egress|  
|  |  |
| bce886e7-74d2-46bc-aba6-5928a17b2c74 | default| ingress   |  
|  | default  |
| c3ccbe23-5d44-4cbc-991d-a5df29aa5300 | default| ingress   |  
|  | default  |
| c86af4d4-d6eb-4b15-a23c-1d84d8b27716 | default| egress|  
|  |  |
| c9b96941-c652-4b24-9162-4a1dcd999088 | default| ingress   | icmp 
| 0.0.0.0/0|  |
| dd26aab7-7641-4ad8-ac53-fe443f41ab5f | default| ingress   |  
|  | default  |
| f87eeaea-4b97-4995-968e-34f127d09bd3 | default| egress|  
|  |  |
| fc7d35d0-d2b6-4df1-a03b-ca28c5e5c487 | default| egress|  
|  |  |
+--++---+--+--+--+
(quantum) security-group-rule-create --protocol icmp --direction ingress default
Multiple security_group matches found for name 'default', use an ID to be more 
specific.
(quantum)

Actualy my first tenant’s several VMs don’t have network issue. Can ping 
their’s floating IP from Internet.
However my second tenant’s several VMs have same network issue: can ping 
Internet from vm, but can’t ping their floating IP from Internet.

Leon

From: Aaron Rosen [mailto:aro...@nicira.com]
Sent: 2013年6月4日 9:03
To: Li, Leon
Cc: 
openstack-operat...@lists.openstack.org;
 openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Quantum] second tenant VM's floating ip can't be 
accessed.

Hi Li,

If you can ping out to the internet from your second vm but not back in it's 
most likely related to security groups.

I'd try running: quantum security-group-rule-create --protocol icmp --direction 
ingress default

and see if that allows ping from the internet to be received.

Aaron

On Mon, Jun 3, 2013 at 2:43 AM, Li, Leon 
mailto:leon@emc.com>> wrote:
Hi all,

I set up an openstack recently. My first tenant’s VMs’ floating IP work fine. 
All of them is pingable from “Internet”.
However on second tenant, via GUI or CLI I can successfully assign floating IPs 
to VMs, but they are not pingable. Meanwhile, I can ping Internet from VM’s 
private network(IP).
My environment: Grizzly. Quantum. 3 physical servers. One is controller; one is 
network; and the other is compute node. GRE tunnel.
Anyone has idea? Thanks for your help.

Leon

___
Mailing list: https://launchpad.ne