date:20130513

Re: [Openstack] Swift questions - container sync

2013-05-13 Thread Mark Brown



Has anyone used container sync in their implementations? It would be great to 
know your experiences, because real world use case studies are scarce:) 
Anything to be aware of, whether its performance, setup, problems seen, 
recommendations..?

--Mark


 From: Mark Brown ntdeveloper2...@yahoo.com
To: David Hadas dav...@il.ibm.com 
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
Sent: Sunday, May 12, 2013 11:25 PM
Subject: Re: [Openstack] Swift questions.
 


Thanks again, David. Definitely helps.

Is the alternative node you refer to here the handoff node? Is the handoff 
node something that is in the ring database? I am trying to piece together 
where in the stack this would happen. If it is transparent, it would probably 
happen in the object server somehow, but it would need to know where the 
handoff node is.

-- Mark.



 From: David Hadas dav...@il.ibm.com
To: Mark Brown ntdeveloper2...@yahoo.com 
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
Sent: Sunday, May 12, 2013 11:13 PM
Subject: Re: [Openstack] Swift questions.
 


Mark, 

It would mark the server as having insufficient storage (to avoid retrying the 
same server for a while) and try to place the object in an alternative node -  
same as it would do with any other error. Once the object is placed in an 
alternative node, the alternative node would try to send the object back to its 
originated place every once in a while such that if the problem is reolved, it 
will move to the right place. 

This being said, there are N replicas - and this would repeat for each of the N 
replicas. So if one server is full you can still access the data using the 
other N-1 replicas and you still maintain N replicas in your system of the 
object (although one of them is misplaced until the administrator would
 resolve the space issue). 

Swift doe snot use df, it would try to allocate the space on the disk and if it 
fails it fails.
Failure is just a natural part of live as far as swift is concerned ;)

Hope this helps. 

DH



Regards, 
David Hadas
Research Staff Member, Master Inventor

IBM Research Labs, Haifa
Tel:Int+972-4-829-6104
Fax:   Int+972-4-829-6112

-Mark Brown ntdeveloper2...@yahoo.com wrote: -
To: David Hadas/Haifa/IBM@IBMIL
From: Mark Brown ntdeveloper2...@yahoo.com
Date: 05/12/2013 08:27PM
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] Swift questions.


Thanks for the response David.

I do understand Swift, by its design, tries to keep things in balance among 
various nodes. I was curious what it does when it encounters a full 
partition(say hard disk is full)? Lets just say it is balanced and the all 
nodes are nearing capacity. If I dont add any nodes, what happens when it tries 
to write on a specific node (which it was directed to based on the hashing 
ring) and there is not enough space to write the object?

Also, what does it use to determine a full partition? Does it use a df? 

Mark



 From: David Hadas dav...@il.ibm.com
To: Mark Brown ntdeveloper2...@yahoo.com 
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net 
Sent: Sunday, May 12, 2013 10:36 PM
Subject: Re: [Openstack] Swift questions.
 


Mark, 

Regarding your first Q:

Swift evenly balance the hard-drives such that in a correctly configured 
system, you should expect one hard-drive being more full than the other. 
There is manual a mechanism in swift to balance hard-drives by moving partitions
 to/from hard-drive but you should need to use it under normal conditions, it 
is likely that if your had-drives get full the right thing to do would be to 
add more hard-drives.

In any case you should care not about individual partitions 'getting full' as 
partitions are not allocated any specific space and can grow and shrink as 
needed as long as the hard-drive they are in have space.


DH



Regards, 
David Hadas
Research Staff Member, Master Inventor

IBM Research Labs, Haifa
Tel:Int+972-4-829-6104
Fax:   Int+972-4-829-6112

-Openstack openstack-bounces+davidh=il.ibm@lists.launchpad.net 
wrote: -
To: openstack@lists.launchpad.net openstack@lists.launchpad.net
From: Mark Brown 
Sent by: Openstack 
Date:
 05/12/2013 07:50PM
Subject: [Openstack] Swift questions.


Hello guys,
Been looking at Swift for some projects, and had some very basic questions.

1. How does Swift determine a certain partition is full? And when it does 
detect that, what does it do? Does it return an error to the client?

2. Regarding container sync, has anyone used container sync in their 
implementations? It would be great to know your experiences, because real world 
use case studies are scarce:)


-- Mark

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

[Openstack] Safe to expose various ports to the public (5000, 8774, etc, and via NAT)?

2013-05-13 Thread Michael S. Moody

Something that doesn't seem to be well discussed is how safe Openstack
(and the corresponding services/API's) is to be exposed to the public.
For instance, how safe is it to expose port 5000 to the general
public? Port 8774?

Right now, the only thing we have exposed to the public is the Horizon
dashboard. Our controller current sits on a private LAN segment
(172.x.x.x). Anything that we do with the API, we utilize a VPN for
(for the moment).

So, how safe is it, and what can be safely exposed? We would like to
enable our users (even if it is closely controlled via hardware
firewall rules) to utilize the various API's.

On an alternate topic, since we utilizing hardware firewalls, and
thus, NAT, when we attempt to connect the the PUBLIC IP address (API,
say 5000), our connection stalls attempting to make a connection to
private_ip:8774. We assume this is what the public_endpoint directive
in keystone.conf is for?

(If it matters, we are running the Essex release on Ubuntu 12.04).

Michael

___
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] New code name for networks

