+1
On Tue, Aug 26, 2014 at 8:54 AM, Tim Simpson
wrote:
> +1
>
>
> From: Sergey Gotliv [sgot...@redhat.com]
> Sent: Tuesday, August 26, 2014 8:11 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kuma
There is the database migration for datastores. We should add a function
to back fill the existing data with either a dummy data or set it to
'mysql' as that was the only possibility before data stores.
On Dec 18, 2013 3:23 PM, "Greg Hill" wrote:
> I've been working on fixing a bug related to m
have
> to correct.
> 3. Put the onus on the deployer to fill out values in the config value
>
> Greg
>
> On Dec 18, 2013, at 8:46 PM, Robert Myers wrote:
>
> There is the database migration for datastores. We should add a function
> to back fill the existing data wit
+1
On Fri, Dec 27, 2013 at 4:48 PM, Michael Basnight wrote:
> Howdy,
>
> Im proposing Auston McReynolds (amcrn) to trove-core.
>
> Auston has been working with trove for a while now. He is a great
> reviewer. He is incredibly thorough, and has caught more than one critical
> error with reviews a
We could always use relative imports in oslo :) Then you could put it where
ever you wanted to without needing to rewrite the import statements.
On Mon, Jan 13, 2014 at 11:07 AM, Doug Hellmann wrote:
> [resurrecting an old thread]
>
>
> On Wed, Nov 27, 2013 at 6:26 AM, Flavio Percoco wrote:
>
I like #4 over #5 because it seems weird to have to create a configuration
first to see what parameters are allowed. With #4 you could look up what is
allowed first then create your configuration.
Robert
On Jan 22, 2014 10:18 AM, "Craig Vyvial" wrote:
> Hey everyone I have run into an issue with
+1
On Tue, May 6, 2014 at 9:38 AM, Michael Basnight wrote:
>
> > On May 6, 2014, at 2:31 AM, Nikhil Manchanda
> wrote:
> >
> >
> > Hello folks:
> >
> > I'm proposing to add Craig Vyvial (cp16net) to trove-core.
> >
> > Craig has been working with Trove for a while now. He has been a
> > consist
I'm pulling this conversation out of the gerrit review as I think it needs
more discussion.
https://review.openstack.org/#/c/53499/
I want to discuss the design decision to not use Jinja templates for the
heat templates. My arguments for using Jinja for heat as well are:
1. We have to rewrite al
ration that is why it doesn't need to
> genereate/modify heat templates on-the-go.
>
> Please take a look at this one https://review.openstack.org/#/c/54315/
>
>
> 2013/10/29 Robert Myers
>
>> I'm pulling this conversation out of the gerrit review as I thin
I hear you Clint. I'm not an expert on heat templates so it is possible to
do this all with one. However I don't want to use Jinja to replace the heat
template logic just for sane template loading. We are already using Jinja
templates to load custom config files. So it makes sense to re-use the sam
10 matches
Mail list logo
