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
.

2017-04-11 17:27 GMT+04:00 Pavlo Shchelokovskyy
>:

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
>
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://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



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

2017-04-12 Thread Peter Razumovsky
>
> 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

.

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


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

2017-04-11 Thread Pavlo Shchelokovskyy
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  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://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