2013-05-13 Thread Thierry Carrez

Anne Gentle wrote:
  I told Monty and the TC this at the Summit (sorry I couldn't attend the
  session about code names).
 
 I promise, it wasn't the world's most fun session. :)
 
 I'm sure. :) I think I don't have much regret but do feel sorry that I
 don't know more. 

The Etherpad is here:
https://etherpad.openstack.org/ProjectsReNaming

I think there is much more value to codenames than just avoiding the
cost of a rename when the project becomes OpenStack. This was captured
in the session:

Codenames drawbacks and benefits
(-) Lack of trademark protection
(-) Confusing to newcomers
(-) Shadow their more official counterparts
(+) Short names are highly-convenient and efficient, often less
ambiguous (in conversations, executables,  modules...)
(+) Help building project and team identity
(+) Separate the project itself from its functional scope (so they
remain valid even if that scope evolves)

Those last two bits are pretty essential. There is a reason why a
functional description cannot be used as a project name. The project (as
in, the code repository and the community of contributors around it) is
*distinct* from the functional scope of what its code does.

Take Ceilometer (OpenStack Metering). What happens when they grow to
cover Monitoring ? You rename the project to OpenStack Metering and
Monitoring ? Or you keep the partial functional description ? I'd
rather avoid to rename everything every time a project evolves. Those
renames are *extremely* costly, as we'll soon enough realize.

I find the confusing argument pretty weak myself. Brands are used
everywhere, so we are used to make the translation between a name and a
function. Microsoft named its desktop environment Windows, rather than
Operating system or Desktop environment, and it took people about 5
minutes to get used to it.

 Go with kumquat, but don't call the CLI kumquat. Call your team kumquat and 
 your repo kumquat. 

If you call the CLI os-metering, you'll have to rename it when the
scope expands, or live with a name that looks like a functional
description but is not an accurate one. I very much prefer to call it
ceilometer.

-- 
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] New code name for networks

2013-05-13 Thread MARGOLIN, Udi (Udi)

Since networks are moving quite rapidly, can be quite messy and its pretty
cold out there my suggestion is:

Blizzard

-Udi

-Original Message-
From: Openstack
[mailto:openstack-bounces+udi.margolin=alcatel-lucent@lists.launchpad.ne
t] On Behalf Of Thierry Carrez
Sent: Monday, May 13, 2013 12:47 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] New code name for networks

Anne Gentle wrote:
  I told Monty and the TC this at the Summit (sorry I couldn't attend 
  the session about code names).
 
 I promise, it wasn't the world's most fun session. :)
 
 I'm sure. :) I think I don't have much regret but do feel sorry that I 
 don't know more.

The Etherpad is here:
https://etherpad.openstack.org/ProjectsReNaming

I think there is much more value to codenames than just avoiding the cost
of a rename when the project becomes OpenStack. This was captured in the
session:

Codenames drawbacks and benefits
(-) Lack of trademark protection
(-) Confusing to newcomers
(-) Shadow their more official counterparts
(+) Short names are highly-convenient and efficient, often less ambiguous
(in conversations, executables,  modules...)
(+) Help building project and team identity
(+) Separate the project itself from its functional scope (so they remain
valid even if that scope evolves)

Those last two bits are pretty essential. There is a reason why a functional
description cannot be used as a project name. The project (as in, the code
repository and the community of contributors around it) is
*distinct* from the functional scope of what its code does.

Take Ceilometer (OpenStack Metering). What happens when they grow to cover
Monitoring ? You rename the project to OpenStack Metering and Monitoring ?
Or you keep the partial functional description ? I'd rather avoid to rename
everything every time a project evolves. Those renames are *extremely*
costly, as we'll soon enough realize.

I find the confusing argument pretty weak myself. Brands are used
everywhere, so we are used to make the translation between a name and a
function. Microsoft named its desktop environment Windows, rather than
Operating system or Desktop environment, and it took people about 5
minutes to get used to it.

 Go with kumquat, but don't call the CLI kumquat. Call your team kumquat
and your repo kumquat. 

If you call the CLI os-metering, you'll have to rename it when the scope
expands, or live with a name that looks like a functional description but is
not an accurate one. I very much prefer to call it ceilometer.

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


smime.p7s
Description: S/MIME cryptographic 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] New code name for networks

2013-05-13 Thread Thierry Carrez

Monty Taylor wrote:
 So, with all due respect to the many awesome lawyers who are involved with 
 the project, what I'm getting at is that we need to do the right thing as 
 best we can based on unofficial advice from well meaning people who may or 
 may not have legal backgrounds as well as input and help from Jonathan Bryce 
 and the foundation board where appropriate.

FWIW Mark McLoughlin tried to organize a bit that unofficial advice
and set up a legal-discuss mailing-list where this unofficial advice
can be easily and publicly discussed.

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

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee

___
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] [OSSG][OSSN] Keystone configuration should not be world readable.

2013-05-13 Thread Clark, Robert Graham

Keystone configuration should not be world readable
---

### Summary ###
In some deployments keystone.conf which contains confidential information, is 
set to world readable.

### Affected Services / Software ###
Keystone, DevStack, Deployment

