date:20130522

Re: [Openstack] DHCP problem in grizzly

2013-05-22 Thread Thomas Kärgel

Hi Johanna,

sure, I'll report my results, but this can take a while. The last time
this issue occurred on my environment is May 10th. It occurs quite
sporadic and i don't know how to manually reproduce this issue yet (i
have to be very careful with my experiments since the environment is
running productive already). Maybe you should also give dnsmasq 2.66 a
try, because you wrote that you can manually reproduce this behavior.


Best Regards,
Thomas


Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
 Hi,
 
 You are right. Manually doing kill -HUP PID has just the effect you 
 mentioned. In the syslog you can see
 
 May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
 May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read 
 /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
 May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read 
 /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
 
 
 But the problem stays. Only 'service quantum-dhcp-agent restart' fixes the 
 problem.
 If you try the newer version of the qnsmasq, I'd be interested to hear the 
 results.
 
 BR
 Johanna
 
 
 
 -Original Message-
 From: ext Thomas Kärgel [mailto:kaer...@b1-systems.de] 
 Sent: Monday, May 20, 2013 11:37 AM
 To: Heinonen, Johanna (NSN - FI/Espoo)
 Cc: openstack@lists.launchpad.net
 Subject: Re: [Openstack] DHCP problem in grizzly
 
 Hi,
 
 thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
 my environment. Can you can confirm that manually sigHUPing all running
 dnsmasq processes has no effect?
 (dnsmasq claims to have reread the configs in syslog, but still refuses
 to deliver the new addresses.)
 Maybe updating dnsmasq to a more recent release would solve our problem.
 Current stable is 2.66. I'll give it a try when i get back to office
 tomorrow.
 
 Best regards
 
 Thomas
 
 
 Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
 Hi Thomas,

 I am using Ubuntu12.04 and the dnsmasq version is 2.59

 BR
 Johanna


 -Original Message-
 From: Openstack 
 [mailto:openstack-bounces+johanna.heinonen=nsn@lists.launchpad.net] On 
 Behalf Of ext Thomas Kärgel
 Sent: Monday, May 20, 2013 10:09 AM
 To: openstack@lists.launchpad.net
 Subject: Re: [Openstack] DHCP problem in grizzly

 Hi Johanna,

 I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
 noticed that new hosts have correct entries in the dnsmasq config-files.
 The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
 to deliver the new address. Instead dnsmasq logs claim no address
 available. Exactly like in your description.
 What distrubtion and exact dnsmasq-versions are in use on your environment?
 I assume dnsmasq is not rereading its configs correctly on signal HUP.
 dnsmasq logs claim it has reread configs, but it still does not deliver
 the new adresses in host-file.
 Manually trying to sigHUP dnsmasq had no effect. The only way to get out
 of this state seems to be restarting DHCP-agent.

 Best regards
 Thomas

 Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
 Hi,
  
 I have installed grizzly with quantum and ovs-plugin. It seems that
 grizzly allocates the third address of each subnet for dhcp. (In folsom
 it was the second address). This means that the VMs will get addresses
 .2, .4, .5, .
  
 In my setup the first VM always boots fine and gets the address x.x.x.2.
 This can be seen in the syslog:
  
 May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
 DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
 May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
 DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
 May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
 DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
 May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
  
 The problem comes when I start the second VM. Nova shows that the
 x.x.x.4 is allocated
  
 root@grizzly-236:~# nova list
 +--+--+++
 | ID   | Name | Status |
 Networks   |
 +--+--+++
 | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test   | ACTIVE |
 tenant1-net=10.20.30.2 |
 | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
 tenant1-net=10.20.30.4 |
 +--+--+++
  
 But from syslog I see that the answer to the DHCPDISCOVER is no address
 available
  
 May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
 DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
 available
 May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
 DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
 available
  
 When I restart the quantum-dhcp-server the problem disappears. This can
 be seen from the syslog:
  
 May 20

Re: [Openstack] DHCP problem in grizzly

2013-05-22 Thread Marco Colombo

Hi All,
i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
killall dnsmasq  service quantum-dhcp-agent restart fixes the problem
temporarily

Best Regards,
Marco




