Open Stack

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.illes at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170411/268bb965/attachment.html>