### Discussion ###
It is important that deployers of OpenStack ensure that keystone.conf is not 
world readable. In some deployments the keystone configuration file is readable 
by all users (and processes) on the installation system. This file should be 
set with the most restrictive permissions that allow the system to continue 
proper operations.

In particular, the password configuration of the LDAP section and the 
admin_token contain secret information:

 being example config snippet 
[ldap]
url = ldap://localhost
user = dc=Manager,dc=example,dc=com
password = None - should be secret
suffix = cn=example,cn=com
use_dumb_member = False
allow_subtree_delete = False
dumb_member = cn=dumb,dc=example,dc=com

[DEFAULT]
admin_token = passw0rd - should be secret
 end example config snippet 

### Recommended Actions ###
Ensure that in your deployment keystone.conf uses the most restrictive 
permissions that allow the system to continue proper operations.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1168252
Original LaunchPad Bug : https://bugs.launchpad.net/devstack/+bug/1168252
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-1977


___
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 Marketing] New code name for networks

2013-05-13 Thread Jason Smith

Hello Stefano,
Thank you for the information. 

I apologize for cross-posting. I'll make sure and stay away from that in the 
future. 

Thanks,
-js

-- Typo's courtesy of Apple --

On May 12, 2013, at 11:58 PM, Stefano Maffulli stef...@openstack.org wrote:

 Hi Jason,
 
 thank you for picking up this topic: some people may not be aware of the work 
 that is happening.
 
 Remember that cross-posting is *evil*: please just don't do it. The best way 
 is to pick one list, the one you think is the best place to start a 
 conversation, and start there. If it's the wrong place, somebody will tell 
 you that and give suggestions.
 
 On 05/11/2013 12:50 PM, Jason Smith wrote:
  Hello, I understand why we had to give up Quantum code name but
  rather than just refer to it as networking let's come up with a new
  code name!
 
 This could have been a topic for openstack-dev, IMHO: it needs to be 
 discussed among the developers because it has lots of technical implications 
 for future of the project.
 
 Anyway, there is a blueprint filed:
 
 https://blueprints.launchpad.net/quantum/+spec/remove-use-of-quantum
 
 and the progress is tracked at the weekly meetings. I encourage you to
 participate to them:
 
 https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting
 
 In the past meeting
 
 http://eavesdrop.openstack.org/meetings/project/2013/project.2013-05-07-21.02.log.html
 
 Mark McClain said:
 
 21:31:18 markmcclain for naming? yes.. will submit a list of name for 
 vetting
 
 I guess the marketing team can be consulted to help pick the final name from 
 the list, together with the other groups involved in this important decisions.
 
 Cheers,
 stef
 
 -- 
 Ask and answer questions on https://ask.openstack.org

___
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] Grizzly on Laptop running Ubuntu 12.04 Desktop 64-bit and having 2 NICs (one Ethernet and other Wireless)

2013-05-13 Thread Devendra Gupta

Hi,

I am setting up Grizzly in single node on my laptop running Ubuntu
12.04 Desktop 64-bit for POC, I am using a doc which say 2 NICs are
required (please see
https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_SingleNode/OpenStack_Grizzly_Install_Guide.rst
doc).

I have two NICs in my laptop one is Ethernet and other is Wireless so
is it fine to setup the environment on it ? Another thing, what if I
am disconnected from any of the network because then I don't have IP
in that specific NIC ?

Please see the result of ifconfig below (when network is connected):

root@devendra-HP-ProBook-6460b:/home/devendra# ifconfig -a
eth0  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
  inet addr:10.128.249.72  Bcast:10.128.249.255  Mask:255.255.254.0
  inet6 addr: fe80::2e41:38ff:fe00:ab9d/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:7026 errors:0 dropped:155 overruns:0 frame:0
  TX packets:4870 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3349362 (3.3 MB)  TX bytes:1076679 (1.0 MB)
  Interrupt:20 Memory:d470-d472

eth1  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
  inet addr:172.16.3.152  Bcast:172.16.3.255  Mask:255.255.255.0
  inet6 addr: fe80::ae81:12ff:fe91:6efa/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:15 errors:0 dropped:0 overruns:0 frame:0
  TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:6392 (6.3 KB)  TX bytes:9341 (9.3 KB)
  Interrupt:19

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:15737 errors:0 dropped:0 overruns:0 frame:0
  TX packets:15737 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:1884492 (1.8 MB)  TX bytes:1884492 (1.8 MB)

So my OpenStack environment would be working in case IP is not
available on any/both of the NICs when network is disconnected ?
Please suggest.

Thanks,
Devendra Gupta

___
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] New code name for networks

2013-05-13 Thread Doug Hellmann