2013/5/22 Thomas Kärgel kaer...@b1-systems.de

 Hi Johanna,

 sure, I'll report my results, but this can take a while. The last time
 this issue occurred on my environment is May 10th. It occurs quite
 sporadic and i don't know how to manually reproduce this issue yet (i
 have to be very careful with my experiments since the environment is
 running productive already). Maybe you should also give dnsmasq 2.66 a
 try, because you wrote that you can manually reproduce this behavior.


 Best Regards,
 Thomas


 Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
  Hi,
 
  You are right. Manually doing kill -HUP PID has just the effect you
 mentioned. In the syslog you can see
 
  May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
  May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
 /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
  May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
 /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
 
 
  But the problem stays. Only 'service quantum-dhcp-agent restart' fixes
 the problem.
  If you try the newer version of the qnsmasq, I'd be interested to hear
 the results.
 
  BR
  Johanna
 
 
 
  -Original Message-
  From: ext Thomas Kärgel [mailto:kaer...@b1-systems.de]
  Sent: Monday, May 20, 2013 11:37 AM
  To: Heinonen, Johanna (NSN - FI/Espoo)
  Cc: openstack@lists.launchpad.net
  Subject: Re: [Openstack] DHCP problem in grizzly
 
  Hi,
 
  thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
  my environment. Can you can confirm that manually sigHUPing all running
  dnsmasq processes has no effect?
  (dnsmasq claims to have reread the configs in syslog, but still refuses
  to deliver the new addresses.)
  Maybe updating dnsmasq to a more recent release would solve our problem.
  Current stable is 2.66. I'll give it a try when i get back to office
  tomorrow.
 
  Best regards
 
  Thomas
 
 
  Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
  Hi Thomas,
 
  I am using Ubuntu12.04 and the dnsmasq version is 2.59
 
  BR
  Johanna
 
 
  -Original Message-
  From: Openstack [mailto:openstack-bounces+johanna.heinonen=
 nsn@lists.launchpad.net] On Behalf Of ext Thomas Kärgel
  Sent: Monday, May 20, 2013 10:09 AM
  To: openstack@lists.launchpad.net
  Subject: Re: [Openstack] DHCP problem in grizzly
 
  Hi Johanna,
 
  I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
  noticed that new hosts have correct entries in the dnsmasq config-files.
  The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
  to deliver the new address. Instead dnsmasq logs claim no address
  available. Exactly like in your description.
  What distrubtion and exact dnsmasq-versions are in use on your
 environment?
  I assume dnsmasq is not rereading its configs correctly on signal HUP.
  dnsmasq logs claim it has reread configs, but it still does not deliver
  the new adresses in host-file.
  Manually trying to sigHUP dnsmasq had no effect. The only way to get out
  of this state seems to be restarting DHCP-agent.
 
  Best regards
  Thomas
 
  Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
  Hi,
 
  I have installed grizzly with quantum and ovs-plugin. It seems that
  grizzly allocates the third address of each subnet for dhcp. (In folsom
  it was the second address). This means that the VMs will get addresses
  .2, .4, .5, .
 
  In my setup the first VM always boots fine and gets the address
 x.x.x.2.
  This can be seen in the syslog:
 
  May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
  DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
  May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
  DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
  May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
  DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
  May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
  10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
 
  The problem comes when I start the second VM. Nova shows that the
  x.x.x.4 is allocated
 
  root@grizzly-236:~# nova list
 
 +--+--+++
  | ID   | Name | Status |
  Networks   |
 
 +--+--+++
  | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test   | ACTIVE |
  tenant1-net=10.20.30.2 |
  | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
  tenant1-net=10.20.30.4 |
 
 +--+--+++
 
  But from syslog I see that the answer to the DHCPDISCOVER is no
 address
  available
 
  May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:

[Openstack] Multipathing with Swift

2013-05-22 Thread Isidro Hortelano

Hey everyone,

do anyone know if multipathing is supported for Swift?


Regards,
___
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] DHCP problem in grizzly

2013-05-22 Thread Thomas Kärgel

Hi Marco,

can you also reproduce it?

If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
reproduce this behavior on the environment i'm woking on it will take
weeks to get to an really conclusive result.

Best regards
thomas


Am 22.05.2013 09:55, schrieb Marco Colombo:
 Hi All,
 i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
 killall dnsmasq  service quantum-dhcp-agent restart fixes the
 problem temporarily
 
 Best Regards,
 Marco
 
 
 
 
 2013/5/22 Thomas Kärgel kaer...@b1-systems.de
 mailto:kaer...@b1-systems.de
 
 Hi Johanna,
 
 sure, I'll report my results, but this can take a while. The last time
 this issue occurred on my environment is May 10th. It occurs quite
 sporadic and i don't know how to manually reproduce this issue yet (i
 have to be very careful with my experiments since the environment is
 running productive already). Maybe you should also give dnsmasq 2.66 a
 try, because you wrote that you can manually reproduce this behavior.
 
 
 Best Regards,
 Thomas
 
 
 Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
  Hi,
 
  You are right. Manually doing kill -HUP PID has just the effect
 you mentioned. In the syslog you can see
 
  May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
  May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
 /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
  May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
 /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
 
 
  But the problem stays. Only 'service quantum-dhcp-agent restart'
 fixes the problem.
  If you try the newer version of the qnsmasq, I'd be interested to
 hear the results.
 
  BR
  Johanna
 
 
 
  -Original Message-
  From: ext Thomas Kärgel [mailto:kaer...@b1-systems.de
 mailto:kaer...@b1-systems.de]
  Sent: Monday, May 20, 2013 11:37 AM
  To: Heinonen, Johanna (NSN - FI/Espoo)
  Cc: openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
  Subject: Re: [Openstack] DHCP problem in grizzly
 
  Hi,
 
  thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
  my environment. Can you can confirm that manually sigHUPing all
 running
  dnsmasq processes has no effect?
  (dnsmasq claims to have reread the configs in syslog, but still
 refuses
  to deliver the new addresses.)
  Maybe updating dnsmasq to a more recent release would solve our
 problem.
  Current stable is 2.66. I'll give it a try when i get back to office
  tomorrow.
 
  Best regards
 
  Thomas
 
 
  Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
  Hi Thomas,
 
  I am using Ubuntu12.04 and the dnsmasq version is 2.59
 
  BR
  Johanna
 
 
  -Original Message-
  From: Openstack [mailto:openstack-bounces+johanna.heinonen
 mailto:openstack-bounces%2Bjohanna.heinonen=nsn@lists.launchpad.net
 mailto:nsn@lists.launchpad.net] On Behalf Of ext Thomas Kärgel
  Sent: Monday, May 20, 2013 10:09 AM
  To: openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
  Subject: Re: [Openstack] DHCP problem in grizzly
 
  Hi Johanna,
 
  I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
  noticed that new hosts have correct entries in the dnsmasq
 config-files.
  The dnsmasq processes get a HUP signal by DHCP-Agent, but simply
 refuse
  to deliver the new address. Instead dnsmasq logs claim no address
  available. Exactly like in your description.
  What distrubtion and exact dnsmasq-versions are in use on your
 environment?
  I assume dnsmasq is not rereading its configs correctly on signal
 HUP.
  dnsmasq logs claim it has reread configs, but it still does not
 deliver
  the new adresses in host-file.
  Manually trying to sigHUP dnsmasq had no effect. The only way to
 get out
  of this state seems to be restarting DHCP-agent.
 
  Best regards
  Thomas
 
  Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
  Hi,
 
  I have installed grizzly with quantum and ovs-plugin. It seems that
  grizzly allocates the third address of each subnet for dhcp. (In
 folsom
  it was the second address). This means that the VMs will get
 addresses
  .2, .4, .5, .
 
  In my setup the first VM always boots fine and gets the address
 x.x.x.2.
  This can be seen in the syslog:
 
  May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
  DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
  May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
  DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
  May 20 08:29:23

