> > I also remember that Heat has smth like 'hidden' in resource plugin > declaration. Usually it is used to hide deprecated resource types so that > new stacks with those can not be created but old ones can be at least > deleted. May be you could use that flag while developing until you think > that resource is already usable, although it might complicate your own > testing of those resources.
In addition, I advice you to use UNSUPPORTED status untill resource will not be fully implemented. For details, suggest to read resource support status page <https://docs.openstack.org/developer/heat/developing_guides/supportstatus.html#life-cycle-of-resource-property-attribute> . 2017-04-11 17:27 GMT+04:00 Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com>: > Hi Norbert, > > my biggest concern with the workflow you've shown is that in the meantime > it would be possible to create undeletable stacks / stacks that leave > resources behind after being deleted. As the biggest challenge is usually > in updates (if it is not UpdateReplace) I'd suggest implementing create and > delete together. To ease development you could start with only basic > properties for the resource if it is possible to figure out their set (with > some sane defaults if those are absent in API) and add more tunable > resource properties later. > > I also remember that Heat has smth like 'hidden' in resource plugin > declaration. Usually it is used to hide deprecated resource types so that > new stacks with those can not be created but old ones can be at least > deleted. May be you could use that flag while developing until you think > that resource is already usable, although it might complicate your own > testing of those resources. > > Cheers, > > Dr. Pavlo Shchelokovskyy > Senior Software Engineer > Mirantis Inc > www.mirantis.com > > On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés < > norbert.e.il...@ericsson.com> wrote: > >> Hi everyone, >> >> Me and two of my colleagues are working on adding Neutron Trunk support >> to Heat. One of us working on the resource implementation, one on the unit >> tests and one on the functional tests. But all of these looks like a big >> chunk of work so I'm wondering how can we divide them into smaller parts. >> >> One idea is to split them along life cycle methods (create, update, >> delete, etc.), for example: >> * Implement the resource creation + the relevant unit tests + the >> relevant functional tests, review and merge these >> * implementing the delete operation + the relevant unit tests + the >> relevant functional tests, review and merge these >> * move on to implementing the update operation + tests... and so on. >> >> Lastly, when the last part of the code and tests merged, we can document >> the new resource, create templates in the heat-templates etc. >> >> Is this workflow sounds feasible? >> >> I mostly concerned about the fact that there will be a time period when >> only a half-done feature merged into the Heat codebase, and I'm not sure if >> this is acceptable? >> >> Has anybody implemented a new resource with a team? I would love to hear >> some experiences about how others have organized this kind of work. >> >> Cheers, >> Norbert >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Best regards, Peter Razumovsky
__________________________________________________________________________ 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