On Sat, May 11, 2013 at 5:48 PM, Anne Gentle a...@openstack.org wrote:




 On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust.comwrote:



 On 05/11/2013 04:07 PM, Asher Newcomer wrote:
  Or even better, just continue to call it openstack networking. The code
  names only serve to confuse the uninitiated. They needlessly steepen the
  learning curve and slow uptake.

 The problem with OpenStack Networking (or getting rid of codenames) is
 seen with pre-incubation-incubation-integrated cycle.

 A project cannot call itself OpenStack Foo until it actually _is_
 openstack foo. So any new project by necessity has to start off as
 something else.

 But - if we then require them to drop that name and become openstack foo
 when they become incubated or integrated, then we've got what's become a
 stable project with a decent amount of contributors renaming itself.

 Every. Time.

 The code names aren't just cute. I kind of wish they were, because it
 would make several things much easier if we could just ditch them and do
 a pure openstack. code namespace. But the reality is that it gets really
 really tricky to deal with a bunch of things if they go away.


 I told Monty and the TC this at the Summit (sorry I couldn't attend the
 session about code names). I find this trickiness a weak argument in the
 face of the invented names that are getting to be as bad as U.S.
 pharmaceuticals. Plus it forces us to put a lookup table in the docs
 forever. [1] Let's find a process for naming that meets a few reqs:
 - describes the service
 - goes through a legal review
 - enables new eyes to understanding it by reading the English word that
 the service represents (that can be translated into a meaningful word in
 other languages)

 If we have to preface with Stackforge to indicate pre-incubation, that's
 fine. Use Incubating or some such to indicate incubation. Meaningful words
 have meaning.


+1

Use a namespace package openstack then each project has a unique package
under that for their meaningfully named package (compute, networking, etc.).

We only have to rename projects if they start out with bad names to begin
with. Projects that want to be integrated should be developing on
stackforge and using the openstack namespace package.



 I acknowledge we still have to indicate what commands, daemon names, and
 so on are related to a particular service. That issue is also fixable with
 some resources and effort and pays off in easier adoption and understanding.


The unified command line project will resolve the command issue because all
commands will be openstack $noun $verb (end users shouldn't have to know
which OpenStack component owns a resource in order to operate on it via the
command line). Daemon startup scripts could use a similar framework, or
just a naming convention (openstack-compute-api, openstack-network-api,
etc.).

Doug



 Anne

 1.
 http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html




  On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com
  mailto:dava...@gmail.com wrote:
 
  Lattice
 
  -- dims
 
  On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net
  mailto:m...@amerine.net wrote:
   Tubes
  
   ;-)
  
  
   On Sat, May 11, 2013 at 12:51 PM, Jason Smith
  jason.sm...@rackspace.com mailto:jason.sm...@rackspace.com
   wrote:
  
   Hello,
   I understand why we had to give up Quantum code name but rather
  than just
   refer to it as networking let's come up with a new code name!
  
   Thoughts?
  
   Thanks,
   -js
   ___
   Mailing list: https://launchpad.net/~openstack
   Post to : openstack@lists.launchpad.net
  mailto: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
  mailto:openstack@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~openstack
   More help   : https://help.launchpad.net/ListHelp
  
 
 
 
  --
  Davanum Srinivas :: http://davanum.wordpress.com
 
  ___
  Mailing list: https://launchpad.net/~openstack
  Post to : openstack@lists.launchpad.net
  mailto: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

Re: [Openstack] New code name for networks

2013-05-13 Thread Sean Dague


On 05/13/2013 11:03 AM, Doug Hellmann wrote:



+1

Use a namespace package openstack then each project has a unique
package under that for their meaningfully named package (compute,
networking, etc.).


Sounds great and all, except when you try to do something like quantum, 
or even cinder, where you break out function into another project.


from openstack import network - wait, is that what used to be nova 
network, or quantum, or some abstraction?


from openstack.compute import network as compute_network ?

Code names are actually incredibly useful in developing this stuff, 
because it lets us think about an implementation separate from a 
concept, and work with non native english speakers a lot easier where 
concept vs. implementation.


Honestly, there is already incredible confusion when you talk with 
people about compute. Where you have to be really paying attention to 
nuance to figure out if people meant Nova as a whole, the Nova 
compute daemon, A nova compute node, which might also have 
nova-network on it. The number of times we had to explain no-db-compute 
blueprint because of that speaks to the fact that generic names do not 
make anything easier, they generate more confusion quite often.


Code names are useful because it gives us a whole other namespace of 
words to work with to be very specific about what we mean, that can't be 
confused for the generic concepts of networking or computing. Yes, it's 
inside baseball, but when you are dealing with code as complicated as 
OpenStack, not having that inside baseball really slows things down.


Just look at the regular confusion new people have about the 2 uses of 
the term migrations in Nova, one for the database schema, and one for 
moving guests around. :)


-Sean

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

[Openstack] heat and quantum

2013-05-13 Thread Molnár Mihály László

Hi all!

I want to try heat, but my instance doesnt start up. As I can see the
network doesn't configured.
So I looked into the template:
https://github.com/openstack/heat-templates/blob/master/cfn/WordPress_Single_Instance_With_Quantum.template

As I can see, there is something configured for quantum, but I cant find
any documentation how should I configure it for an existing network. I
tried to replace IPs with mine, but it doesn't work.

Do you have any idea where should I look for more info?
Except this letter:
http://lists.openstack.org/pipermail/openstack-dev/2012-November/002355.htmlI
couldnt find anything relating these options.

Thanks!

Rusty
___
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] New code name for networks

2013-05-13 Thread Doug Hellmann

On Mon, May 13, 2013 at 11:30 AM, Sean Dague s...@dague.net wrote:

 On 05/13/2013 11:03 AM, Doug Hellmann wrote:



 +1

 Use a namespace package openstack then each project has a unique
 package under that for their meaningfully named package (compute,
 networking, etc.).


 Sounds great and all, except when you try to do something like quantum, or
 even cinder, where you break out function into another project.

 from openstack import network - wait, is that what used to be nova
 network, or quantum, or some abstraction?