Re: [Openstack] Memory requirements for OpenStack vs VM

2013-05-22 Thread JuanFra Rodriguez Cardoso

Hi Chris:

There are some nova config options aim to reserve resources for hosts:

reserved_host_memory_mb (default: 512 MB)
reserved_host_disk_mb (default: 0 MB)

Regards!
---
JuanFra


2013/5/21 Matthew Thode prometheanf...@gentoo.org

 On 05/21/13 12:24, Chris Bartels wrote:
  Hi,
 
 
 
  If I rent a VPS with 32GB RAM on a server that only has 32GB RAM in
 total,
  could OpenStack be choked for memory if the VPS tries to use up all that
  RAM, or will OpenStack be weighted to take priority over the memory the
  server has available?
 
 
 
  Should I only allocate 30GB to the VPS  leave OpenStack a 2GB minimum to
  work with just to be safe?
 
 
 
  Thanks,
 
  Chris
 
 
 
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~openstack
  More help   : https://help.launchpad.net/ListHelp
 
 You can likely use cgroups to give priority to memory used by openstack
 daemons.  Depends on how deep you want to get into it I guess (and your
 memory pressure).

 --
 -- Matthew Thode (prometheanfire)


 ___
 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] DHCP problem in grizzly

2013-05-22 Thread Marco Colombo

Hi Thomas,
i have upgrade dnsmasq to version 2.66, but the problem persist.
If you need more log/information, i'm able to reproduce the problem.

Thanks
Best Regards


2013/5/22 Thomas Kärgel kaer...@b1-systems.de

 Hi Marco,

 can you also reproduce it?

 If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
 reproduce this behavior on the environment i'm woking on it will take
 weeks to get to an really conclusive result.

 Best regards
 thomas


 Am 22.05.2013 09:55, schrieb Marco Colombo:
  Hi All,
  i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
  killall dnsmasq  service quantum-dhcp-agent restart fixes the
  problem temporarily
 
  Best Regards,
  Marco
 
 
 
 
  2013/5/22 Thomas Kärgel kaer...@b1-systems.de
  mailto:kaer...@b1-systems.de
 
  Hi Johanna,
 
  sure, I'll report my results, but this can take a while. The last
 time
  this issue occurred on my environment is May 10th. It occurs quite
  sporadic and i don't know how to manually reproduce this issue yet (i
  have to be very careful with my experiments since the environment is
  running productive already). Maybe you should also give dnsmasq 2.66
 a
  try, because you wrote that you can manually reproduce this behavior.
 
 
  Best Regards,
  Thomas
 
 
  Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
   Hi,
  
   You are right. Manually doing kill -HUP PID has just the effect
  you mentioned. In the syslog you can see
  
   May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
   May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
  /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
   May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
  /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
  
  
   But the problem stays. Only 'service quantum-dhcp-agent restart'
  fixes the problem.
   If you try the newer version of the qnsmasq, I'd be interested to
  hear the results.
  
   BR
   Johanna
  
  
  
   -Original Message-
   From: ext Thomas Kärgel [mailto:kaer...@b1-systems.de
  mailto:kaer...@b1-systems.de]
   Sent: Monday, May 20, 2013 11:37 AM
   To: Heinonen, Johanna (NSN - FI/Espoo)
   Cc: openstack@lists.launchpad.net
  mailto:openstack@lists.launchpad.net
   Subject: Re: [Openstack] DHCP problem in grizzly
  
   Hi,
  
   thx for the interesting info, Johanna: dnsmasq version is also
 2.59 on
   my environment. Can you can confirm that manually sigHUPing all
  running
   dnsmasq processes has no effect?
   (dnsmasq claims to have reread the configs in syslog, but still
  refuses
   to deliver the new addresses.)
   Maybe updating dnsmasq to a more recent release would solve our
  problem.
   Current stable is 2.66. I'll give it a try when i get back to
 office
   tomorrow.
  
   Best regards
  
   Thomas
  
  
   Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
   Hi Thomas,
  
   I am using Ubuntu12.04 and the dnsmasq version is 2.59
  
   BR
   Johanna
  
  
   -Original Message-
   From: Openstack [mailto:openstack-bounces+johanna.heinonen
  mailto:openstack-bounces%2Bjohanna.heinonen=
 nsn@lists.launchpad.net
  mailto:nsn@lists.launchpad.net] On Behalf Of ext Thomas Kärgel
   Sent: Monday, May 20, 2013 10:09 AM
   To: openstack@lists.launchpad.net
  mailto:openstack@lists.launchpad.net
   Subject: Re: [Openstack] DHCP problem in grizzly
  
   Hi Johanna,
  
   I'm facing the same behavior on a Folsom-installation on
 SLES11SP2. I
   noticed that new hosts have correct entries in the dnsmasq
  config-files.
   The dnsmasq processes get a HUP signal by DHCP-Agent, but simply
  refuse
   to deliver the new address. Instead dnsmasq logs claim no address
   available. Exactly like in your description.
   What distrubtion and exact dnsmasq-versions are in use on your
  environment?
   I assume dnsmasq is not rereading its configs correctly on signal
  HUP.
   dnsmasq logs claim it has reread configs, but it still does not
  deliver
   the new adresses in host-file.
   Manually trying to sigHUP dnsmasq had no effect. The only way to
  get out
   of this state seems to be restarting DHCP-agent.
  
   Best regards
   Thomas
  
   Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
   Hi,
  
   I have installed grizzly with quantum and ovs-plugin. It seems
 that
   grizzly allocates the third address of each subnet for dhcp. (In
  folsom
   it was the second address). This means that the VMs will get
  addresses
   .2, .4, .5, .
  
   In my setup the first VM

