Hi operators,
I wanted to ask for feedback on a design issue regarding DHCP agent and IP per
agent.
Very happy about dev's coming here for input :)
Now, regarding the IP consumption there are two possible alternatives:
1. Use single IP per serviced subnet for all the servers. (similar to
You are correct, deleted images are not deleted from the DB, rather their row
has ‘deleted=1’, so specifying the UUID of another image already in glance for
a new image being upload will end in tears.
What I was trying to convey was, when Christian is uploading a new image of the
same name as
I've never worried about Image not Found, as its only a UI concern. IMO
it lets the users know something has changed. Totally optional, and the
same effect can be gained by just renaming it -OLD and leaving it public.
At some point, it still needs to be removed.
On Tuesday, October 7, 2014,
It would be nice to have an archive status for images, where brand new
instances may not be launched off it, but where it may be used as a
reference for existing instances and snapshots.
Not sure about other folks, but we just keep piling up the old images, and
they have to remain public. There's
Hello,
Yes, I agree that this is not big problem when there is info Image not found
in horizon but I saw this discussion and I thought that I will ask about that
:) It would be nice to have some other info like for example: Image 1
(archived) or something like that :)
---
Best regards
Sławek
Right, and I think the best thing about marking a deprecated image private is
that
new instances can’t select that image unless the tenant is an image-member of
it.
So if a specific tenant has some “real valid” need to use the old version (I
can’t imagine why), they could find it in “Project
Hi,
Please note the issue reported in
https://bugs.launchpad.net/nova/+bug/1160773: Cannot resize instance if
base image is not available
AFAIK it is still the case that instances cannot be resized or migrated
once the image from which it has been created has been deleted.
cheers, Jan
On
Il 07/10/2014 16:31, Jeremy Stanley ha scritto:
Indeed, OpenStack's project infrastructure and quality assurance
teams have been collaboratively managing a very large
logstash+elasticsearch cluster for use in classifying bugs witnessed
while performing CI testing on proposed changes. The