FWIW, option 2 is almost required unless we plan to be able to bundle multiple environments with a single template. While having a single environment for a single template can be useful, the even *more* useful scenario (and the primary one driving the development of environments initially) is when you have options as to how a template behaves (use Trove for the backend or pop vms and software config to install a database). IMO, you'd want to de-couple environments from the templates given that multiple environment could work for the same template. On Jul 20, 2016, at 8:58 AM, "Mikhail Fedosin" <mfedo...@mirantis.com> wrote:
> > > On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng <teng...@linux.vnet.ibm.com> > wrote: > On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote: > > Hello! > > > > Today it was announced that Glare is ready for public review > > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html So > > we are ready to start working on integration Heat with Glare and > > implementing a POC. After discussions with Glare team we see two design > > options: > > > > 1) Create one artifact type that will contain template, nested templates > > and environments. > > Pros: It is easy to maintain integrity. Since artifact is immutable, we can > > guarantee the consistency and prevent from accidentally removing of > > dependent environment. > > Cons: If we need to add new environments to use them with template, we need > > to create new artifact. > > > > 2) Create 2 artifact types: environment and template. > > Pros: It is easy to add new environments. You just need to create new > > dependency from template artifact to environment one. > > Cons: Some environment can be (mistakenly) removed, and template that have > > dependencies on it will be in inconsistent state. > > Option 2 looks more flexible to me. I'm not sure we are encouraging > users to introduce or rely on a hard dependency from a template to an > environment file. With that, it is still good to know whether glare > supports the concept of 'reference' where a referenced artifact cannot > be deleted. > > Hey! > > Indeed, option 2 is more flexible, but in this case users have to manually > control dependencies, which is may be hard sometimes. Also, initially Glare > won't support 'hard' dependencies, this feature will be added in next > version, because it requires additional discussions. For this reason I > recommend option 1 and let Glare control template consistency for you, it > won't allow users to break anything. > > Best, > Mike > > > - Qiming > > > So we want to hear your opinions and suggestions on the matter. Thanks in > > advance! > > > > Best regards, > > Oleksii Chuprykov > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