Fair point, and those specific examples of names may not be good. :-)

On the other hand, there's no reason each team needs to be limited to
deploying a single package. If nova network was openstack.network to
begin with, then perhaps quantum could have just been an evolution of that.



 from openstack.compute import network as compute_network ?

 Code names are actually incredibly useful in developing this stuff,
 because it lets us think about an implementation separate from a concept,
 and work with non native english speakers a lot easier where concept vs.
 implementation.

 Honestly, there is already incredible confusion when you talk with people
 about compute. Where you have to be really paying attention to nuance to
 figure out if people meant Nova as a whole, the Nova compute daemon, A
 nova compute node, which might also have nova-network on it. The number of
 times we had to explain no-db-compute blueprint because of that speaks to
 the fact that generic names do not make anything easier, they generate more
 confusion quite often.

 Code names are useful because it gives us a whole other namespace of words
 to work with to be very specific about what we mean, that can't be confused
 for the generic concepts of networking or computing. Yes, it's inside
 baseball, but when you are dealing with code as complicated as OpenStack,
 not having that inside baseball really slows things down.


This seems like a stronger argument than it's hard to rename things
(which I think is at least a large part of the argument against moving away
from code names during/after incubation).

FWIW, I'm in favor of not branding every little thing we do openstack,
especially when components can be reused by other projects (I would love to
see us acquire a few downstream users of some of the Oslo libraries, for
example). But for the big core stuff, it feels weird to have separate
commands, separate package namespaces, etc.



 Just look at the regular confusion new people have about the 2 uses of the
 term migrations in Nova, one for the database schema, and one for moving
 guests around. :)


I'm not sure we're going to eliminate confusion entirely. I'm not even sure
changing anything will reduce it. But it does seem like we can minimize
legal issues by avoiding using code names in the code, which is where this
thread started.

Doug




 -Sean

 --
 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] New code name for networks

2013-05-13 Thread Monty Taylor



On 05/13/2013 11:03 AM, Doug Hellmann wrote:
 
 
 
 On Sat, May 11, 2013 at 5:48 PM, Anne Gentle a...@openstack.org
 mailto:a...@openstack.org wrote:
 
 
 
 
 On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust.com
 mailto:mord...@inaugust.com wrote:
 
 
 
 On 05/11/2013 04:07 PM, Asher Newcomer wrote:
  Or even better, just continue to call it openstack networking.
 The code
  names only serve to confuse the uninitiated. They needlessly
 steepen the
  learning curve and slow uptake.
 
 The problem with OpenStack Networking (or getting rid of
 codenames) is
 seen with pre-incubation-incubation-integrated cycle.
 
 A project cannot call itself OpenStack Foo until it actually _is_
 openstack foo. So any new project by necessity has to start off as
 something else.
 
 But - if we then require them to drop that name and become
 openstack foo
 when they become incubated or integrated, then we've got what's
 become a
 stable project with a decent amount of contributors renaming itself.
 
 Every. Time.
 
 The code names aren't just cute. I kind of wish they were,
 because it
 would make several things much easier if we could just ditch
 them and do
 a pure openstack. code namespace. But the reality is that it
 gets really
 really tricky to deal with a bunch of things if they go away.
 
 
 I told Monty and the TC this at the Summit (sorry I couldn't attend
 the session about code names). I find this trickiness a weak
 argument in the face of the invented names that are getting to be as
 bad as U.S. pharmaceuticals. Plus it forces us to put a lookup
 table in the docs forever. [1] Let's find a process for naming that
 meets a few reqs:
 - describes the service
 - goes through a legal review
 - enables new eyes to understanding it by reading the English word
 that the service represents (that can be translated into a
 meaningful word in other languages)
 
 If we have to preface with Stackforge to indicate pre-incubation,
 that's fine. Use Incubating or some such to indicate incubation.
 Meaningful words have meaning. 
 
 
 +1
 
 Use a namespace package openstack then each project has a unique
 package under that for their meaningfully named package (compute,
 networking, etc.).
 
 We only have to rename projects if they start out with bad names to
 begin with. Projects that want to be integrated should be developing on
 stackforge and using the openstack namespace package.

It's just logically infeasible. If we were to make that choice, I'm
pretty sure we'd have to stop everything that everyone is doing and just
deal the fallout from doing it.

In any case - we did have a session on this at the summit, and we did
lay out a strategy for moving forward. The etherpad is here

https://etherpad.openstack.org/ProjectsReNaming

tl;dr - we are going to rename quantum to a new codename, and we are
going to do our best as a community to lessen the external usage of our
codenames.

 I acknowledge we still have to indicate what commands, daemon names,
 and so on are related to a particular service. That issue is also
 fixable with some resources and effort and pays off in easier
 adoption and understanding.
 
 
 The unified command line project will resolve the command issue because
 all commands will be openstack $noun $verb (end users shouldn't have
 to know which OpenStack component owns a resource in order to operate on
 it via the command line). Daemon startup scripts could use a similar
 framework, or just a naming convention (openstack-compute-api,
 openstack-network-api, etc.).

