roach before I go any
further.
The other approach that makes sense to me would be to add a magic option to
the log_date_format option (e.g., log_date_format = rfc3339 or
log_date_format= rfc5424) that made %(asctime)s into an RFC3339 timestamp.
Thoughts or suggestions? Thanks.
--
Chris St. P
ts. Let's make sure we don't start using a pattern that will cause
> significant issues down the road.
>
> --Morgan
>
> Sent via mobile
>
> On May 7, 2015, at 09:37, Chris St. Pierre
> wrote:
>
> This bug recently came to my attention:
> https://bugs.launchp
is there a better way to tackle the problem altogether?
Thanks!
--
Chris St. Pierre
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
h
actual
security group. That is, adding a new rule with 'nova
secgroup-add-default-rules' has absolutely no effect on what network
traffic is allowed between guests; it only affects new tenants created
afterwards.
--
Chris St. Pierre
___
st resort.)
How can we clean up the wording to make it clear that "the default security
group" is, in fact, not "the 'default' security group" or "the security
group which is default," but rather another beast entirely which isn't even
actuall
2015 at 5:19 AM, Flavio Percoco wrote:
> On 12/02/15 09:34 -0800, Chris St. Pierre wrote:
>
>> Yeah, that commit definitely disables the file-backed queue -- it
>> certainly
>> *looks* like we want to be rid of it, but all of the code is left in
>> place and
>>
12:59 AM, Flavio Percoco wrote:
> On 11/02/15 13:42 -0800, Chris St. Pierre wrote:
>
>> I recently proposed a change to glance to turn the file-backed scrubber
>> queue
>> files into JSON: https://review.openstack.org/#/c/145223/
>>
>> As I looked into it more
ke sure that code is reachable again, and I'll
resurrect my blueprint to make the queue files suck less.
Either way I'm happy to make the changes, I'm just not sure what the goal
of these changes was, and how to properly proceed.
Thanks for any clarification anyo
n the same
installation. I do not consider it a solution to the problem that images
can be deleted in use to take the "protected" flag away from arbitrary,
bespoke use.
On Thu, Dec 18, 2014 at 6:44 PM, Jay Pipes wrote:
> On 12/18/2014 02:08 PM, Chris St. Pierre wrote:
>
>> I wasn
mailto:nikhil.koma...@rackspace.com]
> *Sent:* 17 December 2014 20:34
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [glance] Option to skip deleting images in
> use?
>
>
>
> Guess that's a implementation
s. However, it would be
> too racy unless we we implement a test-and-set for such properties or there
> is a different job which queues up these requests and perform sequentially
> for each tenant.
>
> Thanks,
> -Nikhil
> ----------
> *From:* Chris S
wrote:
> A simple solution that wouldn’t require modification of glance would be a
> cron job
> that lists images and snapshots and marks them protected while they are in
> use.
>
> Vish
>
> On Dec 16, 2014, at 3:19 PM, Collins, Sean <
> sean_colli...@cable.comcast.
mage with
> 'protected'=True, then the image can't be deleted by accidentally.
>
> On 17/12/14 10:23, Chris St. Pierre wrote:
>
> The goal here is protection against deletion of in-use images, not a
> workaround that can be executed by an admin. For instance, someone
d for taking backups, but most of
us take backups anyway. Same deal.
On Tue, Dec 16, 2014 at 2:30 PM, Jay Pipes wrote:
> Just set the images to is_public=False as an admin and they'll disappear
> from everyone except the admin.
>
> -jay
>
>
> On 12/16/2014 03:09 PM
o the trouble of writing a spec
for it, particularly since it doesn't appear that glance currently talks to
Nova as a client at all. Is this something that folks would be interested
in having? Thanks!
--
Chris St. Pierre
___
OpenStack-dev ma
, inconsistent restrictions
Juno: Unicode, consistent restrictions
Kilo (?): Use anything you want
At any rate, if accepting Unicode is an issue, then it's been an issue for
a while.
--
Chris St. Pierre
Senior Software Engineer
metacloud.com
_
Linking clearly isn't my strong suit:
https://review.openstack.org/#/c/119741/
On Mon, Sep 15, 2014 at 1:58 PM, Chris St. Pierre
wrote:
> On Mon, Sep 15, 2014 at 11:16 AM, Jay Pipes wrote:
>
>> I believe I did:
>>
>> http://lists.openstack.org/pipermail/openstack-
nstack-dev>
>
Well, sure. I meant other than that. :)
My review is at https://review.openstack.org/#/c/119421/ if anyone does
find time to +N it. Thanks all!
--
Chris St. Pierre
Senior Software Engineer
metacloud.com
___
OpenStack
consensus on whether or not I need to go through the
interminable blueprint process to get this accepted.
So since everyone seems to think that this is at least not a bad idea, and
since no one seems to know why it was originally changed, what stands
between me and a +2?
Thanks.
--
Chris St. P
yone knows any reason why these printable characters should
not be joined in holy resource naming, speak now or forever hold your peace.
Thanks!
--
Chris St. Pierre
Senior Software Engineer
metacloud.com
___
OpenStack-dev mailing list
OpenStack-dev
20 matches
Mail list logo
