Thanks Sam. We purposefully chose that time to accommodate some of our
community members from the Pacific. I'm assuming it's just your case
that's not working out for that time? So, hopefully other Australian/NZ
friends can join.
On 5/26/16 12:59 AM, Sam Morrison wrote:
> I’m hoping some people f
I’m hoping some people from the Large Deployment Team can come along. It’s not
a good time for me in Australia but hoping someone else can join in.
Sam
> On 26 May 2016, at 2:16 AM, Nikhil Komawar wrote:
>
> Hello,
>
>
> Firstly, I would like to thank Fei Long for bringing up a few operator
I don't have cycles to support this development, but I do think that the
function is worth while, wether you are using a 3rd party IPAM model or
not, there are plenty of developers who expect a specific IP Address (even
if it was randomly assigned via some other process, like booting without
defini
Hi All,
We carry one small local change in Horizon and I'm trying to determine
if there's enough community interst in similar things that we should
go through the process of upsreaming it.
In order to provide access to our preexisting self-service IPAM and
DNS registration services we allow and i
Join us Thursday for our weekly meeting, scheduled for May 26th at
17:00UTC in #openstack-meeting-3
The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog
This week we will see some
We will want to move the main repo to OpenStack infra, with the usual
mirror to github.com/openstack/craton. I don't think we need to worry about
mirroring to github.com/rackerlabs/craton as well. A simple reference there
pointing to the new location should suffice.
Basically I'm just trying to ke
True, we will want to wait if we want decide to move or copy the
rackerlabs/craton repo. I can create the project patch and then pin it so
it doesn't get merged.
On Wed, May 25, 2016 at 10:27 AM, Jim Baker wrote:
> Sean, thanks for your help here, it's very much appreciated!
>
> The move then sh
Sean, thanks for your help here, it's very much appreciated!
The move then should be straightforward once we get past our first
milestone, on or around June 10; but any prep in advance sounds good.
On Wed, May 25, 2016 at 12:37 PM, sean roberts
wrote:
> Now that we have settled on the name, s
Le 21/01/2016 à 18:02, Arne Wiebalck a écrit :
> Dear all,
>
> On compute nodes with high instance turn-over we’re accumulating quite
> some log files in /var/log/libvirt/qemu/.
> https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1460197 is
> mentioning this issue as well.
>
> While re
Slight concern on how to deploy on a RHEL system base as software collections
are non-trivial.
If we can keep the client to be still python 2.X compatible, that would be a
significant help.
Getting good development productivity/deployments should probably outweigh
these concerns though…
Tim
Now that we have settled on the name, setting up the project infrastructure
is straightforward. I have done this a few times and am ready to do it for
craton.
On Tue, May 24, 2016 at 3:51 PM, Jim Baker wrote:
> On Tue, May 24, 2016 at 6:36 PM, Sam Morrison wrote:
>
>> I’m in favour of using 3.5
On 25/05/16 17:36, "Sean Dague" wrote:
>On 05/23/2016 10:24 AM, Tim Bell wrote:
>>
>>
>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>> syntax for limiting actions by user. According to
>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>> apparentl
Hello,
Firstly, I would like to thank Fei Long for bringing up a few operator
centric issues to the Glance team. After chatting with him on IRC, we
realized that there may be more operators who would want to contribute
to the discussions to help us take some informed decisions.
So, I would like
On 05/23/2016 10:24 AM, Tim Bell wrote:
>
>
> Quick warning for those who are dependent on the "user_id:%(user_id)s"
> syntax for limiting actions by user. According to
> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
> apparently not intended according to the bug report feedba
From: Antoni Segura Puimedon [mailto:toni+openstac...@midokura.com]
Sent: May-25-16 6:55 AM
To: OpenStack Development Mailing List (not for usage questions); Gal Sagie;
openstack-operators
Subject: Re: [openstack-dev] [kuryr][magnum]Installing kuryr for mutlinode
openstack setup
On Wed, May
Hi,
Thanks Jaume and Antoni.
I tried the installation by git cloning the kuryr repo. I did pip install
-r requirements.txt. After that I did pip install . . But it doesn't end
successfully. There are no config files in /etc/kuryr directory.
root@compute1:~/kuryr# pip install .
Unpacking /root/kuryr
Hi, I'm working on being able to reload a service's config file. This
may be useful for EG turning debug logging on/off*, tweaking live
migration parameters and changing the number of workers.
Operators, which options would you like to be mutable (reloadable)? I'm
interested in Nova for now, if ot
On Tue, May 24, 2016 at 10:21 PM, Michael Still wrote:
> On Wed, May 25, 2016 at 3:28 AM, Dan Smith wrote:
>
>> > It was my impression we were trying to prevent bitrot, not defend
>> > against an attacker that has gained control over the compute node.
>>
>> I think we've established that address
18 matches
Mail list logo
