Re: [openstack-dev] [heat] New resource implementation workflow

2017-04-18 Thread Norbert Illés

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
<pshchelokovs...@mirantis.com <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
<norbert.e.il...@ericsson.com <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.openstack.org/cgi-bin/mailman/list

[openstack-dev] [heat] New resource implementation workflow

2017-04-11 Thread Norbert Illés

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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Heat] Adding support to Neutron Trunking feature

2017-01-13 Thread Norbert Illés

Hi everybody,

I'm interested in adding Heat support to a Neutron feature, called VLAN 
aware VMs [1] (also known as Trunk Port or just Trunking) introduced in 
the Newton release.
A Heat Launchpad Blueprint already created [2] by Rabi Mishra, but I'm 
wondering if anybody started/plan to work on this.


If the answer is no, how can I indicate that I'd like to work on this 
Blueprint?


[1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[2]: https://blueprints.launchpad.net/heat/+spec/support-trunk-port

Cheers,
Norbert

__
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