Hi,
Thanks for the advices! The HIDDEN status looks better for me as it
completely hides the resource from the user and it won't be included in
the documentation, but using this to status to mark the implementation
of the resource incomplete feels like a misuse of this status.
So I believe, we should use the UNSUPPORTED attribute in this case
and implement the create and delete operations together + the relevant
test then the update + the relevant test.
Cheers,
Norbert
On 04/12/2017 12:26 PM, Peter Razumovsky wrote:
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
mailto: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 <http://www.mirantis.com>
On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés
mailto: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:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.o