Re: [Openstack] Swift questions

2013-05-22 Thread Chmouel Boudjnah

On Wed, May 22, 2013 at 3:53 AM, Chuck Thier cth...@gmail.com wrote:
 It can be set to 1, and I think the default devstack install may do exactly
 that.


this is correct, this is the default devstack install to set one replica.

Chmouel.

___
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 questions

2013-05-22 Thread Mark Brown

Thank you for the responses Chuck.

As part of a rebalance, the replicator, I would assume, copies the object from 
the old partition to the new partition, and then deletes it from the old 
partition. Is that a fair assumption?

Also, is there anything that explains in more detail how the handoff node is 
picked? What if the ring changes and the data still lives on the handoff node? 

-- Mark



 From: Chuck Thier cth...@gmail.com
To: Mark Brown ntdeveloper2...@yahoo.com 
Cc: Openstack openstack@lists.launchpad.net 
Sent: Tuesday, May 21, 2013 6:53 PM
Subject: Re: [Openstack] Swift questions
 


Hi Mark,


On Tue, May 21, 2013 at 6:46 PM, Mark Brown ntdeveloper2...@yahoo.com wrote:

Hello,
I had a few more basic Swift questions..


1. In Swift, when a rebalance is happening, does the client have write access 
to the object? Does Swift have a mechanism to lock down one copy which it is 
moving, and allow updates to the remaining two copies and do a final sync 
somehow? What is the mechanism?
 
When the ring rebalances, it is allowed to only move one replica of a 
partition.  This guarantees that you still have 2 available while replication 
is moving the partitions around.

 
2. I did see that Swift has a configurable number of replicas. Can it be set to 
1? If it is set to 1, how does it work for the question above w.r.t rebalance? 
I do understand a single replica does not make sense, I did want to understand 
what it does in that case though.

It can be set to 1, and I think the default devstack install may do exactly 
that. Pretty much any guarantees of swift go out the window with 1 replica.  I 
would expect that the partitions that are being moved would not be available 
until replication has moved them.
 
3. If one of the nodes returns an error during a PUT(say, disk full), the 
request is sent to the handoff node, but how is the handoff node configured in 
the ring? Is it a special entry, or is it picked based on some algorithm or 
something else? 

There is an algorithm in the ring code that deterministically determines the 
handoff nodes.

--
Chuck___
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 questions

2013-05-22 Thread Chuck Thier

Hey Mark,

On Wed, May 22, 2013 at 8:59 AM, Mark Brown ntdeveloper2...@yahoo.comwrote:

 Thank you for the responses Chuck.

 As part of a rebalance, the replicator, I would assume, copies the object
 from the old partition to the new partition, and then deletes it from the
 old partition. Is that a fair assumption?


That is correct, the replicators will replicate the data in the partition
at the new location.  The server that has the old data will delete it once
it is certain that data is available in all replicas.


 Also, is there anything that explains in more detail how the handoff node
 is picked? What if the ring changes and the data still lives on the handoff
 node?


I don't think there is currently any documentation that describes how
handoff nodes are picked.  Handoff nodes can be used for a variety of
reasons, including when servers are down, or not responding.  The server
that has handoff partitions is always responsible for getting the data to
the correct location.

There is some more detailed information on replication at:

http://docs.openstack.org/developer/swift/overview_replication.html

(if you haven't read it yet)

--
Chuck
___
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] DHCP problem in grizzly

2013-05-22 Thread Thomas Kärgel

Hi Marco,

thanks for the interesting information. I think we can be sure now that
this is a bug in dnsmasq. I'll go ahead and report this bug to the
dnsmasq-developers tomorrow morning. Hopefully they can fix this issue soon.
I'll report the details when the bugreport is open. Maybe they want more
infos from us...

Best regards
Thomas

