Re: [openstack-dev] [heat] New resource implementation workflow
> > 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
[openstack-dev] [openstack-infra][fuel-ccp-designate] Repository empty core-group
Hi openstack-infra! I recently added new repo named fuel-ccp-designate [1], but we can't merge any patch due to no one consists in fuel-ccp-designate core-group. Can you add me to core-group, and then I'll add other cores to it. Thanks! [1] https://github.com/openstack/fuel-ccp-designate -- 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
[openstack-dev] [Heat] Current status of observe reality feature implementation (Convergence Phase 2)
Hi all! I'd like to provide current status of observe reality implementation. I remember, that community wished to land before N release time as much observe reality patches as possible. Next resource plugins have observe reality feature patches on review and should be reviewed *as soon as possible*: *Nova resources:* Nova::Server - https://review.openstack.org/#/c/244066/ *Cinder resources:* Cinder::VolumeType - https://review.openstack.org/#/c/250451/ Cinder::Volume - https://review.openstack.org/261445 Cinder::EncryptedVolumeType - https://review.openstack.org/276730 *Aodh resources:* Aodh::GnocchiAggregationByResourcesAlarm - https://review.openstack.org/#/c/314540/ Aodh::GnocchiAggregationByMetricsAlarm - https://review.openstack.org/314517 Aodh::GnocchiResourcesAlarm - https://review.openstack.org/#/c/314488/ Aodh::CombinationAlarm - https://review.openstack.org/#/c/313513/ Aodh::Alarm - https://review.openstack.org/#/c/313499/ Next resource plugins have observe reality feature patches on review and should be reviewed *when it would be convenient*: *Neutron resources:* Neutron::Net - https://review.openstack.org/255287 Neutron::Subnet - https://review.openstack.org/255753 Neutron::Router - https://review.openstack.org/255776 Neutron::FloatingIP - https://review.openstack.org/256264 Neutron::Port - https://review.openstack.org/259074 vpnservice.py resources - https://review.openstack.org/266910 firewall.py resources - https://review.openstack.org/271992 Neutron::ProviderNet - https://review.openstack.org/273055 *Sahara resources:* sahara/templates resources - https://review.openstack.org/274073 Sahara::ImageRegistry - https://review.openstack.org/274648 Sahara::DataSource - https://review.openstack.org/274654 Sahara::JobBinary - https://review.openstack.org/274658 *Manila resources:* Manila::SecurityService - https://review.openstack.org/275344 Manila::ShareType - https://review.openstack.org/275363 Manila::ShareNetwork - https://review.openstack.org/275363 Manila::Share - https://review.openstack.org/276151 Next resource plugins will be available after testing and rebasing: *Keystone resources: * https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/get-reality-for-resources+message:%22Keystone::%22 --- 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][yaql] Heat map replacement options
Try this:
yaql:
expression:let(root => $) ->
dict($root.data.service.items().select([$[0], $root.data.ip[$[1]]]))
data:
service: { get_param: ServiceNetMap }
ip: { get_param: NetIpMap}
2016-07-15 12:25 GMT+03:00 Steven Hardy :
> Hi all,
>
> I'm trying to figure out the cleanest way to do a replacement of values in
> a mapping (json parameter) in a heat template, e.g:
>
> ServiceNetMap:
> type: json
> default:
> IronicApiNetwork: internal_api
> CephPublicNetwork: storage
>
> NetIpMap:
> type: json
> default:
> storage: 192.0.2.2
> internal_api: 192.0.2.5
>
> How do I get
> OutputMap:
> IronicApiNetwork: 192.0.2.5
> CephPublicNetwork: 192.0.2.2
>
> It seems like something yaql should be able to do, but I've so far failed
> to figure out the syntax.
>
> The other (possibly simpler) possibility is to implement a new hot
> function, e.g something like:
>
> map_replace:
> template: {get_param: ServiceNetMap}
> value_replacements: {get_param: NetIpMap}
>
> The function could accept e.t value_replacements and key_replacements, and
> simply iterate over the map doing a key lookup and replacement on the
> key/value when they match.
>
> Anyone got any simpler ideas, or an example of what this would look like in
> yaql?
>
> Thanks!
>
> Steve
>
> __
> 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] Nomination Oleksii Chuprykov to Heat core reviewer
Of course +1. 2016-03-16 14:12 GMT+03:00 Steven Hardy : > On Wed, Mar 16, 2016 at 01:57:34PM +0300, Sergey Kraynev wrote: > > Hi Heaters, > > > > The Mitaka release is close to finish, so it's good time for reviewing > > results of work. > > One of this results is analyze contribution results for the last release > cycle. > > According to the data [1] we have one good candidate for nomination to > > core-review team: > > Oleksii Chuprykov. > > During this release he showed significant value of review metric. > > His review were valuable and useful. Also He has enough level of > > expertise in Heat code. > > So I think he is worthy to join to core-reviewers team. > > > > I ask you to vote and decide his destiny. > > +1 - if you agree with his candidature > > -1 - if you disagree with his candidature > > +1 > > __ > 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
[openstack-dev] [Heat] Current state of get_live_state implementation
Hi all! I decided to post current state of convergence sensitive patches - get_live_state method implementation - which resources is ready for review. At first, if you need, you can learn about this feature from https://review.openstack.org/#/c/232368/ There's some refactoring of base get_live_state implementation, which resolves few unresolved moments from original base implementation, and it's available here: https://review.openstack.org/#/c/264861/ Currently get_live_state method is ready for review for Cinder, Barbican and Glance resource plugins and available here: * OS::Cinder::VolumeType: https://review.openstack.org/#/c/250451/ * OS::Cinder::EncryptedVolumeType: https://review.openstack.org/#/c/250666/ * OS::Cinder::Volume: https://review.openstack.org/#/c/261445/ * OS::Barbican::Order: https://review.openstack.org/#/c/252976/ * OS::Barbican::Secret: https://review.openstack.org/#/c/254226/ * OS::Glance::Image: https://review.openstack.org/#/c/250705/ Will be good to review all this patches and give some response. Thank you. -- 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] Rico Lin for heat-core
+1 2015-12-07 15:39 GMT+03:00 Sergey Kraynev : > Hi all. > > I'd like to nominate Rico Lin for heat-core. He did awesome job with > providing useful and valuable reviews. Also his contribution is really high > [1] . > > [1] http://stackalytics.com/report/contribution/heat-group/60 > > Heat core-team, please vote with: > +1 - if you agree > -1 - if you disagree > > -- > Regards, > Sergey. > > __ > 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] get_reality implementation: default values, specified in config files
Hm... It's sounds reasonable, I will think about it. 2015-12-03 15:37 GMT+03:00 Thomas Herve : > > > On Thu, Dec 3, 2015 at 1:00 PM, Peter Razumovsky > wrote: > >> >> Hello! >> >> During get_reality implementation next problem raised: if I don't specify >> optional not update allowed property (like availabiliy_zone in >> OS::Cinder::Volume), default value will be set for this property in entity. >> This default value defined in configuration of entity's project (i.e. if I >> create OS::Cinder::Volume without az, volume will be created with az = >> default value, which defined in cinder.conf). >> >> So, if I want to get live state of entity, I get az with value, but in >> template no value has been specified for az, and that's mean, stack will be >> repalced during update, which is awful (e.g. if we have huge stack with >> this problem for each resource, updating will be very slow). >> >> What I can do with such properties with default values, defined in config >> options? I don't know any methods to get value from config of other project. >> > > I haven't thought too much about it, but I'm sure getting config from > other projects is not the right idea :). One possible solution would be to > get the live state of the entity just after creation, so that we can fill > those default properties right away. What do you think? > > -- > Thomas > > > __ > 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
[openstack-dev] [Heat] get_reality implementation: default values, specified in config files
Hello! During get_reality implementation next problem raised: if I don't specify optional not update allowed property (like availabiliy_zone in OS::Cinder::Volume), default value will be set for this property in entity. This default value defined in configuration of entity's project (i.e. if I create OS::Cinder::Volume without az, volume will be created with az = default value, which defined in cinder.conf). So, if I want to get live state of entity, I get az with value, but in template no value has been specified for az, and that's mean, stack will be repalced during update, which is awful (e.g. if we have huge stack with this problem for each resource, updating will be very slow). What I can do with such properties with default values, defined in config options? I don't know any methods to get value from config of other project. -- 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] Show attribute is a collection of other attributes or not?
I want to implement this task
3 июля 2015 г. 15:00 пользователь "Sergey Kraynev"
написал:
> Thank everyone for the good feedback.
> If summarize all suggestions:
> - I will continue add show as raw output (similar on clients show command
> output)
> - Also we decided to implement additional functional for "get_attr"
> function, when it get only resource name and returns map with all
> attributes (except "show").
>
> About second one need volunteer :)
>
> Regards,
> Sergey.
>
> On 3 July 2015 at 00:04, Steven Hardy wrote:
>
>> On Fri, Jul 03, 2015 at 07:35:18AM +1200, Steve Baker wrote:
>> > On 03/07/15 06:03, Randall Burt wrote:
>> > >Maybe use "all" for all attributes in the schema and use "show" for
>> the raw output from the service (as is done today for server and neutron
>> stuff).
>> > Instead of "all", how about allowing a special form of {get_attr:
>> > [resource_name]} with no extra arguments to return a dict of all
>> attributes?
>> > This would be consistent with how extra arguments traverse attribute
>> data.
>>
>> +1
>>
>> __
>> 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
>
>
__
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][Mistral] How to use Mistral resources in Heat
Hi Renat, We solved problem with referencing. I'll add more tests for understanding, how Mistral Workflow resource look like in Heat template. 2015-03-03 14:35 GMT+03:00 Renat Akhmerov : > Hi Peter, > > Thanks for sharing this.. Overall it looks good to me, I just left a > couple of comments/questions in > https://review.openstack.org/#/c/147645/17/contrib/heat_mistral/heat_mistral/tests/test_workflow.py > Could > you please take a look? > > We keep in mind that one thing is still not implemented: workflow > references get broken if we upload a workflow which calls another workflow. > We need to discuss the best way to deal with that. Either we need to do in > Heat itself to restore those references accounting for stack name etc.. Or > we need to provide some facility in Mistral itself. > > Other than that it looks to be ready to start gathering Heat folks’ > feedback. > > Renat Akhmerov > @ Mirantis Inc. > > > > On 26 Feb 2015, at 17:49, Peter Razumovsky > wrote: > > In anticipation of Mistral supporting in Heat, let's introduce using > Mistral in Heat. > 1. For using Mistral resources workflow and cron-trigger in Heat, Mistral > must be installed to DevStack. Installation guide for DevStack on > https://github.com/stackforge/mistral/tree/master/contrib/devstack Detailed > information about Workflow and CronTrigger you can find on > https://wiki.openstack.org/wiki/Mistral Note, that currently Mistral use > DSLv2 (https://wiki.openstack.org/wiki/Mistral/DSLv2) and Rest API v2 ( > https://wiki.openstack.org/wiki/Mistral/RestAPIv2). > 2. When Mistral will be installed, check it accessibility - in screen or > using command 'mistral --help' (list of commands). You can test Mistral > resources creating workflow resources with DSLv2-formatted definitions, > cron-triggers and executions. > For example, command 'mistral workflow-list' gives the table: > Starting new HTTP connection (1): 192.168.122.104 > Starting new HTTP connection (1): localhost > > +-++--+-++ > | Name| Tags | Input| Created > at | Updated at | > > +-++--+-++ > | std.create_instance | | name, image_id, flavor_id... | 2015-01-27 > 14:16:21 | None | > | std.delete_instance | | instance_id | 2015-01-27 > 14:16:21 | None | > > +-++--+-++ > > 3. Mistral resources for Heat you can find there: > > https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/mistral-resources-for-heat,n,z > 4. Simple templates using Mistral resources in Heat templates you can find > there: > https://wiki.openstack.org/wiki/Heat_Mistral_resources_usage_examples > __ > 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 > > __ 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][Mistral] How to use Mistral resources in Heat
In anticipation of Mistral supporting in Heat, let's introduce using Mistral in Heat. 1. For using Mistral resources workflow and cron-trigger in Heat, Mistral must be installed to DevStack. Installation guide for DevStack on https://github.com/stackforge/mistral/tree/master/contrib/devstack Detailed information about Workflow and CronTrigger you can find on https://wiki.openstack.org/wiki/Mistral Note, that currently Mistral use DSLv2 (https://wiki.openstack.org/wiki/Mistral/DSLv2) and Rest API v2 ( https://wiki.openstack.org/wiki/Mistral/RestAPIv2). 2. When Mistral will be installed, check it accessibility - in screen or using command 'mistral --help' (list of commands). You can test Mistral resources creating workflow resources with DSLv2-formatted definitions, cron-triggers and executions. For example, command 'mistral workflow-list' gives the table: Starting new HTTP connection (1): 192.168.122.104 Starting new HTTP connection (1): localhost +-++--+-++ | Name| Tags | Input| Created at | Updated at | +-++--+-++ | std.create_instance | | name, image_id, flavor_id... | 2015-01-27 14:16:21 | None | | std.delete_instance | | instance_id | 2015-01-27 14:16:21 | None | +-++--+-++ 3. Mistral resources for Heat you can find there: https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/mistral-resources-for-heat,n,z 4. Simple templates using Mistral resources in Heat templates you can find there: https://wiki.openstack.org/wiki/Heat_Mistral_resources_usage_examples __ 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
