I installed a minimal cloud image (cirros) and found that it had no
network configures after booting. Even running udhcpc manually does not
work - it never gets an answer from dhcp.
I checked and dnsmasq is running on all of the the compute nodes:
/usr/sbin/dnsmasq --strict-order --bind-interf
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
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
I
On Jul 3, 2012, at 4:55 PM, Adam Young 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 list: https://launch
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 wrote:
> Hi Vish
>
> On Wed, Jul 4, 2012 at 6:28 AM, Vishvananda Ishaya
> wrote:
> > Metadata is supposed to be use
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 wrote:
> +1 grizzly
>
>
> On Jul 3, 2012, at 7:45 PM, "Gabriel Hurley"
> wrote:
>
> +1 on “close enough to an arbitrary territory and also a great name”.
> ;-)
>
> **
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 som
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 che
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 wrote:
> Brian Waldon writes:
>
> > TL;DR - Screw the rules, let's call the next
On 07/03/2012 07:33 PM, James E. Blair wrote:
> Brian Waldon 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' department, I
>> have had t
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 the
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
> contribu
+1 grizzly
On Jul 3, 2012, at 7:45 PM, "Gabriel Hurley"
mailto: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:
http://www.statesymbolsusa.org/California/animal_grizzly_bear.html
Foo
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 cur
On 07/03/2012 05:07 PM, Duncan McGreggor wrote:
> On Tue, Jul 3, 2012 at 5:39 PM, Dan Wendlandt 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 recent r
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. That means two things:
>
> At the g summi
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 a
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, w
+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: openstack-bounces+gabriel.hurley=nebula@lists.launchpa
+1 for Grizzly
On Jul 3, 2012 8:02 PM, "Brian Waldon" 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 to
> look *slightly*
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 : https://launchpad.net/~o
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 cod
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
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
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, e
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 c
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:
htt
Hi Vish
On Wed, Jul 4, 2012 at 6:28 AM, 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.
I've just been looking into what is already in place to imp
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
On Tue, Jul 3, 2012 at 5:39 PM, Dan Wendlandt 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 recent reviews, so Mark isn't being singled out here,
My objec
Dan Prince 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 reviews (25+) for
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
MIICgAYJKoZIhvcNAQcCoIICcTCCAm0CAQExCTAHBgUrDgMCGjC
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) and
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 chang
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 mostl
+1 for getting over screams earlier rather than later
On 7/3/12 11:51 AM, "Scott Moser" 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 inside
> th
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 dependenc
Ok thanks! I will have a look :D
We keep in touch ;)
On Tue, Jul 3, 2012 at 4:09 PM, Christian Parpart wrote:
> On Tue, Jul 3, 2012 at 1:35 PM, Sébastien Han wrote:
>
>> Hi,
>>
>> Managing a resource via LSB only checks the PID. If the PID exists the
>> service is running but it's not enough b
On 7/3/12 1:59 PM, Gabriel Hurley wrote:
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
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
___
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 upgra
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 requireme
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
> >>
On Jul 3, 2012, at 11:51 AM, Scott Moser 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 inside
>> the guest as well.
>
> Am I reading it wro
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 f
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, 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
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 nee
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 t
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 o
- Original Message -
> From: "Russell Bryant"
> To: andrewbog...@gmail.com
> Cc: "Andrew Bogott" , openstack@lists.launchpad.net
> Sent: Monday, July 2, 2012 3:26:56 PM
> Subject: Re: [Openstack] best practices for merging common into specific
> projects
>
> On 07/02/2012 03:16 PM
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 p
I've set up the ceilometer development documentation build on RTD at
http://ceilometer.readthedocs.org/en/latest/index.html
Doug
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpa
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 forgo
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 consumes
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 bac
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 a
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 c
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 from
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
-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
H
Still the same problem :S
On Tue, Jul 3, 2012 at 4:46 PM, Marnus van Niekerk 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:
>
>> Hello
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, but
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
http://docs.openstack
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. ideall
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 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 PM, Sébastie
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 wrote:
> Which permissions did you set on /var/lib/nova/instances?
>
>
> On Tue, Jul 3, 2012 at 3:48 PM, Leander Bessa Beernaert <
> leande...@gmail.c
Which permissions did you set on /var/lib/nova/instances?
On Tue, Jul 3, 2012 at 3:48 PM, Leander Bessa Beernaert wrote:
> 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-
On Tue, Jul 03, 2012, Daniel P. Berrange 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. It ought to
On Tue, Jul 3, 2012 at 9:54 AM, Monty Taylor wrote:
>
>
> On 07/03/2012 08:47 AM, Doug Hellmann wrote:
> >
> > On Jul 3, 2012, at 5:57 AM, Thierry Carrez
> > wrote:
> >
> >> Monty Taylor wrote:
> >>> At the moment, the only people with permission to upload tags is
> >>> the openstack-release tea
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
>>> o
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...
> "#!
On Tue, Jul 3, 2012 at 2:01 AM, Simon G. 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, easily increa
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
On Tue, Jul 3, 2012 at 1:35 PM, Sébastien Han wrote:
> Hi,
>
> Managing a resource via LSB only checks the PID. If the PID exists the
> service is running but it's not enough because it doesn't mean that the
> service is truly functionnal. However OCF agents offer more features like
> fine monitor
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 t
Andrew Bogott 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 current level of tooli
On 07/03/2012 08:47 AM, Doug Hellmann wrote:
>
> On Jul 3, 2012, at 5:57 AM, Thierry Carrez
> 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 versi
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 alre
On 07/02/2012 08:43 PM, Joshua Harlow wrote:
> Ack, please don’t keep on adding on to the copy around stuff scheme.
> Plese :-)
You know - I was a huge opponent to the copy around stuff scheme when it
started. It raised all of my hackles and I got all upset about things
not being done the "r
On 07/03/2012 08:43 AM, Doug Hellmann wrote:
>
>
> On Jul 2, 2012, at 6:40 PM, Monty Taylor
> 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 th
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
scree
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 linked
On Jul 3, 2012, at 5:57 AM, Thierry Carrez 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 right on their
>
On Jul 2, 2012, at 6:40 PM, Monty Taylor 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 actually _curr
On Jul 3, 2012, at 5:31 AM, 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 wi
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
On Jul 2, 2012, at 7:02 PM, Monty Taylor 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 pip-requires file, (such
2012/7/3 John Garbutt :
>> 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,
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:
[
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]
http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_addUser_v2.0_users_Admin
Hi,
Managing a resource via LSB only checks the PID. If the PID exists the
service is running but it's not enough because it doesn't mean that the
service is truly functionnal. However OCF agents offer more features like
fine monitoring (scripting).
I'm not sure to understand your question about R
Hi-
With respect to the web link
http://wiki.openstack.org/HeterogeneousTileraSupport,
"
For supporting non-x86 architecture (ex. TILERA), Proxy Compute Node should
be designed.
An x86 Proxy Compute Node is connected to the TILEmpower boards through
network. A Proxy Compute Node may handle multi
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 2,
> 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
__
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 o
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
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 exi
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 python-nova
I can assign the bug to me ,but can't assign the blueprint .
2012/7/3 Salvatore Orlando :
> 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 lunchpad allow y
1 - 100 of 114 matches
Mail list logo