Am 22.05.2013 14:33, schrieb Marco Colombo:
 Hi Thomas,
 i have upgrade dnsmasq to version 2.66, but the problem persist.
 If you need more log/information, i'm able to reproduce the problem.
 
 Thanks
 Best Regards
 
 
 2013/5/22 Thomas Kärgel kaer...@b1-systems.de
 mailto:kaer...@b1-systems.de
 
 Hi Marco,
 
 can you also reproduce it?
 
 If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
 reproduce this behavior on the environment i'm woking on it will take
 weeks to get to an really conclusive result.
 
 Best regards
 thomas
 
 
 Am 22.05.2013 09:55, schrieb Marco Colombo:
  Hi All,
  i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
  killall dnsmasq  service quantum-dhcp-agent restart fixes the
  problem temporarily
 
  Best Regards,
  Marco
 
 
 
 
  2013/5/22 Thomas Kärgel kaer...@b1-systems.de
 mailto:kaer...@b1-systems.de
  mailto:kaer...@b1-systems.de mailto:kaer...@b1-systems.de
 
  Hi Johanna,
 
  sure, I'll report my results, but this can take a while. The
 last time
  this issue occurred on my environment is May 10th. It occurs quite
  sporadic and i don't know how to manually reproduce this issue
 yet (i
  have to be very careful with my experiments since the
 environment is
  running productive already). Maybe you should also give
 dnsmasq 2.66 a
  try, because you wrote that you can manually reproduce this
 behavior.
 
 
  Best Regards,
  Thomas
 
 
  Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
   Hi,
  
   You are right. Manually doing kill -HUP PID has just the
 effect
  you mentioned. In the syslog you can see
  
   May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
   May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
  /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
   May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
  /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
  
  
   But the problem stays. Only 'service quantum-dhcp-agent restart'
  fixes the problem.
   If you try the newer version of the qnsmasq, I'd be
 interested to
  hear the results.
  
   BR
   Johanna
  
  
  
   -Original Message-
   From: ext Thomas Kärgel [mailto:kaer...@b1-systems.de
 mailto:kaer...@b1-systems.de
  mailto:kaer...@b1-systems.de mailto:kaer...@b1-systems.de]
   Sent: Monday, May 20, 2013 11:37 AM
   To: Heinonen, Johanna (NSN - FI/Espoo)
   Cc: openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
  mailto:openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
   Subject: Re: [Openstack] DHCP problem in grizzly
  
   Hi,
  
   thx for the interesting info, Johanna: dnsmasq version is
 also 2.59 on
   my environment. Can you can confirm that manually sigHUPing all
  running
   dnsmasq processes has no effect?
   (dnsmasq claims to have reread the configs in syslog, but still
  refuses
   to deliver the new addresses.)
   Maybe updating dnsmasq to a more recent release would solve our
  problem.
   Current stable is 2.66. I'll give it a try when i get back
 to office
   tomorrow.
  
   Best regards
  
   Thomas
  
  
   Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
   Hi Thomas,
  
   I am using Ubuntu12.04 and the dnsmasq version is 2.59
  
   BR
   Johanna
  
  
   -Original Message-
   From: Openstack [mailto:openstack-bounces+johanna.heinonen
 mailto:openstack-bounces%2Bjohanna.heinonen
  mailto:openstack-bounces%2Bjohanna.heinonen
 
 mailto:openstack-bounces%252Bjohanna.heinonen=nsn@lists.launchpad.net
 mailto:nsn@lists.launchpad.net
  mailto:nsn@lists.launchpad.net
 mailto:nsn@lists.launchpad.net] On Behalf Of ext Thomas Kärgel
   Sent: Monday, May 20, 2013 10:09 AM
   To: openstack@lists.launchpad.net
 mailto:openstack@lists.launchpad.net
  mailto:openstack@lists.launchpad.net

Re: [Openstack] [Quantum OVS] How to bi-direction communicate between VM instances and old LAN network(s)

2013-05-22 Thread Naveen Joy (najoy)

Hi Chu,

I was able to get my instances and  LAN servers communicate by following the 
below steps. The basic idea is that you should add the external network 
interface to br-ex,  then create an external network in quantum with 
--router:external=True and allocate floating IPs to your instances from this 
external network. Now your LAN servers can talk to your instances using these 
routable floating IPs that you have allocated from the external network.

Steps:

1.  Create an external bridge named br-ex and add the network card to that 
bridge. Also assign an IP on the external bridge so you can manage it. Assuming 
eth1 is your network card.

sudo ovs-vsctl add-br br-ex

sudo ovs-vsctl add-port br-ex eth1

sudo ip addr add ip/mask dev br-ex

sudo ip link set br-ex up



2.  Set eth1 as a promiscuous interface in Ubuntu with no IP address so 
your host OS does not mess with it.

Edit your /etc/network/interfaces and add the below lines:

iface eth1 inet manual

up ifconfig $IFACE 0.0.0.0 up

up ifconfig $IFACE promisc

down ifconfig $IFACE down

3.  Create a shared public network and subnet for your tenant routers to 
plug in.

Note that this network should be mapped to your existing LAN network and you 
should also set an existing gateway and assign IP allocation pools.

quantum net-create public --shared --router:external=True 
--provider:network_type local

quantum subnet-create --name public-subnet --gateway gateway-ip  
--allocation-pool start=start-ip,end=end-ip public 
external-LAN-subnet/mask



4.  Then set an external gateway IP for your tenant routers and create your 
user nets

quantum router-create router1

quantum router-gateway-set router1 public

quantum net-create usernet1

quantum subnet-create --name subnet1 usernet1 10.0.0.0/24

quantum router-interface-add router1 subnet1



5.  To enable bi-directional network communication your old LAN network 
server farm use floating IPs. Allocate a floating IP and map it to your 
instance port either using command line or via horizon.

quantum floatingip-create --port_id $SERVER_PORT_ID public

Hope this helps.

Naveen/


From: Openstack [mailto:openstack-bounces+najoy=cisco@lists.launchpad.net] 
On Behalf Of Chu Duc Minh
Sent: Wednesday, May 22, 2013 5:04 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] [Quantum  OVS] How to bi-direction communicate between VM 
instances and old LAN network(s)

