Re: [openstack-dev] [Openstack] How to deploy OpenStack on thousands of nodes?
Kylin, I think there is some confusion as to the term broadcast. Many of the Rabbit docs describe the delivery of a message from one publisher to multiple subscribers as a 'broadcast'. This is not to be confused with a network broadcast where traffic is sent over the network broadcast address. Rabbit uses tcp and a publisher/subscriber model - even in more complex configurations where there are multiple publishers (think cluster). I have personally implemented large openstack compute clouds that had many hypervisors, each on individual subnets and a rabbit server on yet another subnet and all message traffic worked as expected. There were no actual network broadcasts to worry about. In my previous message I had assumed that you were actually in the process of implementation and were running into problems. It now seems that is not the case - you are in a review or planning period. However - as I noted above the openstack queues on rabbit will work in a distributed network configuration as long as all of the subscribers can reach the rabbit server on tcp/5672. I've personally done it and not had an issue. Brent On Tue, Jun 25, 2013 at 9:40 PM, Sg Kylin kylin7...@gmail.com wrote: Hi Brent, Thanks for your reply! But we are afraid that Rabbitmq needs broadcast to work correctly and usually broadcast is not available in cross-subnets deployments. That is what we are worrying about... Best, Kylin CG 2013/6/26 Brent Roskos brent.ros...@solinea.com By default rabbit uses tcp port 5672 for communication.. tcp can certainly cross subnet boundaries and be routed without issue. I suggest you do some network troubleshooting; ping your rabbit server then telnet to port 5672 on the rabbit server from hosts on the other subnets. Check your router acls and local host firewalls. Check to make sure that your rabbit server has a route to get back to the other subnets with the reply. Dual homed hosts with one local connection and one Internet connection will need specific routes added to allow them to reach other local subnets since you wouldn't want that traffic to try to traverse the default route which points out to the Internet. This is true even if you are using virtual interfaces with vlans instead of separate physical interfaces. Regards, Brent On Tue, Jun 25, 2013 at 6:10 AM, Sg Kylin kylin7...@gmail.com wrote: Hi All, We are currently trying to deploy OpenStack on thousands of nodes. We are using Grizzly stable version and Ubuntu 12.04.2. However, the big problem we meet now is the network topology. If we want to use HA (haproxy + keepalived) for the controller nodes on which *-apis are running as well as network nodes which are deployed across different VLANs (VLANs can reach each other by setting gateways), e.g 10.1.0.0/16 and 10.2.0.0/16, HA would not work correctly. Also we found that rabbitmq could not work when nova-* services were deployed across different subnets. Thus, we want to know whether HA and rabbitmq can be used across subnets? If it not true, we can only deploy them in a single flat layer 2 net, which seems unfeasible in real-world because of broadcast storms... Best, Kylin CG ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
On 06/24/2013 11:50 AM, Thierry Carrez wrote: To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) I think we should add Translations to the list of Programs: it is cross-functional to all the Projects, Incubated and Documentation (less relevant in QA and Infrastructure) but it has special needs, enough to deserve a small slot at the Design Summit, IMHO. Daisy: what do you think? /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack][ceilometer] ceilometer meter-list only lists image
Hi All, I'm trying to configure and run ceilometer with devstack on a Virtual Machine. Enabled ceilometer in devstack by following the instructions given in the wiki. devstack setup returns successfully, however ceilometer meter-list only lists the image metrics and nothing else. ceilometer-agent-compute, ceilometer-agent-central, ceilometer-collector, ceilometer-api are running Any suggestions to debug the problem ? -- Regards, Pradipta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Stefano Maffulli wrote: On 06/24/2013 11:50 AM, Thierry Carrez wrote: To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) I think we should add Translations to the list of Programs: it is cross-functional to all the Projects, Incubated and Documentation (less relevant in QA and Infrastructure) but it has special needs, enough to deserve a small slot at the Design Summit, IMHO. Daisy: what do you think? Translations is another horizontal effort, something that applies to all projects, like release management or vulnerability handling, but where contributions actually end up being applied as patches to other projects, rather than having their own repos. Another example of that would be the Python 3 effort. We have yet to decide if those should be considered programs, or if they should be recognized in some other way that is not a program. That shouldn't block the setup of the first programs though. Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
On Wed, 2013-06-26 at 14:15 +0200, Thierry Carrez wrote: 4. Be potentially able to define a set of projects that are the OpenStack product (markmc) Random thought on this ... If one of the release deliverables was e.g. a openstack.org/havana page which included links to the tarballs of the server projects, the same for the client and oslo libs, and also links to the docs ... then that could be the definition of our product. The difficulty, of course, is that it's not actually all that useful as a starting point for users. Does anyone install the tarballs directly? So we'd need to make it clear that this is about documenting what's in the official OpenStack release rather than a starting page for users. Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] How to deploy OpenStack on thousands of nodes?
I stand corrected. Mostly confused since the keepalived didn't actually need addresses in the multicast IP range. It does use it - as I can see with ifconfig. We minimized the impact of this by creating a small subnet that just had the switch address, host addresses and vrrp address in it. All the chatter was contained within that block. We avoided pacemaker in this particular instance because the keepalived setup and configuration was so very simple - only a couple of lines in a config file, and because we didn't need any of the other available HA features. Brent On Wed, Jun 26, 2013 at 10:03 AM, Jesse Pretorius jesse.pretor...@gmail.com wrote: On 26 June 2013 15:42, Brent Roskos brent.ros...@solinea.com wrote: I've also used keepalived for services that did not scale laterally. In this case I put two horizon servers behind an active/passive virtual IP. This was also pretty simple as there was no need to maintain state information in for active passive. That wouldn't work quite as well when capacity thresholds started to become a concern. Neither of the above required multicast support - which really helps with deployment options. *ahem* keepalived most definitely requires multicast support for its vrrp... and it's quite noisy. If there's a way to make it use unicast instead, I'd definitely like to know. corosync pacemaker can do a virtual IP failover between as many nodes as you like using unicast instead of multicast. ___ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
+1 On Jun 26, 2013, at 10:09 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, I would like to nominate John Garbutt for the nova-core team. John has been involved with nova for a long time now. He's primarily known for his great work on the xenapi driver. However, he has been contributing and reviewing in other areas, as well. Based on my experience with him I think he would be a good addition, so it would be great to have him on board to help keep up with the review load. Please respond with +1s or any concerns. References: https://review.openstack.org/#/dashboard/782 https://review.openstack.org/#/q/reviewer:782,n,z https://launchpad.net/~johngarbutt/+specs?role=assignee https://launchpad.net/~johngarbutt/+bugs?role=assignee Thanks, -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
On Wed, 2013-06-26 at 11:09 -0400, Russell Bryant wrote: I would like to nominate John Garbutt for the nova-core team. +1 John has been involved with nova for a long time now. He's primarily known for his great work on the xenapi driver. However, he has been contributing and reviewing in other areas, as well. Based on my experience with him I think he would be a good addition, so it would be great to have him on board to help keep up with the review load. -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
+1 On 06/26/13 at 11:09am, Russell Bryant wrote: Greetings, I would like to nominate John Garbutt for the nova-core team. John has been involved with nova for a long time now. He's primarily known for his great work on the xenapi driver. However, he has been contributing and reviewing in other areas, as well. Based on my experience with him I think he would be a good addition, so it would be great to have him on board to help keep up with the review load. Please respond with +1s or any concerns. References: https://review.openstack.org/#/dashboard/782 https://review.openstack.org/#/q/reviewer:782,n,z https://launchpad.net/~johngarbutt/+specs?role=assignee https://launchpad.net/~johngarbutt/+bugs?role=assignee Thanks, -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][Cinder][Hyper-V] iSCSI dealing in a High-Throughput Network
On 06/26/2013 11:42 AM, Peter Pouliot wrote: Hi Bruno, I’ll respond to the questions inline. I can't tell what was the original message and what was added. This may help: https://wiki.openstack.org/wiki/MailingListEtiquette#Outlook -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][Cinder][Hyper-V] iSCSI dealing in a High-Throughput Network
Hi Bruno, I’ll respond to the questions inline. Peter J. Pouliot, CISSP Senior SDET, OpenStack Microsoft New England Research Development Center One Memorial Drive,Cambridge, MA 02142 ppoul...@microsoft.commailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436 From: Bruno Oliveira ~lychinus [mailto:brunnop.olive...@gmail.com] Sent: Wednesday, June 26, 2013 10:00 AM To: Peter Pouliot Subject: [Openstack][Cinder][Hyper-V] iSCSI dealing in a High-Throughput Network Hello Peter, how are you doing? Excuse-me for the sudden email, but there's something very very important that I'd like to ask your advice for, if you don't mind. We're (at MANDIC) are now dealing with what would be the best protocol for when dealing with Cinder (Block Storage): NFS or iSCSI. ISCSI is the best option. As far as I've read, iSCSI is extremely resilient and more reliable than NFS since it already address issues like network faults, by using multiple channels as individual paths to make sure the data reaches its targets. On the other hand, NFS would require the infrastructure itself to guarantee the network connectivity. NFS exports a filesystem and require a nfs client at the OS layer. ISCSI can be consume directly via hardware and exports block devices. That for a production use is very important indeed, but I cannot forget of the performance between the two (I've also got to know that NFS might have a superior read IO, due to its read_cache, but it lacks when it comes to writing -- unless I have some sort of write cache, like the one deployed in the ZFS filesystem). So once again it depends on how you want to use it. NFS requires some sort of distributed filesystem under it to scale. Currently with ISCSI we just just plug in storage nodes, and don’t care about filesystems. Note: we have a Sun/Oracle Storage using the ZFS filesystem for what we're using currently. Question 1) In any case, I'd like to know your thoughts on it. I'm not sure myself if it would be somewhat possible to have Hyper-V (even 2012) using a NFS, is it possible at all ? So Hyper-V itself uses the native ISCSI client. (You need to start the iscsi initiator service). And that’s it. It can by default pass cinder iscsi volumes. In terms of comsuming NFS, there is also a native nfs client. That is a feature that must be installed, and I’m not entirely sure if it’s present or available on hyper-v server. You may need to use a full server sku for that. Now that being said in theory work could be done to have the cinder client work natively as long as that feature is present however currently it only supports iscsi. Question 2) Performance-wise, in a very high-throughput network (supposely 10G), would iSCSI perform better than other alternatives ? (I've read a lot on the internet, but as you know, I'm not sure how practical these articles can be or if they're just comparing them theorically) I personally ran ISCSI for years over 1G with out incident for production workloads with linux clusters. That being said, we still did dedicate interfaces for storage traffic. Thank you very much, Peter. Best regards. -- Bruno Oliveira Developer, Software Engineer irc: lychinus | skype: brunnop.oliveira brunnop.olive...@gmail.commailto:brunnop.olive...@gmail.com [https://drive.google.com/uc?export=viewid=0B2UQ5KHL27SYR1B0UVJUOWs4dmc]http://br.linkedin.com/in/brunnopoliveira [https://drive.google.com/uc?export=viewid=0B2UQ5KHL27SYYWxKTlU4ZlBueGc] http://twitter.com/lychinus [https://drive.google.com/uc?export=viewid=0B2UQ5KHL27SYWUhoeTg2b3FaZDg] http://gplus.to/lychinus ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] 1.9.0 release candidate
The RC for Swift 1.9.0 has been cut, and baring any issues discovered, will be finalized next Tuesday. Please take some time to try it out and run through your tests. Cahngelog: https://github.com/openstack/swift/blob/milestone-proposed/CHANGELOG Launchpad milestone page: https://launchpad.net/swift/+milestone/1.9.0 Code on the milestone-proposed branch: https://github.com/openstack/swift/tree/milestone-proposed Direct download: http://tarballs.openstack.org/swift/swift-milestone-proposed.tar.gz Major new features in this release include full global clusters support, improvements to disk performance, and conf.d-style config directory support. This is a great release that is the result of contributions from a lot of people. Thanks to everyone involved. --John smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Http library usage by clients
Right now Keystone provides so called bearer tokens: This means that whoever has a token can do whatever the token entitles him to do. If I manage to get somebody's token I can do whatever this person is able to do. To fix it, the other services that use tokens to: 1. Authenticate the identity 2. Match the name in the token to the identity that authenticated the connection. If the names match then you can be sure that the user that connected to the service and presented a token is the same user that acquired the token from keystone in the first place. To make this happen we need to add authentication to the connections between clients and services. To be able to do that we need to 1. Enable multiple forms of authentication per client. The best way to do this is to use a common client library, which we have developed in keystoneclient 2. Use the 'requests' libraray for HTTP across all clients 3. Enable running the API servers in Apache HTTPD. Making Eventlet support X509 CLient certs and Kerberos is going to be difficult, and the likelihood of introducing a security problem is high. https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token Jamie Lennox did the following analysis: Http library usage by clients Keystone: - Uses requests for the keystoneclient - Uses httplib for auth token middleware (i've got a patch to change it to requests). - Checks that os is patched before importing eventlet for cms. Glance: - Uses httplib for communication - Uses keystoneclient within cli - Checks that socket is patched before importing eventlet for httplib. Cinder: - Uses requests - Does not use keystoneclient - Uses sleep from evenlet or time based on ImportError of eventlet Ceilometer: - Uses keystoneclient within library. - Uses httplib - No eventlet Nova: - Uses requests - Does not use keystoneclient - No eventlet Horizon (obviously is a server): - Uses all clients - No eventlet Heat: - Uses keystoneclient within cli - Uses httplib - No eventlet Quantum - Uses httplib - Does not use keystoneclient - No eventlet Openstack Client: - Uses keystoneclient - Communicates via client libraries - No eventlet So this raises a couple of points. - We need to get Nova, Quantum and Cinder to use keystoneclient. - Eventlet is mostly gone from the clients already. I'm not sure how many of those http requests would end up actually blocking. - It would appear that clients have all at some point taken a central layout approach and with it taken httplib. We probably can't get them all changed over to requests before we try to add kerberos. - There is already a number of concerns around the way we use https. By default httplib does not verify https certificates, requests does and provides global ways of setting the bundle. https://wiki.openstack.org/wiki/SecureClientConnections already advocates for the transfer to requests with some interesting examples likehttps://bugs.launchpad.net/python-glanceclient/+bug/1079692 (Server's name isn't verified when using https) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
+1 On 06/26/2013 11:09 AM, Russell Bryant wrote: Greetings, I would like to nominate John Garbutt for the nova-core team. John has been involved with nova for a long time now. He's primarily known for his great work on the xenapi driver. However, he has been contributing and reviewing in other areas, as well. Based on my experience with him I think he would be a good addition, so it would be great to have him on board to help keep up with the review load. Please respond with +1s or any concerns. References: https://review.openstack.org/#/dashboard/782 https://review.openstack.org/#/q/reviewer:782,n,z https://launchpad.net/~johngarbutt/+specs?role=assignee https://launchpad.net/~johngarbutt/+bugs?role=assignee Thanks, -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Question about locking
Hi all, What happens if a greenthread, after acquiring a lock (not external), it dies? For example: A thread is performing the do_terminate_instance, it has the lock and before terminating the process it dies, what happens at the lock? Is that released in some way? If not I think that all other actions for that instance are blocked waiting for the lock, is that correct? Regards -- Andrea ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core
+1 On Wed, Jun 26, 2013 at 10:06 AM, Sean Dague s...@dague.net wrote: +1 On 06/26/2013 11:09 AM, Russell Bryant wrote: Greetings, I would like to nominate John Garbutt for the nova-core team. John has been involved with nova for a long time now. He's primarily known for his great work on the xenapi driver. However, he has been contributing and reviewing in other areas, as well. Based on my experience with him I think he would be a good addition, so it would be great to have him on board to help keep up with the review load. Please respond with +1s or any concerns. References: https://review.openstack.org/#**/dashboard/782https://review.openstack.org/#/dashboard/782 https://review.openstack.org/#**/q/reviewer:782,n,zhttps://review.openstack.org/#/q/reviewer:782,n,z https://launchpad.net/~**johngarbutt/+specs?role=**assigneehttps://launchpad.net/~johngarbutt/+specs?role=assignee https://launchpad.net/~**johngarbutt/+bugs?role=**assigneehttps://launchpad.net/~johngarbutt/+bugs?role=assignee Thanks, -- Sean Dague http://dague.net __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Ceilometer: Proposal to add resource_metadata to reporting Meter object
Our group would like to have resource_metadata available on the Meter object (currently it's not there). The reason is so we may supply additional customized attributes associated with a Meter. Examples include other timestamp values, a project owner, and processing status. Currently, to get these values we would need to request a Sample for the Meter. This is problematic because we often want to get Meter lists associated with certain customized attributes, such as the project owner. Changing the Meter spec (http://docs.openstack.org/developer/ceilometer/webapi/v2.html#Meter) to include resource_metadata would not require others to use the new field. Clients could ignore it as they do for Samples. It wouldn't necessarily require any code changes if we documented the field as not implemented. The only change it would require is to the Meter table schema, so that if someone were to supply the field it could be stored. Here is the wishlist item along with discussion. Any comments appreciated. https://bugs.launchpad.net/ceilometer/+bug/1194593 Thank you, Eric Pendergrass smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer]How to change Keystone properties
On 06/26/2013 03:41 PM, Pendergrass, Eric wrote:
I've been editing /etc/ceilometer/ceilometer.conf trying to change the
keystone provider:
[keystone]
auth_host=some host
auth_port=35357
auth_protocol=https
auth_uri=https://some host:35357
admin_user=user
admin_password=some password
Tracing throught auth_token.py, I see none of the configuration info
is picked up:
257 def __init__(self, app, conf):
258 pdb.set_trace()
259 self.LOG = logging.getLogger(conf.get('log_name',
__name__))
260 - self.LOG.info('Starting keystone auth_token middleware')
261 self.conf = conf
262 self.app = app
263
264 # delay_auth_decision means we still allow
unauthenticated requests
265 # through and we let the downstream service make
the final decision
(Pdb) p conf
{'memcache_secret_key': None, 'auth_protocol': 'https', 'admin_user':
None, 'admin_token': None, 'http_handler': None, 'signing_dir':
'/root/keystone-signing', 'auth_uri': None, 'auth_admin_prefix': '',
'memcache_security_strategy': None, 'admin_tenant_name': 'admin',
'auth_port': 35357, 'memcache_servers': None, 'delay_auth_decision':
False, 'cache': None, 'auth_version': None, 'token_cache_time': 300,
'admin_password': None, 'auth_host': '127.0.0.1', 'certfile': None,
'http_connect_timeout': None, 'keyfile': None}
I assumed the configuration would be within a [keystone] section in
ceilometer.conf. Have not found much documentation about this. Am I
missing something?
Thanks
Eric
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Is this what you are looking for?
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L182
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Configuring dm-crypt inside Host
Dear members, I was trying to configure dm-crypt in my openstack without creating virtual machines. I read the blueprint VolumeEncryption but somehow I am unable to configure encryption. I am also new to openstack so it would be really nice of you guys if you can share your knowledge with me to configure it. If someone has already did it then kindly tell me what changes do I need to make in order to accomplish it. And one more thing, it is written in that blueprint that encryption in VM is not possible. Is that true? Waiting for positive reply. -- -- Tauqeer Ahmad ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
