On 02/07/2012 16:33, Razique Mahroua wrote:
I've put a small section here
http://docs.openstack.org/diablo/openstack-compute/admin/content/multi-host.html
Using this I have made progress, except I had to use nova-manage
network delete 10.10.11.128/26 to delete the network and then added it
On 03/07/2012 09:53, Marnus van Niekerk wrote:
I can now see the bridge created and assigned an address on each
compute node, but all of the VMs get stuck after the bootloader - they
never boot any further.
Sorry, they do actually boot after a while but without any networking..
Hi,
I'd already setup nexenta in a independent server and nova-volume run on
another server with nexenta driver configured in nova.conf to provide volume
service to the openstack system.
I can use command or dashboard to create volume well and nexenta also have
create relative zol,but
My nexenta configuration in nova.conf on nova-volume server is:
#nova-volume
--routing_source_ip=$my_ip
--volume_driver=nova.volume.nexenta.volume.NexentaDriver
--nexenta_host=192.168.1.42
--nexenta_iscsi_target_portal_port=3260
--nexenta_rest_port=80
--nexenta_user=admin
On Tue, Jul 3, 2012 at 12:50 AM, Monty Taylor mord...@inaugust.com wrote:
At the moment, the only people with permission to upload tags is the
openstack-release team. However, since we're letting client libs manage
their own versions, I kinda think we should give PTLs the right on their
own
On Mon, Jul 02, 2012 at 12:09:55PM -0700, Johannes Erdfelt wrote:
On Mon, Jul 02, 2012, Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Jul 02, 2012 at 08:17:08AM -0700, Johannes Erdfelt wrote:
Not using /tmp for large files is a good reason for practical reasons
(distributions
Firstly, I'm just curious about their technology. I'm unable to make any
representative benchmark and that's why I was asking you about it. I'm just
a student during master thesis, interested in cloud computing, Openstack
etc. so I can't afford for such huge deployment :).
Secondly, I don't think
Hi Dan,
I'd like to implement this feather for quantum ,can you assign it to
me? the Milestone target is set to folsom-3,so I have a month to
implement,is it?
2012/7/2 Dan Wendlandt d...@nicira.com:
Hi Irena,
We've talked about adding this capability (blueprint here:
Try to remove that quotes from nexenta_target_prefix flag. They seem
to be the source of this problem.
Kind regards, Yuriy.
On Tue, Jul 3, 2012 at 12:45 PM, romi zhang romizhang1...@163.com wrote:
My nexenta configuration in nova.conf on nova-volume server is:
#nova-volume
Gabriel Hurley wrote:
On a more fundamental level, did I miss some tremendous reason why we have
this merge from common pattern instead of making OpenStack Common a
standard python dependency just like anything else? Especially with the work
Monty has recently done on versioning and
Thierry Carrez wrote:
Gabriel Hurley wrote:
On a more fundamental level, did I miss some tremendous reason why we have
this merge from common pattern instead of making OpenStack Common a
standard python dependency just like anything else? Especially with the work
Monty has recently done on
Joshua Harlow wrote:
Ack, please don’t keep on
adding on to the copy around stuff scheme. Plese :-)
You might have misread what Monty proposes. openstack-requires would
actually duplicate the openstack-common copy-around mechanism
(update.py) in an even more permanent way (openstack-common
I can assign the bug to me ,but can't assign the blueprint .
2012/7/3 Salvatore Orlando sorla...@nicira.com:
Hi Yaguang,
Folsom-3 will be release on August 16th. If nothing changes wrt Folsom-2 all
code should be in by August 14th, so it's about 40 days from today.
Out of curiosity, does
Monty Taylor wrote:
At the moment, the only people with permission to upload tags is the
openstack-release team. However, since we're letting client libs manage
their own versions, I kinda think we should give PTLs the right on their
own project - so Vish would get tag access to
Sorry to go back in the tread, but just wanted to ask a possibly dumb question.
Daniel P. Berrange wrote:
In the particular case of the qemu-img command described in earlier in this
thread, I'm not convinced we need a new option. Instead of using /tmp
when extracting a snapshot from an
On Tue, Jul 03, 2012 at 11:01:11AM +0100, John Garbutt wrote:
Sorry to go back in the tread, but just wanted to ask a possibly dumb
question.
Daniel P. Berrange wrote:
In the particular case of the qemu-img command described in earlier in this
thread, I'm not convinced we need a new
Daniel P. Berrange wrote:
On Mon, Jul 02, 2012 at 12:09:55PM -0700, Johannes Erdfelt wrote:
It seems to me that we're just as likely to have a review slip through
that uses /tmp insecurely as a review slipping through that uses /tmp at
all.
With my Vulnerability Management team hat on,
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: 03 July 2012 11:09
This would suggest there's a potential use case for a new config parameter
FLAGS.local_scratch_path, whose default value matches
FLAGS.instances_path if not set.
+1
Cheers,
John
Hey,
that's great, but how do you handle RabbitMQ in-between?
I kind of achieved it w/o OCF agents but used native upstart support of
Pacemaker, however,
OCF's are much more nicer, and still, I'd be interested in how you solved
the RabbitMQ issue.
Best regards,
Christian Parpart.
On Mon, Jul
Hi.
I think there is an error in the Keystone API docs [1].
The parameter password in the JSON request for create an user,
should be password and not OS-KSADM:password.
Regards,
Antonio.
[1]
On the Project release status meeting on today:
Only a few hours left before we cut milestone-proposed branches for
Folsom-2. We'll review what's left to do, defer stuff that won't make
it, get the PTL sign-off and refine the F2-targeted bug lists.
Feel free to add extra topics to the agenda:
On Jul 2, 2012, at 7:02 PM, Monty Taylor mord...@inaugust.com wrote:
Secondly, in addition to the normal per-commit tarballs, we're now
publishing tarballs of the form $project-$branch.tar.gz which will get
overwritten with each commit - that way, if you need to track trunk from
a
On Mon, 2 Jul 2012, Jay Pipes wrote:
On 07/02/2012 01:32 PM, Mark Lehrer wrote:
just did an ln -s /some/dir/with/space /tmp and that does solve
I added an option to /etc/init/nova_compute.conf to specify the tmp
space, so the start line looks like this:
exec su -s /bin/sh -c export
On Jul 3, 2012, at 5:31 AM, Thierry Carrez thie...@openstack.org wrote:
Gabriel Hurley wrote:
On a more fundamental level, did I miss some tremendous reason why we have
this merge from common pattern instead of making OpenStack Common a
standard python dependency just like anything else?
On Jul 2, 2012, at 6:40 PM, Monty Taylor mord...@inaugust.com wrote:
Hey all!
One of the tasks from the last ODS was to implement a single global
dependency list. Turns out the more you think about it, the more
important it is... because of the way we use devstack as part of the
gate, we
On Jul 3, 2012, at 5:57 AM, Thierry Carrez thie...@openstack.org wrote:
Monty Taylor wrote:
At the moment, the only people with permission to upload tags is the
openstack-release team. However, since we're letting client libs manage
their own versions, I kinda think we should give PTLs the
Hi,
I'm not sure that I fully understand the security angle that you're getting at
here, but you and Jay are right that we're focusing on adding heterogeneity to
Openstack. Right now we support large shared memory x86 machines, like SGI
UVs, GPUs, and Tilera systems. The blueprints you
Hi,
We configured the cloud infrastructure using openstack and it
is working fine as private.And the dashboard is accessible in public.
all the functions in the dashboard can use in public except vnc console .
When we are accessing the vnc it didn't showing any error, but no vnc
On 07/03/2012 08:43 AM, Doug Hellmann wrote:
On Jul 2, 2012, at 6:40 PM, Monty Taylor mord...@inaugust.com
wrote:
Hey all!
One of the tasks from the last ODS was to implement a single
global dependency list. Turns out the more you think about it, the
more important it is... because
Hello all,
I've been trying to get the live migration to work according to the guide
http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html.
So far i've setup 2 compute nodes and 1 controller node. They all share the
/var/lib/nova/instances dir. I've
Andrew Bogott abog...@wikimedia.org writes:
I. As soon as a patch drops into common, the patch author should
submit merge-from-common patches to all affected projects.
A. (This should really be done by a bot, but that's not going to
happen overnight)
Actually, I think with our
Hi Folks,
Is anyone else looking at how to support images that need a password rather
than an ssh key (windows) on hypervisors that don't support set_admin_password
(e.g. libvirt) ?
Thanks
Phil
___
Mailing list: https://launchpad.net/~openstack
Post
I have to agree with others that copying files around is not ideal, and I can
see the maintenance of this getting more involved as Nova becomes more coupled
with common.
Additionally, we'd make the copy only copy in the versions from
openstack-common for package that were already listed in
On Tue, Jul 3, 2012 at 2:01 AM, Simon G. semy...@gmail.com wrote:
Secondly, I don't think we shouldn't compare GCE to Openstack. I
understand that right now cloud (Openstack, Amazon, ...) is just easy in
use, managed and scalable datacenter. It allows users to create VMs, upload
their images,
On Mon, 2 Jul 2012, Ed Shaw wrote:
Hi,
I've posted on this previously but have yet to be pointed in the right
direction - so I'm posting again. Examples or docs appreciated.
I'm trying to pass user_data on server create using the xml (or JSON) api.
My userdata looks like...
#!/bin/bash
On 07/03/2012 10:09 AM, Eric Windisch wrote:
I have to agree with others that copying files around is not ideal, and
I can see the maintenance of this getting more involved as Nova becomes
more coupled with common.
Additionally, we'd make the copy only copy in the versions from
On Tue, Jul 3, 2012 at 9:54 AM, Monty Taylor mord...@inaugust.com wrote:
On 07/03/2012 08:47 AM, Doug Hellmann wrote:
On Jul 3, 2012, at 5:57 AM, Thierry Carrez thie...@openstack.org
wrote:
Monty Taylor wrote:
At the moment, the only people with permission to upload tags is
the
On Tue, Jul 03, 2012, Daniel P. Berrange berra...@redhat.com wrote:
It seems to me that we're just as likely to have a review slip through
that uses /tmp insecurely as a review slipping through that uses /tmp at
all.
We already run a bunch of PEP8 checks across the code on every
commit.
Which permissions did you set on /var/lib/nova/instances?
On Tue, Jul 3, 2012 at 3:48 PM, Leander Bessa Beernaert leande...@gmail.com
wrote:
Hello all,
I've been trying to get the live migration to work according to the guide
Currently it's using the default permission. Everything belongs to user
nova and the group nova.
On Tue, Jul 3, 2012 at 4:23 PM, Sébastien Han han.sebast...@gmail.comwrote:
Which permissions did you set on /var/lib/nova/instances?
On Tue, Jul 3, 2012 at 3:48 PM, Leander Bessa Beernaert
Here's an output from ls -l:
drwxr-xr-x 3 nova nova 4096 Jul 3 14:10 instances
On Tue, Jul 3, 2012 at 4:25 PM, Leander Bessa Beernaert leande...@gmail.com
wrote:
Currently it's using the default permission. Everything belongs to user
nova and the group nova.
On Tue, Jul 3, 2012 at 4:23
This seemed to crop up quite a lot in different sessions at the Design summit.
I am certainly interested in a standard way to inject information into VMs.
What I think we need is a cross hypervisor two-way guest communication channel
that is fairly transparent to the user of that VM (i.e.
Have you tried setting the ownership of /var/lib/nova/instances to the
nova user?
sudo chown -R nova:nova /var/lib/nova/instances
M
On 03/07/2012 15:48, Leander Bessa Beernaert wrote:
Hello all,
I've been trying to get the live migration to work according to the
guide
Matt,
I agree with almost everything that you're saying, except to add that we hope
to change things. I hope that our work at ISI is moving in that direction.
But you're right, hypervisors add some overhead, network performance isn't
always great, etc. Things are changing, albeit slowly,
Still the same problem :S
On Tue, Jul 3, 2012 at 4:46 PM, Marnus van Niekerk m...@mjvn.net wrote:
Have you tried setting the ownership of /var/lib/nova/instances to the
nova user?
sudo chown -R nova:nova /var/lib/nova/instances
M
On 03/07/2012 15:48, Leander Bessa Beernaert wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenStack Security Advisory: 2012-008
CVE: 2012-3360, 2012-3361
Date: July 3, 2012
Title: Arbitrary file injection/corruption through directory traversal
issues
Impact: Critical
Reporter: Matthias Weckbecker (SUSE Security team), Pádraig Brady (Red
On Tue, 3 Jul 2012, Day, Phil wrote:
Hi Folks,
Is anyone else looking at how to support images that need a password
rather than an ssh key (windows) on hypervisors that don't support
set_admin_password (e.g. libvirt) ?
I'm completely ignorant about windows.
Please forgive me.
Is it for
Hey all,
I'm currently working on supporting OpenVZ through the libvirt driver in
Nova.
I can successfully spin up and tear down OpenVZ containers using a slightly
modified version of devstack (yay!), but I've come across an issue with the
networking part of it that I could use some advice on
John, great job in compiling the data together! keep up the great job in
takin the pulse of the open source movement in cloud.
I would second Tim's observation about additional forums that Open Stack
uses for its developer and user community.
I would also suggest adding one particular vibrant
Hi,
I'm looking at nova, and the compute API has 3 methods:
delete_instance_metadata
update_instance_metadata
get_instance_metadata
I know that
* python nova client has
* the ability to specify --meta=KEY=VALUE on instance creation
* a top level subcommand 'meta' which allows set
Thanks John,
One approach we were wondering about is to have an agent in Windows which:
o Generates a random password and sets it for the admin account
o Gets the public ssh key from the metadata service
o Encrypts the password with the public key
o Pushes the encrypted public key
I found that updater and replicator could improve this issue.
In my original practice , for getting best performance , I only start main
workers ( account-server , container-server , object-server) , And keep
upload / download / delete objects over 100 times.
Issues:
1. XFS or Swift
Interesting idea, that seams reasonable.
The password is encrypted when it leaves the VM in the XenServer case too (if I
have understood the code correctly).
My only concerns are thinking about the more general solution:
* It only works on boot, so harder to change password if you
I think that's a good little explanation as to why we have openstack-common,
but when did it become a good reason to copy code around via an inclusion
mechanism?
Lots of code is in packages (outside of openstack, in pypi and elsewhere) that
is also in 'incubation' (in fact, what code isn't in
- Original Message -
From: Russell Bryant rbry...@redhat.com
To: andrewbog...@gmail.com
Cc: Andrew Bogott abog...@wikimedia.org, openstack@lists.launchpad.net
Sent: Monday, July 2, 2012 3:26:56 PM
Subject: Re: [Openstack] best practices for merging common into specific
HPC is often used as a general term but it is actually many different facets
depending on the computing model.
CERN is at the centre of a server grid of 100,000s of servers called WLCG
(http://wlcg.web.cern.ch) for analyzing the data from the Large Hadron
Collider. The servers are located at
Metadata is supposed to be user tags that are associated with a guest
that are available via the api. We discussed displaying these tags inside
the guest as well.
The main difference between user-data and metadata is that metadata is
available to the api, whereas user-data is only available in
I like the security of this idea, but it would also require that metadata is
available outside the vm which it isn't. What about creating a security group
that opens a specific port, and run a little webserver on that port in the
guest that makes the key available. That would mean you don't
On Tue, 3 Jul 2012, Vishvananda Ishaya wrote:
Metadata is supposed to be user tags that are associated with a guest
that are available via the api. We discussed displaying these tags inside
the guest as well.
Am I reading it wrong? It seems like it *is* available inside the guest.
At very
Congrats to Adam Young - now a member of Keystone Core. For those of you who
don't know, Adam drove the initial LDAP backend implementation for the new
keystone architecture, and has been the driving force (technically and code)
behind getting PKI enabled within Keystone for signed tokens as we
On Tue, 3 Jul 2012, John Garbutt wrote:
This seemed to crop up quite a lot in different sessions at the Design
summit. I am certainly interested in a standard way to inject information
into VMs.
What I think we need is a cross hypervisor two-way guest communication
channel that is fairly
On Tue, 3 Jul 2012, Vishvananda Ishaya wrote:
The config drive was a later addition because we thought it might be useful.
The plan was to add it to the metadata server once we had a /openstack
available.
The main difference between user-data and metadata is that metadata is
available
So, I understand the rationales, and I think of those three options the one
chosen is the most reasonable. I'm gonna just come out and say I hate this
whole idea, but let's set this aside for a minute 'cuz I have a genuine
question:
What will the process be for merging changes to this
The notion that copying code is any protection against APIs that may change is
a red herring. It's the exact same effect as pegging a version of a dependency
(whether it's a commit hash or a real version number), except now you have code
duplication. An unstable upgrade path is an unstable
On 07/03/2012 07:46 PM, Doug Hellmann wrote:
I've set up the ceilometer development documentation build on RTD at
http://ceilometer.readthedocs.org/en/latest/index.html
Hi,
I've updated https://launchpad.net/ceilometer to list this link.
Cheers
Ok thanks! I will have a look :D
We keep in touch ;)
On Tue, Jul 3, 2012 at 4:09 PM, Christian Parpart tra...@gmail.com wrote:
On Tue, Jul 3, 2012 at 1:35 PM, Sébastien Han han.sebast...@gmail.comwrote:
Hi,
Managing a resource via LSB only checks the PID. If the PID exists the
service is
It's a good and valid question and I don't really know. In this case,
I'm merely the pack-horse who was told global synchronized dependencies
lists! (not that I'm not the evil person cooking up schemes)
That said - most patches from new contributors don't actually come with
new library
+1 for getting over screams earlier rather than later
On 7/3/12 11:51 AM, Scott Moser smo...@ubuntu.com wrote:
On Tue, 3 Jul 2012, Vishvananda Ishaya wrote:
Metadata is supposed to be user tags that are associated with a guest
that are available via the api. We discussed displaying these tags
There wasn't a blueprint, but you can see the change here:
https://review.openstack.org/#/c/7542/
Bandwidth is updated in a DB table outside of notifications. Notifications
just pulls the last data received and sends it. With rapid state changes, I
would expect that bandidth_usage would
Agreed on all points, and I know you're not evil, Monty. ;-) (mostly)
You're totally right that this particular case won't stymie new contributors,
but as we've seen for changes to common--and sometimes even to the client
libraries or devstack--reviewers are in short supply and getting the
I 150% agree that is a red-herring, that's why I wonder what it really offers
besides a 'façade' and/or the feeling that what u are using isn't a package,
when in concept it really is, except now u have lost all the benefits of using
version numbers, having dependency versions (with history)
The discussion during the Keystone meeting today had a couple of key
points I'd like to address.
The Current token length is 32 characters long. An example:
e50d580692d644cfb8bec0246aede2c2
With PKI Signed tokens, they will be much longer
Dan Prince dpri...@redhat.com writes:
If someone wants to split openstack-common changes into patchsets that
might be Okay in small numbers. If you are merging say 5-10 changes
from openstack common into all the various openstack projects that
could translate into a rather large number of
Hi Daniel,
Attached is a patch that implements filtering on (architecture,
hypervisor_type, vm_mode) tuple as was discussed in this previous patch
https://review.openstack.org/#/c/9110/
CC'ing Chuck since he is the author of the ArchFilter patch.
Feedback appreciated before sending this off to
Hi Vish
On Wed, Jul 4, 2012 at 6:28 AM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Metadata is supposed to be user tags that are associated with a guest
that are available via the api. We discussed displaying these tags inside
the guest as well.
I've just been looking into what is
Yes, it's that time of the year again... time for us to choose the name
of the next OpenStack release !
This time, cities and counties in California (San Diego, CA being the
location of the G design summit)
I set up a poll with the available options (based on our current rules
of naming) at:
git submodules don't have to be linked to the head of a branch. Instead of
double-commiting (for every commit), we can do a single commit in each project
to change the git reference of the submodule. This would not be too far from
the existing behavior, except that it would minimize the double
On 7/3/12 5:47 PM, Eric Windisch wrote:
git submodules don't have to be linked to the head of a branch.
Instead of double-commiting (for every commit), we can do a single
commit in each project to change the git reference of the submodule.
This would not be too far from the existing behavior,
Hi,
As mentioned in the thread Jenkins and transient failures, we've had
an unusually high number of transient failures in Jenkins lately. We've
done several things in response to that:
1) Monty identified a problem with our pypi mirror which was the cause
of many of the errors, and corrected
TL;DR - Screw the rules, let's call the next release 'Grizzly'
As California is rather lacking in the 'municipality names starting with a G
that we should use for an OpenStack release' department, I have had to look
*slightly* outside the ruleset to find a suitable 'G' release name - that name
I’m pretty -1 on triggering changes in other projects from common. That’s gonna
result in a broken code (whether subtle or obvious) no matter how good your
gates are.
At least as an external library you can freeze a version requirement until such
time as you see fit to properly updated that
On 07/03/2012 04:50 PM, Brian Waldon wrote:
TL;DR - Screw the rules, let's call the next release 'Grizzly'
Do it!
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe :
+1 for Grizzly
On Jul 3, 2012 8:02 PM, Brian Waldon brian.wal...@rackspace.com wrote:
TL;DR - Screw the rules, let's call the next release 'Grizzly'
As California is rather lacking in the 'municipality names starting with a
G that we should use for an OpenStack release' department, I have had
+1 on close enough to an arbitrary territory and also a great name. ;-)
Also, the Grizzly is the California state animal:
http://www.statesymbolsusa.org/California/animal_grizzly_bear.html
Food for thought.
- Gabriel
From:
tl;dr - Screw the rules, I agree
Let's at least add it to the poll.
Also - I think we should further amend the rules such that we select the
NEXT release by the summit for the current release. That means two things:
At the g summit, we'd tell everyone where the next summit is:
At the g summit,
I've been following along at home a bit. I can totally see where it's
desirable to have well thought out APIs that you can commit to supporting and
encourage other people to use. And that you sometimes have expedient code that
you aren't as comfortable with.
What I don't get is how using
On 07/03/2012 05:07 PM, Duncan McGreggor wrote:
On Tue, Jul 3, 2012 at 5:39 PM, Dan Wendlandt d...@nicira.com wrote:
Lately, Quantum reviewers have been doing their best to enforce python style
guidelines above and beyond the programmatically enforced pep8 checks. This
has happened for many
On 07/03/2012 07:29 PM, Brian Waldon wrote:
On Jul 3, 2012, at 5:21 PM, Monty Taylor wrote:
tl;dr - Screw the rules, I agree
Let's at least add it to the poll.
Also - I think we should further amend the rules such that we select the
NEXT release by the summit for the current release.
+1 grizzly
On Jul 3, 2012, at 7:45 PM, Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote:
+1 on “close enough to an arbitrary territory and also a great name”. ;-)
Also, the Grizzly is the California state animal:
On 07/03/2012 04:23 PM, Gabriel Hurley wrote:
Agreed on all points, and I know you're not evil, Monty. ;-)
(mostly)
Dammit. I'm going to HAVE to try harder... see my other post about
Bulgarian bars with freezers...
You're totally right that this particular case won't stymie new
Interestingly enough - gerrit supports submodules pretty well... and it
does exactly what Eric said below ... if both the project and
superproject are in gerrit, and a change is made to the project, gerrit
can automatically update the superproject reference.
Here's the thing though (and one of
On 07/03/2012 07:33 PM, James E. Blair wrote:
Brian Waldon brian.wal...@rackspace.com writes:
TL;DR - Screw the rules, let's call the next release 'Grizzly'
As California is rather lacking in the 'municipality names starting
with a G that we should use for an OpenStack release'
I would like to come out as strongly pro-Grizzly.
I wonder if this release name would make Thierry the moma grizzly:
http://en.wikipedia.org/wiki/Mama_grizzly
dan
On Wed, Jul 4, 2012 at 1:33 AM, James E. Blair cor...@inaugust.com wrote:
Brian Waldon brian.wal...@rackspace.com writes:
TL;DR
I talked with folks a bit about this offlist. Here's the summary:
I think everyone agrees that there is a value in enforcing style guidelines
that go beyond what can be mechanically enforced via pep8, namely, things
covered in HACKING.rst (such as doc-strings formatting). Tools for
automatic
On Jun 29, 2012, at 9:53 PM, Adam Young wrote:
On 04/01/2012 11:15 AM, Lorin Hochstein wrote:
On Mar 29, 2012, at 12:40 PM, Daniel P. Berrange wrote:
On Wed, Mar 28, 2012 at 04:41:28PM -0400, Lorin Hochstein wrote:
All:
Given that I have a qcow2 image from somewhere (e.g.,
Grizzly is better than people making who is john galt jokes.
+1 to grizzly.
On Tue, Jul 3, 2012 at 5:51 PM, Mark Collier mark.coll...@rackspace.comwrote:
+1 grizzly
On Jul 3, 2012, at 7:45 PM, Gabriel Hurley gabriel.hur...@nebula.com
wrote:
+1 on “close enough to an arbitrary
It might be nice to set it up so that openstack admins can add metadata
values to the metadata server for installation wide use.
-Matt
On Tue, Jul 3, 2012 at 3:10 PM, Steve Baker st...@stevebaker.org wrote:
Hi Vish
On Wed, Jul 4, 2012 at 6:28 AM, Vishvananda Ishaya
vishvana...@gmail.com
On Jul 3, 2012, at 4:55 PM, Adam Young ayo...@redhat.com wrote:
However, nothing in the API comments on the token length.
This is very intentional! If a specific length is documented somewhere, it
should be corrected.
-Dolph Mathews
___
Mailing
Yuriy,
Thanks for your reply.
I try to uncomment
--nexenta_target_prefix=iqn.1986-03.com.sun:01:005008c802ff.4fb2f97d and then
restart nova-volume, but the result is still error as same as before,volume
service log has no error,but compute node brief log is:
Attaching volume 1 to /dev/vdc
Sorry,nova-volume was not stop clearly, when I uncomment
--nexenta_target_prefix, create a volume is fine,but still could not attach it
to instance, compute node log is just :
ISCSI volume not yet found at: vdc. Will rescan retry. Try number: 0
And in dashboard,it was failing into attaching
1 - 100 of 113 matches
Mail list logo