I agree - having the unified command line client will be very helpful to
lessening our externally-facing usages of code names.

 Doug
  
 
 
 Anne
 
 1. 
 http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html
  
  
 
 
  On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com
 mailto:dava...@gmail.com
  mailto:dava...@gmail.com mailto:dava...@gmail.com wrote:
 
  Lattice
 
  -- dims
 
  On Sat, May 11, 2013 at 3:52 PM, Mark Turner
 m...@amerine.net mailto:m...@amerine.net
  mailto:m...@amerine.net mailto:m...@amerine.net wrote:
   Tubes
  
   ;-)
  
  
   On Sat, May 11, 2013 at 12:51 PM, Jason Smith
  jason.sm...@rackspace.com
 mailto:jason.sm...@rackspace.com
 mailto:jason.sm...@rackspace.com
 mailto:jason.sm...@rackspace.com
   wrote:
  
   Hello,
   I understand why we had to give up Quantum code name
 but rather

[Openstack] Folsom 2012.2.4 Ubuntu Packages

2013-05-13 Thread Joe Topjian

Hello,

Does anyone know when the Folsom 2012.2.4 release will be available in the
Ubuntu Cloud Archive?

Thanks,
Joe

-- 
Joe Topjian
Systems Administrator
Cybera Inc.

www.cybera.ca

Cybera is a not-for-profit organization that works to spur and support
innovation, for the economic benefit of Alberta, through the use
of cyberinfrastructure.
___
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 and disk usage

2013-05-13 Thread Paras pradhan

Thanks Christian you have been a good help !

Paras.

On Sat, May 11, 2013 at 3:14 AM, Christian Schwede i...@cschwede.de wrote:

Hi Paras,

Am 08.05.13 22:02, schrieb Paras pradhan:
Thanks Christian. How do we keep track of the usage? For example with 5
nodes i.e 40TB. How do we know how much space has been consumed out of
this 40TB?

well, that depends on the used authentication scheme. If you are using
swauth and don't have thousands of users, this gist might help you:

https://gist.github.com/cschwede/5559268

It reports the used bytes for every account and the total size. Please
note that the returned account list is not sorted.

On the other side you can simply monitor all of your disks, sum up all
used byte values and divide by the number of replicas (3).

You might also use account_quotas, which blocks further write requests
if the quota on an account is exceeded. It is especially useful for
smaller private storage clusters.

http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.account_quotas

Christian

Paras.

On Wed, May 8, 2013 at 2:44 PM, Christian Schwede i...@cschwede.de
mailto:i...@cschwede.de wrote:

Am 08.05.13 21:18, schrieb Paras pradhan:
I have a three nodes swift cluster. I can see the objects being
replicated to all three nodes. Each node has 12 2TB disks. Since I
have 3 replicas the usable space is only 24TB ?

Yes, that's correct.

How this will scale up if we add two more storage nodes of the same
capacity?

5 * 12 * 2 / 3: ~ 40TB usable capacity.

Also, is there any tool to monitor the usage, health of the whole
cluster?

To detect failed drives you might have a look at

http://docs.openstack.org/developer/swift/admin_guide.html#detecting-failed-drives

For Swift-related monitoring please refer to

http://docs.openstack.org/trunk/openstack-object-storage/admin/content/ch_introduction-to-openstack-object-storage-monitoring.html

For general node monitoring you can use your preferred tool (Nagios,
Icinga, Shinken, RHQ, Hyperic...).

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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] [openstack-community] [Ask] Guidelines for answering question on Ask

2013-05-13 Thread Stefano Maffulli


[trimming the cc]

On Sat 11 May 2013 07:30:13 AM PDT, John Wong wrote:

Can we have a template?
I think it would be really helpful if by default there is a template /
form to fill out. Not sure if the underlying software has that mechanism.

Basically to do support, it'd really important to know the version
used, system.


I think it's a good idea. The software allows already to insert a short 
text blurb on


https://ask.openstack.org/questions/ask/

People don't usually read but I think it's better to put something 
there than nothing :) What would you write there?



--
Ask and answer questions on https://ask.openstack.org

___
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] Understanding the metadata service

2013-05-13 Thread Greg Chavez

Even after reading all the posts and IRC chatter regarding how to
configure VM metadata services, I'm no closer to understanding how
this should be set up in *my* environment. As it stands, my VMs are
fully functional (available from external network via floaters) but
cannot connect to 169.254.169.254.

I am running Grizzly on Raring, with per-tenant routers,
ip-namespaces/overlapping-ips, GRE tunneling, and a separate network
node with three NICs for public, management, and vm config nets.
Also:

I have nova-api installed on the compute node.  It is listening for
8775 on the controller's management network.

The relavent configurations:


controller nova.conf:
--
service_quantum_metadata_proxy = True
quantum_metadata_proxy_shared_secret = PvUafKreIImX3OePynlc
metadata_host = 192.168.241.100
metadata_listen = 192.168.241.100
metadata_listen_port = 8775

net-node quantum.conf / dhcp_agent.ini / l3_agent.ini
--
allow_overlapping_ips = True

net-node metadata_agent.ini
--
nova_metadata_ip = 192.168.241.100
nova_metadata_port = 8775
metadata_proxy_shared_secret = PvUafKreIImX3OePynlc

compute nodes nova.conf
--
service_quantum_metadata_proxy = True
quantum_metadata_proxy_shared_secret = PvUafKreIImX3OePynlc


What am I missing here?  Thanks in advance.

--
\*..+.-
--Greg Chavez
+//..;};

