On Wed, Oct 2, 2013 at 11:39 AM, Michael Basnight <mbasni...@gmail.com>wrote:
> On Oct 2, 2013, at 9:21 AM, Craig Vyvial wrote: > > > If a configuration is updated that is attached to N instances then those > instances will be updated with the configuration overrides. This will keep > the configuration n-sync[hah 90s boy band reference] with instances that > have it attached. I'm not sure that this is really a "confusing situation" > because you are updating the configuration key/values. This will not update > the UUID of the configuration because we are not trying to make the changes > like a sub-versioned system. > > ok if thats the expected behavior, im ok with that. ByeByeBye with the > other options ;) > > > > > 'configuration' is a resource that can be applied only to instances. > Making it a sub-resource of '/instances' is an option but does that warrant > it always being tied to an instance? > > No. > > > > > Each configuration is unique to a tenant and therefore doesnt allow a > reseller to create a tweaked out config. I see value in allowing resellers > to do this but currently they can update the templates that are used in the > system. > > I mean a single tenant being that reseller. He has 1 template he applies > to all his db instances for his customers, which he supports outside of > trove. > This sounds similar to supporting roles or sharing resources. This is a great use case and if we were to put configurations under instances would we be able to achieve this? I'm thinking no? > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