Hi, i deployed a Openstack Grizzly cluster with Quantum using network-model 
Per-tenant Routers with Private Networks. Everything is ok.
Now, i need to communicate (bi-direction) between VM network(s) and old LAN 
network(s) of old server farm. (192.168.2.0/24http://192.168.2.0/24, 
192.168.3.0/24http://192.168.3.0/24, v.v...)
I added a network card to Network-node and plug it to a LAN network 
(192.168.3.0/24http://192.168.3.0/24).
But still not yet figured out how i can achieve it (old server farm can connect 
to VM instance and vice-versa)
Could you help me, pls? Thanks a lot, folks!
PS: I attach my network topology in this mail for reference.
I think that, maybe I need to create a new br-ex for LAN, create 
port/interface in router of each tenant, then add a LAN IP (192.168.3.x) to 
router-interface.
Then add route to 192.168.0.0/16http://192.168.0.0/16 to 192.168.3.1
v.v

But how to implement it still not clear... :-(


___
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] Fwd: [openstack-dev] [Heat] Running latest Heat against older OpenStacks

2013-05-22 Thread Steve Baker

Reposting here since this is mostly user related.


 Original Message 
Subject:[openstack-dev] [Heat] Running latest Heat against older
OpenStacks
Date:   Wed, 22 May 2013 14:46:19 +1200
From:   Steve Baker sba...@redhat.com
Reply-To:   OpenStack Development Mailing List
openstack-...@lists.openstack.org
To: openstack-...@lists.openstack.org



At the Design Summit a number of people mentioned that they would like
to run the latest release of Heat against their own installation of an
older OpenStack release.

As a project we're not against this in principle, however we don't
currently have the resources to develop or test against anything other
than latest OpenStack (unless by coincidence of the provided dev
environment).

It would be very useful to us for people to describe their use cases for
running Heat against older OpenStack installations - feel free to
contribute them to this thread.

We're about to have the beginnings of some Tempest integration tests[1].
I'd like to suggest that these be used as a coordination point for
testing latest Heat against private installations. For those running
Heat against older OpenStack installations the following would be done:
- Run the heat tempest tests against your own Heat/OpenStack environment
- Participate in finding and fixing regressions that appear in your own
environment (bug reports good, failing tempest tests better, fixes best)

There are a couple of caveats worth mentioning:
- the transition from our own CloudWatch-lite alarming to ceilometer
might be messy - there might be a limit to how much we can mitigate the pain
- it seems reasonable for latest heat to depend on the latest released
client libs. Any regressions involving recent client libs running on
older APIs probably need to be taken to those client projects.

In the medium to long term we have some roadmap items which have
implications here, including:
- a local installation of Heat configured to point at a public OpenStack
cloud - auth and other quirks of each cloud need to be handled
- a single installation of Heat which can deploy to multiple clouds
(private and public)
- Heat DSL concepts [2] of Providers and Environments should allow Heat
to change any aspect of its behavior to support older installations.

[1] https://review.openstack.org/#/q/topic:bp/add-basic-heat-tests,n,z
[2] https://wiki.openstack.org/wiki/Heat/DSL

___
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] [Glance] Reuse the image id when recreate an image in Glance which had been deleted

2013-05-22 Thread Robert Collins

On 17 May 2013 02:38, Fei Long Wang flw...@cn.ibm.com wrote:
 Hi stackers,

 Now I'm running into an issue about reusing image id in Glance. Based on
 current design, the image id can be specified during create image by end
 user. But now there is a problem, which is tracked by defect


...


various services use the image UUID as a key for caches on disk.
Reusing that seems like a catastrophic event, not to mention a clear
security attack vector.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Cloud Services

___
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 Agents and Reporting State

2013-05-22 Thread Craig E. Ward

I'm configuring a single-node installation of the Grizzly release and I am 
having some strange issues with the Quantum agents.


The install using quantum-linuxbridge-agent, quantum-l3-agent, and 
quantum-dhcp-agent. Each on is logging the error:


   Failed reporting state!

The end of the stack trace indicates that the number arguments to some call was 
incorrect.


dhcp-agent:TypeError: lambda() takes exactly 2 arguments (3 given)
l3_agent:  TypeError: lambda() takes exactly 2 arguments (3 given)
linuxbridge-agent: TypeError: lambda() takes exactly 2 arguments (3 given)

The services are connecting to the RabbitMQ server. Does this indicate a 
mismatch in some driver that sites between the agents and the RabbitMQ server?


Has anyone else seen this type of error before?

The packages I'm using are openstack-quantum-2013.1-3.el6.noarch and 
openstack-quantum-linuxbridge-2013.1-3.el6.noarch.


Any suggestions will be appreciated.

Thanks,

Craig

--
Craig E. Ward
USC Information Sciences Institute
cw...@isi.edu


___
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 questions

2013-05-22 Thread Mark Brown

Thanks Chuck.

Just one more question about rebalancing. Have there been measurements on how 
much it affects performance when a rebalance is in progress? I would assume its 
an operation that puts some load on the system, while also keeping track of  
whether the original object changed while moving, among other things. Its 
probably not that frequent, but it would be great to understand how it works in 
the real world with large workloads.

I did have a general question about container sync. Is it something that is 
used a lot, and works well?

-- Mark



 From: Chuck Thier cth...@gmail.com
To: Mark Brown ntdeveloper2...@yahoo.com 
Cc: Openstack openstack@lists.launchpad.net 
Sent: Wednesday, May 22, 2013 7:26 AM
Subject: Re: [Openstack] Swift questions
 


Hey Mark,
On Wed, May 22, 2013 at 8:59 AM, Mark Brown ntdeveloper2...@yahoo.com wrote:

Thank you for the responses Chuck.


As part of a rebalance, the replicator, I would assume, copies the object from 
the old partition to the new partition, and then deletes it from the old 
partition. Is that a fair assumption?

That is correct, the replicators will replicate the data in the partition at 
the new location.  The server that has the old data will delete it once it is 
certain that data is available in all replicas.
 
Also, is there anything that explains in more detail how the handoff node is 
picked? What if the ring changes and the data still lives on the handoff node? 

I don't think there is currently any documentation that describes how handoff 
nodes are picked.  Handoff nodes can be used for a variety of reasons, 
including when servers are down, or not responding.  The server that has 
handoff partitions is always responsible for getting the data to the correct 
location.

There is some more detailed information on replication at: 

http://docs.openstack.org/developer/swift/overview_replication.html

(if you haven't read it yet)

--
Chuck___
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 Agents and Reporting State

2013-05-22 Thread gong yong sheng

It seems there is a gap between these two packages, can u upgrade the 
openstack quantum to latest git repo?

On 05/23/2013 08:08 AM, Craig E. Ward wrote:
I'm configuring a single-node installation of the Grizzly release and 
I am having some strange issues with the Quantum agents.


The install using quantum-linuxbridge-agent, quantum-l3-agent, and 
quantum-dhcp-agent. Each on is logging the error:


   Failed reporting state!

The end of the stack trace indicates that the number arguments to some 
call was incorrect.


dhcp-agent:TypeError: lambda() takes exactly 2 arguments (3 
given)
l3_agent:  TypeError: lambda() takes exactly 2 arguments (3 
given)
linuxbridge-agent: TypeError: lambda() takes exactly 2 arguments (3 
given)


The services are connecting to the RabbitMQ server. Does this indicate 
a mismatch in some driver that sites between the agents and the 
RabbitMQ server?


Has anyone else seen this type of error before?

The packages I'm using are openstack-quantum-2013.1-3.el6.noarch and 
openstack-quantum-linuxbridge-2013.1-3.el6.noarch.


Any suggestions will be appreciated.

Thanks,

Craig




___
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 questions

2013-05-22 Thread Chuck Thier

On Wed, May 22, 2013 at 7:54 PM, Mark Brown ntdeveloper2...@yahoo.comwrote:

 Thanks Chuck.

 Just one more question about rebalancing. Have there been measurements on
 how much it affects performance when a rebalance is in progress? I would
 assume its an operation that puts some load on the system, while also
 keeping track of  whether the original object changed while moving, among
 other things. Its probably not that frequent, but it would be great to
 understand how it works in the real world with large workloads.


There are no exact measurements on how it affects performance.  A lot of it
depends on how aggressively you are re-balancing, size of the cluster,
usage, etc.  A lot of replication will increase the amount of network
traffic going on and disk io.


 I did have a general question about container sync. Is it something that
 is used a lot, and works well?


I have heard of some using it successfully, but it does have some issues,
so I personally wouldn't recommend it beyond experimentation, and small
clusters.

--
Chuck
___
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 OVS] How to bi-direction communicate between VM instances and old LAN network(s)

2013-05-22 Thread Chu Duc Minh

Hi, thank you for your help, but I can't follow your guides because I
already have an external network (123.x.y.0/24)

I tried some ways to add 2 floating IP(s) (belong to 2 network/subnet) to
an instance, but still not success...

Do you or others have another idea?

Thank you very much!




On Thu, May 23, 2013 at 12:40 AM, Naveen Joy (najoy) na...@cisco.comwrote:

  Hi Chu,

 ** **

 I was able to get my instances and  LAN servers communicate by following
 the below steps. The basic idea is that you should add the external network
 interface to br-ex,  then create an external network in quantum with
 --router:external=True and allocate floating IPs to your instances from
 this external network. Now your LAN servers can talk to your instances
 using these routable floating IPs that you have allocated from the external
 network.

 ** **

 Steps:

 **1.  **Create an external bridge named br-ex and add the network
 card to that bridge. Also assign an IP on the external bridge so you can
 manage it. Assuming eth1 is your network card.

 sudo ovs-vsctl add-br br-ex

 sudo ovs-vsctl add-port br-ex eth1

 sudo ip addr add ip/mask dev br-ex

 sudo ip link set br-ex up

 ** **

 **2.  **Set eth1 as a promiscuous interface in Ubuntu with no IP
 address so your host OS does not mess with it.

 Edit your /etc/network/interfaces and add the below lines:

 iface eth1 inet manual

 up ifconfig $IFACE 0.0.0.0 up

 up ifconfig $IFACE promisc

 down ifconfig $IFACE down

 

 **3.  **Create a shared public network and subnet for your tenant
 routers to plug in. 

 Note that this network should be mapped to your existing LAN network and
 you should also set an existing gateway and assign IP allocation pools.***
 *

 quantum net-create public --shared --router:external=True
 --provider:network_type local

 quantum subnet-create --name public-subnet --gateway gateway-ip
  --allocation-pool start=start-ip,end=end-ip public
 external-LAN-subnet/mask

 ** **

 **4.  **Then set an external gateway IP for your tenant routers and
 create your user nets

 quantum router-create router1

 quantum router-gateway-set router1 public

 quantum net-create usernet1

 quantum subnet-create --name subnet1 usernet1 10.0.0.0/24

 quantum router-interface-add router1 subnet1

 ** **

 **5.  **To enable bi-directional network communication your old LAN
 network server farm use floating IPs. Allocate a floating IP and map it to
 your instance port either using command line or via horizon.

 quantum floatingip-create --port_id $SERVER_PORT_ID public

 ** **

 Hope this helps.

 ** **

 Naveen/

 ** **

 ** **

 *From:* Openstack [mailto:openstack-bounces+najoy=
 cisco@lists.launchpad.net] *On Behalf Of *Chu Duc Minh
 *Sent:* Wednesday, May 22, 2013 5:04 AM
 *To:* openstack@lists.launchpad.net
 *Subject:* [Openstack] [Quantum  OVS] How to bi-direction communicate
 between VM instances and old LAN network(s)

 ** **

 Hi, i deployed a Openstack Grizzly cluster with Quantum using
 network-model *Per-tenant Routers with Private Networks*. Everything is
 ok. 

 Now, i need to communicate (bi-direction) between VM network(s) and old
 LAN network(s) of old server farm. (192.168.2.0/24, 192.168.3.0/24,
 v.v...)

 I added a network card to Network-node and plug it to a LAN network (
 192.168.3.0/24).
 But still not yet figured out how i can achieve it (old server farm can
 connect to VM instance and vice-versa) 

 Could you help me, pls? Thanks a lot, folks!

 *PS:* I attach my network topology in this mail for reference. 

 I think that, maybe I need to create a new br-ex for LAN, create
 port/interface in router of each tenant, then add a LAN IP (192.168.3.x) to
 router-interface.
 Then add route to 192.168.0.0/16 to 192.168.3.1
 v.v

 But how to implement it still not clear... :-(

 ** **

 ** **

___
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 OVS] How to bi-direction communicate between VM instances and old LAN network(s)

2013-05-22 Thread Ashok Kumaran

Hi Chu,

You might want to check this link.

http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_multi_extnet.html

you can create multiple floating ip pools in association with different ext
nets

-Ashok

On Thu, May 23, 2013 at 10:38 AM, Chu Duc Minh chu.ducm...@gmail.comwrote:

Hi, thank you for your help, but I can't follow your guides because I
already have an external network (123.x.y.0/24)

I tried some ways to add 2 floating IP(s) (belong to 2 network/subnet) to
an instance, but still not success...

Do you or others have another idea?

Thank you very much!

On Thu, May 23, 2013 at 12:40 AM, Naveen Joy (najoy) na...@cisco.comwrote:

Hi Chu,

** **

I was able to get my instances and LAN servers communicate by following
the below steps. The basic idea is that you should add the external network
interface to br-ex, then create an external network in quantum with
--router:external=True and allocate floating IPs to your instances from
this external network. Now your LAN servers can talk to your instances
using these routable floating IPs that you have allocated from the external
network.

** **

Steps:

**1. **Create an external bridge named br-ex and add the network
card to that bridge. Also assign an IP on the external bridge so you can
manage it. Assuming eth1 is your network card.

sudo ovs-vsctl add-br br-ex

sudo ovs-vsctl add-port br-ex eth1

sudo ip addr add ip/mask dev br-ex

sudo ip link set br-ex up

** **

**2. **Set eth1 as a promiscuous interface in Ubuntu with no IP
address so your host OS does not mess with it.

Edit your /etc/network/interfaces and add the below lines:

iface eth1 inet manual

up ifconfig $IFACE 0.0.0.0 up

up ifconfig $IFACE promisc

down ifconfig $IFACE down

**3. **Create a shared public network and subnet for your tenant
routers to plug in.

Note that this network should be mapped to your existing LAN network and
you should also set an existing gateway and assign IP allocation pools.**
**

quantum net-create public --shared --router:external=True
--provider:network_type local

quantum subnet-create --name public-subnet --gateway gateway-ip
--allocation-pool start=start-ip,end=end-ip public
external-LAN-subnet/mask

** **

**4. **Then set an external gateway IP for your tenant routers and
create your user nets

quantum router-create router1

quantum router-gateway-set router1 public

quantum net-create usernet1

quantum subnet-create --name subnet1 usernet1 10.0.0.0/24

quantum router-interface-add router1 subnet1

** **

**5. **To enable bi-directional network communication your old LAN
network server farm use floating IPs. Allocate a floating IP and map it to
your instance port either using command line or via horizon.

quantum floatingip-create --port_id $SERVER_PORT_ID public

** **

Hope this helps.

** **

Naveen/

** **

*From:* Openstack [mailto:openstack-bounces+najoy=
cisco@lists.launchpad.net] *On Behalf Of *Chu Duc Minh
*Sent:* Wednesday, May 22, 2013 5:04 AM
*To:* openstack@lists.launchpad.net
*Subject:* [Openstack] [Quantum OVS] How to bi-direction communicate
between VM instances and old LAN network(s)

** **

Hi, i deployed a Openstack Grizzly cluster with Quantum using
network-model *Per-tenant Routers with Private Networks*. Everything
is ok.

Now, i need to communicate (bi-direction) between VM network(s) and old
LAN network(s) of old server farm. (192.168.2.0/24, 192.168.3.0/24,
v.v...)

I added a network card to Network-node and plug it to a LAN network (
192.168.3.0/24).
But still not yet figured out how i can achieve it (old server farm can
connect to VM instance and vice-versa)

Could you help me, pls? Thanks a lot, folks!

*PS:* I attach my network topology in this mail for reference.

I think that, maybe I need to create a new br-ex for LAN, create
port/interface in router of each tenant, then add a LAN IP (192.168.3.x) to
router-interface.
Then add route to 192.168.0.0/16 to 192.168.3.1
v.v

But how to implement it still not clear... :-(

** **

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

--
Regds,

Ashok ,
Delivery Consultant,
HP.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

70 matches

Mail list logo