Re: [Openstack] [TripleO]Error while running RDO instack
On 09/24/2014 10:20 PM, Steve Gordon wrote: - Original Message - From: "Peeyush Gupta" To: openstack@lists.openstack.org Hi all, I have been trying to set up TripleO using RDO instack. I tried it in virtual environment and it works fine. Now, I am trying on physical environment. I installed Fedora 20 on a machine and set up the user stack. Now, when I run 'instack-install-undercloud-packages', I am getting the following error: + output 'Running /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo' ++ date + echo dib-run-parts Tue Sep 23 13:00:52 IST 2014 Running /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo dib-run-parts Tue Sep 23 13:00:52 IST 2014 Running /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo + target_tag=00-allow-heat-admin-sudo + date +%s.%N + /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo /etc/sudoers.d/x2goserver: bad permissions, should be mode 0440 /etc/sudoers: parsed OK /etc/sudoers.d/50_stack_sh: parsed OK /etc/sudoers.d/cinder-rootwrap: parsed OK /etc/sudoers.d/heat-admin-notty: parsed OK /etc/sudoers.d/nova-rootwrap: parsed OK /etc/sudoers.d/stack: parsed OK INFO: 2014-09-23 13:00:52,440 -- ### End stdout/stderr logging ### ERROR: 2014-09-23 13:00:52,441 -- Hook FAILED. ERROR: 2014-09-23 13:00:52,441 -- Failed running command ['dib-run-parts', u'/tmp/tmpzgbZSQ/pre-install.d'] Then I ran ' dib-run-parts /tmp/tmpNMJP7_/pre-install.d' command and here is the error I got: + source /tmp/tmpNMJP7_/pre-install.d/../environment.d/15-manifests ++ set -eu ++ export DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests ++ DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests /tmp/tmpNMJP7_/pre-install.d/../environment.d/15-manifests: line 20: IMAGE_NAME: unbound variable So, as I understand there is no IMAGE_NAME set in the system. So, I put fedora-20-undercloud-package as IMAGE_NAME. I am not sure if that is correct or not. Now, I ran the command again (the dib one) and here is the error: + source /tmp/tmpNMJP7_/pre-install.d/../environment.d/15-manifests ++ set -eu ++ export DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests ++ DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests ++ export DIB_MANIFEST_SAVE_DIR=fedora-20-undercloud-packages.d/ ++ DIB_MANIFEST_SAVE_DIR=fedora-20-undercloud-packages.d/ + for target in '$targets' + output 'Running /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo' ++ date + echo dib-run-parts Tue Sep 23 13:04:16 IST 2014 Running /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo dib-run-parts Tue Sep 23 13:04:16 IST 2014 Running /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo + target_tag=00-allow-heat-admin-sudo + date +%s.%N + /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo: line 6: /etc/sudoers.d/heat-admin-notty: Permission denied Can you please help me resolve the error? Thanks, -- Peeyush Gupta gpeey...@linux.vnet.ibm.com Hi Peeyush, Did you create the stack user and add them to sudo?: # useradd stack # passwd stack # specify a password # echo "stackALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/stack # chmod 0440 /etc/sudoers.d/stack See the bottom of this page: https://openstack.redhat.com/Deploying_RDO_on_a_Baremetal_Environment_using_Instack -Steve Hi Steve, Yes, I did that. And I also logged into new shell for the changes to take effect. Still I am not able to make it work. Should I install Fedora from scratch? As there was an tripleo virtual environment setup on this machine before. Is it possible that that could have messes up the configuration? -- Peeyush Gupta gpeey...@linux.vnet.ibm.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Nat rules of Floating IP on wrong router
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, i'm running in a problem if i associate a floating IP address to an instance. My system: * icehouse / Ubuntu * 2 different tenants * each tenant have his own router * each tenant have his own fixed net/subnet attached to his own router I've create a port on tenant A with a fixed_ip address and attach this port to tenant B router. In addition i've updated the subnet on tenant A and add the host routes to reach the tenant B network. That works perfectly. Now i'm spawning an instance on tenant A and i can reach them with the allocated fixed_ip. The next step is to associate a floating IP address to the spawned instance. That works without errors but the l3 agent will create the DNAT and SNAT rules on the tenant B router (wrong router). My assumption is that the l3 agent looks for router_interface and takes the first one. So the l3 agent gets the device_id (router id) where the SNAT and DNAT should be create. Is that a bug or do im something wrong ? Cheers Heiko P.S.: Sorry for double post (https://ask.openstack.org/en/question/48468/neutron-floating-ip-nat-on-wrong-router/) - -- anynines.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUJAhSAAoJELxFogM4ixOFSYcH/33P+S3us0h8EblPhh8Ctyuj b21tS1b/wmaz4tyJdCCWDBh61GHLT75aMcoriPa7lPm/nhT0eT79DG52NO1I5G3B lJqA6cPI+r1Da4fPB049g4OJ7izIKbUrinGlW/lZtf0Pf6ppV3x7BfedMZbl2U78 mWM5AYrfWWQwWcN9n1lG65cGtPR/v24QCbf9kkIBAdowdkzczk7K99DZ7/kynIT5 NiF3Dz6IhLUF4cblhDqoKOO2ClqvwTU17wqqt9OmLWiV6y1UOkRKpQY3gKiN6peb ggKQP0U6QIV6ynv4EPyD5S5OLEXjLDEJLcAUlDwFmGXRR6Hi/KEZOsnLtUaS9xI= =AAP3 -END PGP SIGNATURE- ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Devstack][Neutron][Neutron N1KV Plugin] How to enable in local.conf?
taken cisco plugin file from below url: https://github.com/CiscoSystems/devstack/blob/bobmel/csr1kv_for_routing_icehouse/lib/neutron_plugins/cisco Downloaded vem and vem-dkms from the below url: https://launchpad.net/~cisco-n1kv/+archive/ubuntu/n1kv-updates/+packages nexus-1000v-vem-dkms_14.04.5.2.1.sk3.1.0.s0.187-1_all.deb nexus-1000v-vem_14.04.5.2.1.sk3.1.0.s0.187.orig.tar.gz manually installed vem-dkms using: sudo dpkg -i nexus-1000v-vem-dkms_14.04.5.2.1.sk3.1.0.s0.187-1_all.deb configured VEM.deb in local.conf: Q_CISCO_PLUGIN_UVEM_DEB_IMAGE=/var/lib/nexus-1000v-vem_14.04.5.2.1.sk3.1.0.s0.187-1_amd64.deb Now I am getting different error: $ tail stack.sh.log 2014-09-25 11:40:27.604 | + die_if_not_set 374 TENANT_ID 'Failure retrieving TENANT_ID for demo' 2014-09-25 11:40:27.609 | + local exitcode=0 2014-09-25 11:40:27.614 | + neutron cisco-network-profile-create default_network_profile vlan --segment_range 1-3000 --physical_network test-physnet1 2014-09-25 11:40:36.596 | Internal Server Error (HTTP 500) (Request-ID: req-23eb2811-cfdc-40c7-b7e0-16a8e53f5068) 2014-09-25 11:40:36.644 | + exit_trap 2014-09-25 11:40:36.651 | + local r=1 2014-09-25 11:40:36.657 | ++ jobs -p 2014-09-25 11:40:36.662 | + jobs= 2014-09-25 11:40:36.668 | + [[ -n '' ]] 2014-09-25 11:40:36.673 | + exit 1 $ tail -n 200 screen-q-svc.log 2014-09-25 18:11:19.147 DEBUG neutron.plugins.cisco.db.n1kv_db_v2 [req-9f7ef44c-3cb7-4005-9ce1-d96ade49caae admin 8dce1039369440b9b006f3f9c7247588] get_network_profile() from (pid=2004) get_network_profile /opt/stack/neutron/neutron/plugins/cisco/db/n1kv_db_v2.py:816 2014-09-25 18:11:19.169 ERROR neutron.api.v2.resource [req-9f7ef44c-3cb7-4005-9ce1-d96ade49caae admin 8dce1039369440b9b006f3f9c7247588] create failed 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource Traceback (most recent call last): 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/resource.py", line 87, in resource 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource result = method(request=request, **args) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 448, in create 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource obj = obj_creator(request.context, **kwargs) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_neutron_plugin.py", line 1412, in create_network_profile 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource self).delete_network_profile(context, net_p['id']) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/openstack/common/excutils.py", line 82, in __exit__ 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_neutron_plugin.py", line 1407, in create_network_profile 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource context.tenant_id) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_neutron_plugin.py", line 628, in _send_create_logical_network_request 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource n1kvclient.create_logical_network(network_profile, tenant_id) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_client.py", line 250, in create_logical_network 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource body=body) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_client.py", line 521, in _post 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource headers=headers) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_client.py", line 471, in _do_request 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource raise c_exc.VSMError(reason=replybody) 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource VSMError: Internal VSM Error: Resource not found 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource . 2014-09-25 18:11:19.169 TRACE neutron.api.v2.resource 2014-09-25 18:11:19.173 INFO neutron.wsgi [req-9f7ef44c-3cb7-4005-9ce1-d96ade49caae admin 8dce1039369440b9b006f3f9c7247588] 10.10.2.2 - - [25/Sep/2014 18:11:19] "POST /v2.0/network_profiles.json HTTP/1.1" 500 317 0.849353 It actually failed while executing "_do_request" method: $ vim /opt/stack/neutron/neutron/plugins/cisco/n1kv/n1kv_client.py try: resp, replybody = (httplib2.Http(timeout=self.timeout). request(action, method, body=body, headers=headers)) except Exception as e: raise c_exc.VSMConnectionFailed(reason=e)
Re: [Openstack] Nat rules of Floating IP on wrong router
Hi you could boot up your vm and specify which port to use I am not sure if you can from the ui. Remo Inviato da iPhone () > Il giorno 25/set/2014, alle ore 04:19, Heiko Krämer > ha scritto: > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi guys, > > i'm running in a problem if i associate a floating IP address to an > instance. > > My system: > * icehouse / Ubuntu > * 2 different tenants > * each tenant have his own router > * each tenant have his own fixed net/subnet attached to his own router > > I've create a port on tenant A with a fixed_ip address and attach this > port to tenant B router. In addition i've updated the subnet on tenant A > and add the host routes to reach the tenant B network. That works perfectly. > > Now i'm spawning an instance on tenant A and i can reach them with the > allocated fixed_ip. The next step is to associate a floating IP address > to the spawned instance. That works without errors but the l3 agent will > create the DNAT and SNAT rules on the tenant B router (wrong router). > > My assumption is that the l3 agent looks for router_interface and takes > the first one. So the l3 agent gets the device_id (router id) where the > SNAT and DNAT should be create. > > Is that a bug or do im something wrong ? > > Cheers > Heiko > > > P.S.: Sorry for double post > (https://ask.openstack.org/en/question/48468/neutron-floating-ip-nat-on-wrong-router/) > > - -- > anynines.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUJAhSAAoJELxFogM4ixOFSYcH/33P+S3us0h8EblPhh8Ctyuj > b21tS1b/wmaz4tyJdCCWDBh61GHLT75aMcoriPa7lPm/nhT0eT79DG52NO1I5G3B > lJqA6cPI+r1Da4fPB049g4OJ7izIKbUrinGlW/lZtf0Pf6ppV3x7BfedMZbl2U78 > mWM5AYrfWWQwWcN9n1lG65cGtPR/v24QCbf9kkIBAdowdkzczk7K99DZ7/kynIT5 > NiF3Dz6IhLUF4cblhDqoKOO2ClqvwTU17wqqt9OmLWiV6y1UOkRKpQY3gKiN6peb > ggKQP0U6QIV6ynv4EPyD5S5OLEXjLDEJLcAUlDwFmGXRR6Hi/KEZOsnLtUaS9xI= > =AAP3 > -END PGP SIGNATURE- > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > !DSPAM:1,54240b2d103215550328303! > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [Ironic] Deploying a physical node through Ironic
Hi all, I have been trying to deploy a physical node through Ironic. I have set up Ironic using devstack in a Ubuntu virtual environment. Now, I was able to register the node with Ironic and I can shut it down and turn it on using Ironic (meaning ipmi works). The problem is when I try to boot an instance, nova-scheduler doesn't consider the newly added node. It only consider the previously defined three virtual nodes. I tried restarting nova-scheduler process, but it didn't work. How can I let nova-scheduler know that there is one more node with Ironic? Or Do I need to somehow register it with nova too? -- Peeyush Gupta gpeey...@linux.vnet.ibm.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [openstack][keystone] Need a solution for large catalog in PKI tokens
The Openstack installation (Havana) at our company has a large number of service endpoints in the catalog. As a consequence, when using PKI tokens, my HTTP request header gets too big to handle for services like neutron. Im evaluating different options for reducing the size of the catalog in the PKI token. Some that I have found are: 1. Using the per tenant endpoint filtering extension: This could break if the per tenant endpoint list gets too big 2. Using PKIZ Tokens(In Juno): Were using Havana, so I cant use this feature, but it still doesnt look scalable 3. Using the ?nocatalog option. This is the best option for scalability but isnt the catalog a required component for authorization? Are there any other solutions that i am unaware of, that scale with number of endpoints? Thanks, Ved ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OSSA 2014-030] TLS cert verification option not honoured in paste configs (CVE-2014-7144)
OpenStack Security Advisory: 2014-030 CVE: CVE-2014-7144 Date: September 25, 2014 Title: TLS cert verification option not honoured in paste configs Reporter: Qin Zhao (IBM) Products: keystonemiddleware, python-keystoneclient Versions: versions up to 1.1.1 (keystonemiddleware), versions up to 0.10.1 (python-keystoneclient) Description: Qin Zhao from IBM reported a vulnerability in keystonemiddleware (formerly shipped as python-keystoneclient). When the 'insecure' option is set in a paste configuration file it is effectively ignored, regardless of its value. As a result certificate verification will be disabled, leaving TLS connections open to MITM attacks. All versions of keystonemiddleware with TLS settings configured via a paste.ini file are affected by this flaw. keystonemiddleware fix: https://review.openstack.org/113191 python-keystoneclient fix: https://review.openstack.org/112232 Notes: These fixes are included in the keystonemiddleware 1.2.0 release and in the python-keystoneclient 0.11.0 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7144 https://launchpad.net/bugs/1353315 -- Grant Murphy OpenStack Vulnerability Management Team pgpjA9GLG53to.pgp Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Ubuntu Cloud Archive not reachable via IPv6
Hey Stackers! I'm already building IceHouse Clouds that are IPv6-Only networks, using Trusty. Now, I would like to start testing Juno, in my IPv6 lab but, it doesn't work. Apparently, the entire Ubuntu PPA infrastructure doesn't have IPv6 connectivity, and this is affecting OpenStack users, because UCA doesn't have IPv6 connectivity... Is there any possibility for you guys from OpenStack, to put some pressure on Canonical to enable IPv6 at its PPA servers?! It is a pain to maintain creepy NAT64 at my border gateway just to access some PPA repos... Thanks! Thiago ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Load balancer questions
Hello, I had some basic questions on a load balancer we are considering for Swift. Some of them might be pretty stupid and basic. 1. Assuming layer 7 is what would be used for openstack services like keystone and Swift, not layer 4? I saw a layer 4 in front of a layer 7 in one of the diagrams, didnt really understand why that was needed. 2. Do typical installations use SSL termination within the load balancer and then normal http sessions beyond that to, say the proxy for Swift or keystone? 3. Is round robin at layer 7 is what is used? 4. This might be another stupid question, minus Horizon, you dont really need the load balancer to do cookies or sessions or any stickiness? For all else, it would just be load balancing round robin? With horizon, for the specific session, it would need to go to the same endpoint in the back end? 5. Is anyone using geo-DNS or a global load balancer for Swift multi site? TIA, --MW ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OSSN 0024] Sensitive data is exposed in log statements by python-keystoneclient
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sensitive data is exposed in log statements by python-keystoneclient
- ---
### Summary ###
Python-keystoneclient is a client tool for the OpenStack Identity API,
which is implemented by the Keystone project. Various OpenStack services
including the OpenStack Dashboard depend on python-keystoneclient to
consume the OpenStack Identity API service. A particular log level
setting in python-keystoneclient can lead to exposure of user sensitive
data (e.g., passwords or tokens) in log statements.
### Affected Services / Software ###
Python-keystoneclient=<0.10.0
### Discussion ###
Python-keystoneclient provides an interface for making Identity API
requests to the OpenStack Identity Service, Keystone.
Python-keystoneclient handles user sensitive data such as user passwords
and tokens when sending requests or receiving responses from a Keystone
server. Like all OpenStack projects, python-keystoneclient uses a python
logger to log request/response activities. When python-keystoneclient
runs with the DEBUG log level enabled, sensitive data such as user
passwords and tokens associated with requests/responses will be exposed
in log statements. For example:
- begin example
$ keystone --debug user-list
DEBUG:keystoneclient.session:REQ: curl -i -X POST
http://10.0.0.15:5000/v2.0/tokens -H "Content-Type:application/json"
-H "User-Agent: python-keystoneclient"
DEBUG:keystoneclient.session:REQ BODY: {"auth": {"tenantName": "admin",
"passwordCredentials": {"username": "admin", "password": "stack"
}}}
- end example
This sensitive data can potentially be exploited by an attacker with
access to the log statements.
Python-keystoneclient is used by Horizon and other Identity consuming
services to authenticate a user against the Identity API service,
Keystone. A user providing password or token for authentication to these
services could result in the capture of this sensitive data in the
respective services log statements.
### Recommended Actions ###
Version 0.10.1 of python-keystoneclient has addressed this issue by not
exposing user password and token information in log statements. Any
service using version 0.10.1 or later of python-keystoneclient is not
affected by this issue. Other services using old versions, should
upgrade to a fixed version of python-keystoneclient.
For a fresh installation of a service which depends on
pythone-keystoneclient, make sure it uses at least version 0.10.1 of
python-keystoneclient. One way to do this is to set a specific version
in the requirments.txt file. For example, in Horizon, update
horizon/requirements.txt file:
- begin example
python-keystoneclient>=0.10.1
- end example
For existing installations, upgrade python-keystoneclient to the
latest version. For example, python package manager (PIP) can be used
to upgrade the existing installations.
- begin example
$ pip install python-keystoneclient --upgrade
- end example
An alternate approach is to never run a production system with the log
level in DEBUG mode.
### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0024
Original Launchpad Bug:
https://bugs.launchpad.net/python-keystoneclient/+bug/1004114
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1004114
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUJM6eAAoJEJa+6E7Ri+EVmtEH/j6Z0+FFPYMYg7ABsk0AW81z
Bp2I7w5ulKznWrrFsWUuKE7BIWGZpRe1/7OIN8HOUDBGcP8hAxPwVEY+SNOrm13a
krBIhU6+X1zjzLsw+Uyzc4zWCL0hHcyxbW6sEqMDRkCWYunSCHhdkEAhTNtfl3lP
j8M0LVnxJZfjZAPVzWf56akA64PMKIPNS7fTYHeGskCg+BqYsu3UOjL9A/fSEILw
ZucxvtmxtJhVRG5YYjywFrBwMG+WheclgTTb+HP6l4kMJm9YWA9tjdR8iAgROlD4
LIFS55QV/UBHe0e+TAEg1YGmAgm9i/bO/5gR8q9m3b3nqqmjvBw4fXwruhTy/fY=
=I4CV
-END PGP SIGNATURE-
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