___
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] Guest PXE Boot

2013-05-13 Thread David Hill

Hello Monty,

I haven't had the time to play with baremetal yet but it is on my todo 
list. 
I know I may be doing it wrong but when I create my Linux/Windows/ETC images, 
I'm 
using the kickstarting solution we already have in place and I was simply 
trying to PXE
boot my images from my lab as it is faster (better hardware, more memory).

I'm wondering if this patch could make it trunk?   I enjoyed the 
libvirt.xml.template before 
it got removed and found this solution (quick and easy).

I will definitely look at the baremetal (after seeing what it can do at the 
summit).

Thank you very much,

Dave


-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: May-11-13 4:18 PM
To: David Hill
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Guest PXE Boot

Neat!

Have you seen any of the work around nova baremetal (which is
transitioning to be called ironic?) Related to that is a set of virtual
power drivers which allow for treating virtual machines like real
machines - so that you can use nova to pxe boot a kvm or a virtualbox or
a vmware instance.

I know it's not exactly the same thing, but I don't know what you're
trying to accomplish. Perhaps what you want is similar enough to work
together?

Monty

On 05/10/2013 12:55 PM, David Hill wrote:
 Hi guys,
 
  
 
 I was trying to PXE boot a guest for quite some time now and I think
 I've found a solution that is kind of hackish but pretty simple.   I'm
 not quite sure it's good to go in trunk but felt like I'd share it since
 I've been messing a while on this.  
 
 If anybody have a better solution, I would really like to hear/see/try it ...
 
  
 
 Here is how I did it:
 
  
 
 First, patch the libvirt/driver.py file:
 
 --- /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py.orig  
 2013-05-10 16:25:17.787862177 +
 
 +++ /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py   
 2013-05-10 16:26:39.442022870 +
 
 @@ -87,6 +87,9 @@
 
 LOG = logging.getLogger(__name__)
 
  
 
 libvirt_opts = [
 
 +cfg.StrOpt('default_guest_boot_dev',
 
 +   default='hd',
 
 +   help='Sets the default guest boot device'),
 
  cfg.StrOpt('rescue_image_id',
 
 default=None,
 
 help='Rescue ami image'),
 
 @@ -1792,7 +1795,7 @@
 
 instance['name'],
 
 ramdisk)
 
  else:
 
 -guest.os_boot_dev = hd
 
 +guest.os_boot_dev = FLAGS.default_guest_boot_dev
 
  
 
  if FLAGS.libvirt_type != lxc and FLAGS.libvirt_type != uml:
 
  guest.acpi = True
 
  
 
  
 
 And add to nova.conf:
 
 default_guest_boot_dev=network
 
  
 
 And finally add to /etc/dnsmasq.conf
 
 dhcp-boot=boot\x86\pxelinux.com,host_name,host_ip
 
 dhcp-no-override
 
  
 
 And restart dnsmasq.conf
 
  
 
 In my actual setup, the guest will PXE boot, show the menu 60 seconds
 and then boot from hard disk after the 60 seconds timeout.
 
  
 
  
 
 Thank you very much,
 
  
 
 Dave
 
 
 
 ___
 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

[Openstack] Unable to run Instance, Ends with status Error in OpenStack

2013-05-13 Thread Dhanasekaran Anbalagan

Hi Guys,

I am trying to start instance it's says instance status Error.
In horizon log tab  Unable to get log for instance
c307ae2b-c09d-4c05-9525-906ed35d81c5.

This my /var/log/nova/nova-compute.log

2013-05-13 15:59:38.717 3014 TRACE nova.compute.manager [instance:
c307ae2b-c09d-4c05-9525-906ed35d81c5] QuantumClientException: 404 Not Found
2013-05-13 15:59:38.717 3014 TRACE nova.compute.manager [instance:
c307ae2b-c09d-4c05-9525-906ed35d81c5]
2013-05-13 15:59:38.717 3014 TRACE nova.compute.manager [instance:
c307ae2b-c09d-4c05-9525-906ed35d81c5] The resource could not be found.

http://paste.ubuntu.com/5662352/

Please guide me.

Did I learn something today? If not, I wasted it.
___
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] ConnectQuantum to VLAN-tagged physical network

2013-05-13 Thread Yiting Wu

Hi Angelo,


I had the same problem with you.
when I try:

# ovs-vsctl add-br br-dev
# ovs-vsctl add-port br-dev eth1 tag=108

and it doesn't work.

Does it mean we have to use vconfig to add a eth1.108 virtual interface,
and add it into bridge?
But OpenVSwitch suppose to support vlan directly.

That's a bit tricky.



On Mon, May 13, 2013 at 4:06 AM, Angelo Olivera aoliv...@gmail.com wrote:

 Salvatore, thanks for your reply. It took me a few tries but I finally
 solved this issue by creating the vlan devices on the respective
 interfaces, adding them to the corresponding bridges with ovs-vsctl
 and configuring two external networks with quantum.

 This would correspond to the Multiple Flat Network use case
 described in the Grizzly Networking Administration Guide[1], although
 the configuration is not explained. Quantum provides DHCP with default
 routes 10.33.8.1 (vlan 108) and 10.33.9.1 (vlan 109). Namespaces are
 used and there is one instance of the metadata proxy per each
 namespace.

 [1]
 http://docs.openstack.org/grizzly/openstack-network/admin/content/use_cases_multi_flat.html

 /etc/network/interfaces
 auto lo
 iface lo inet loopback

 auto eth0
 iface eth0 inet static
 address 10.33.10.210
 netmask 255.255.255.0
 gateway 10.33.10.1

 auto eth1
 iface eth1 inet manual

 auto eth1.108
 iface eth1.108 inet manual
 vlan-raw-device eth1
 up /sbin/ifconfig eth1.108 up

 auto eth1.109
 iface eth1.109 inet manual
 vlan-raw-device eth1
 up /sbin/ifconfig eth1.109 up

 /etc/quantum/quantum.conf
 [DEFAULT]
 lock_path = $state_path/lock
 bind_host = 0.0.0.0
 bind_port = 9696
 core_plugin =
 quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
 api_paste_config = /etc/quantum/api-paste.ini
 control_exchange = quantum
 rabbit_host = 10.33.10.210
 notification_driver = quantum.openstack.common.notifier.rpc_notifier
 default_notification_level = INFO
 notification_topics = notifications
 [QUOTAS]
 [DEFAULT_SERVICETYPE]
 [AGENT]
 root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf
 [keystone_authtoken]
 auth_host = 127.0.0.1
 auth_port = 35357
 auth_protocol = http
 admin_tenant_name = service
 admin_user = quantum
 admin_password = ###
 signing_dir = /var/lib/quantum/keystone-signing

 /etc/quantum/dhcp_agent.ini
 [DEFAULT]
 interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
 dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq
 use_namespaces = True
 enable_isolated_metadata = True

 /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
 [DATABASE]
 sql_connection = mysql://quantum##@10.33.10.210/quantum?charset=utf8
 reconnect_interval = 2
 [OVS]
 # even when using flat networking these two variables had to be
 defined for the multiple physical networks to work
 tenant_network_type = vlan
 network_vlan_ranges = physdev:2048:4094,physqa:2048:4094
 bridge_mappings = physdev:br-dev,physqa:br-qa
 [AGENT]
 polling_interval = 2
 [SECURITYGROUP]
 firewall_driver =
 quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

 # ovs-vsctl add-br br-int
 # ovs-vsctl add-br br-dev
 # ovs-vsctl add-port br-dev eth1.108
 # ovs-vsctl add-br br-qa
 # ovs-vsctl add-port br-qa eth1.109
 # quantum net-create --shared dev --provider:network_type flat
 --router:external=True --provider:physical_network physdev
 # quantum net-create --shared qa --provider:network_type flat
 --router:external=True --provider:physical_network physqa
 # quantum subnet-create dev 10.33.8.0/24 --name dev-subnet
 --allocation-pool start=10.33.8.10,end=10.33.8.254
 # quantum subnet-create qa 10.33.9.0/24 --name qa-subnet
 --allocation-pool start=10.33.9.10,end=10.33.9.254

 (Question also posted on
 https://answers.launchpad.net/quantum/+question/228437/)

 Regards,

 --
 Angelo

 On Thu, May 9, 2013 at 8:07 AM, Salvatore Orlando sorla...@nicira.com
 wrote:
  Your configuration looks correct, and provider networks are what you need
  for implementing this use case.
 
  Is the traffic for your subnets improperly tagged, or are you unable at
 all
  to forward traffic?
  If you're not using GRE overlays it might make sense verifying that VLAN
  108/109 are allowed on physical switch ports or that the physical switch
  ports are in trunk mode.
 
 
  Regards,
  Salvatore
 
 
  On 8 May 2013 20:21, Ashok Kumaran ashokkumara...@gmail.com wrote:
 
  Hi Angelo,
 
  This should be possible. Make sure that eth1 is connected to the Vlan
  trunk with necessary port configurations.
 
  Create 2 network with segmentation's ID as 108 and 109 respectively.
  Create the respective subnets for both network and then proceed with
 further
  configurations as needed. Are you facing any specific issues here?
 
  -Ashok
 
 
  On Wed, May 8, 2013 at 9:57 PM, Angelo Olivera aoliv...@gmail.com
 wrote:
 
  Hello,
 
  I am using Ubuntu 12.04 and OpenStack Grizzly from the Ubuntu Cloud
  archive. I am trying to get instances to get an IP address from
 dnsmasq in
  the 10.33.8.0/24 or 10.33.9.0/24

Re: [Openstack] Grizzly on Laptop running Ubuntu 12.04 Desktop 64-bit and having 2 NICs (one Ethernet and other Wireless)

2013-05-13 Thread Lloyd Dewolf

On Mon, May 13, 2013 at 7:34 AM, Devendra Gupta dev29...@gmail.com wrote:
 Hi,

 I am setting up Grizzly in single node on my laptop running Ubuntu
 12.04 Desktop 64-bit for POC, I am using a doc which say 2 NICs are
 required (please see
 https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_SingleNode/OpenStack_Grizzly_Install_Guide.rst
 doc).

 I have two NICs in my laptop one is Ethernet and other is Wireless so
 is it fine to setup the environment on it ? Another thing, what if I
 am disconnected from any of the network because then I don't have IP
 in that specific NIC ?

Skimming through those instructions it looks like the requirement for
2 nics is specific to making your OpenStack install available on the
Internet in a secure-ish manner.

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

62 matches

Mail list logo