Re: [openstack-dev] [Heat] How to model resources in Heat
On Jan 31, 2014, at 1:30 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Zane Bitter's message of 2014-01-30 19:30:40 -0800:
On 30/01/14 16:54, Clint Byrum wrote:
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [ build_server,
fixed_ip ]}, /image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Well, consider that when this build is complete you'll still have the
server you used to build the image still sitting around. Of course you
can delete the stack to remove it - and along with it will go the image
in Glance. Still seem useful?
No, not as such. However I have also discussed with other users having
an OS::Heat::TemporaryServer which is deleted after a wait condition is
signaled (resurrected on each update). This would be useful for hosting
workflow code as the workflow doesn't actually need to be running all
the time. It would also be useful for heat resources that want to run
code that needs to be contained into their own VM/network such as the
port probe thing that came up a few weeks ago.
Good idea? I don't know. But it is the next logical step my brain keeps
jumping to for things like this.
(I'm conveniently ignoring the fact that you could have set
DeletionPolicy: Retain on the image to hack your way around this.)
What you're looking for is a workflow service (I think it's called
Mistral this week?). A workflow service would be awesome, and Heat is
pretty awesome, but Heat is not a workflow service.
Totally agree. I think workflow and orchestration have an unusual
relationship though, because orchestration has its own workflow that
users will sometimes need to defer to. This is why we use wait
conditions, right?
So yeah, Glance images in Heat might be kinda useful, but at best as a
temporary hack to fill in a gap because the Right Place to implement it
doesn't exist yet. That's why I feel ambivalent about it.
I think you've nudged me away from optimistic at least closer to
ambivalent as well.
We (RH tripleo folks) were having a similar conversation around Heat and stack
upgrades the other day. There is unquestionably a workflow involving stack
updates when a user goes to upgrade their overcloud, and it's awkward trying to
shoehorn it into Heat (Steve Dake agreed). Our first thought was Tuskar should
do that, but our second thought was Whatever the workflow service is should
do that, and Tuskar should maybe provide a shorthand API for it.
I feel like we (tripleo) need to take a harder look at getting a working
workflow thing available for our needs, soon...
--Hugh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
Hi,
There is a stackforge project Mistral which is aimed to provide generic
workflow service. I believe Zane mentioned it in his previous e-mail.
Currently, this project is at a pilot stage. Mistral has working pilot with
all core components implemented and right now we are finalizing DSL syntax
for task definitions. Mistral can call any API endpoint which is defined in
a task and Mistral exposes hooks to trig workflow execution on some
external event.
There will be a meetup where Renat Akhmerov (Mistral lead) will present
Mistral, its use cases and current status of the project followed by a
demo. Here is a link: http://www.meetup.com/openstack/events/163020092/
We plan to finish Mistral core development during Icehouse release and
apply for an incubation. I think in J release Mistral can be used by other
OpenStack projects as all bits an pieces will be available at this time.
Thanks
Georgy
On Fri, Jan 31, 2014 at 4:53 AM, Hugh Brock hbr...@redhat.com wrote:
On Jan 31, 2014, at 1:30 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Zane Bitter's message of 2014-01-30 19:30:40 -0800:
On 30/01/14 16:54, Clint Byrum wrote:
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [
build_server, fixed_ip ]}, /image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Well, consider that when this build is complete you'll still have the
server you used to build the image still sitting around. Of course you
can delete the stack to remove it - and along with it will go the image
in Glance. Still seem useful?
No, not as such. However I have also discussed with other users having
an OS::Heat::TemporaryServer which is deleted after a wait condition is
signaled (resurrected on each update). This would be useful for hosting
workflow code as the workflow doesn't actually need to be running all
the time. It would also be useful for heat resources that want to run
code that needs to be contained into their own VM/network such as the
port probe thing that came up a few weeks ago.
Good idea? I don't know. But it is the next logical step my brain keeps
jumping to for things like this.
(I'm conveniently ignoring the fact that you could have set
DeletionPolicy: Retain on the image to hack your way around this.)
What you're looking for is a workflow service (I think it's called
Mistral this week?). A workflow service would be awesome, and Heat is
pretty awesome, but Heat is not a workflow service.
Totally agree. I think workflow and orchestration have an unusual
relationship though, because orchestration has its own workflow that
users will sometimes need to defer to. This is why we use wait
conditions, right?
So yeah, Glance images in Heat might be kinda useful, but at best as a
temporary hack to fill in a gap because the Right Place to implement it
doesn't exist yet. That's why I feel ambivalent about it.
I think you've nudged me away from optimistic at least closer to
ambivalent as well.
We (RH tripleo folks) were having a similar conversation around Heat and
stack upgrades the other day. There is unquestionably a workflow involving
stack updates when a user goes to upgrade their overcloud, and it's awkward
trying to shoehorn it into Heat (Steve Dake agreed). Our first thought was
Tuskar should do that, but our second thought was Whatever the workflow
service is should do that, and Tuskar should maybe provide a shorthand API
for it.
I feel like we (tripleo) need to take a harder look at getting a working
workflow thing available for our needs, soon...
--Hugh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
Re: [openstack-dev] [Heat] How to model resources in Heat
Excerpts from Hugh Brock's message of 2014-01-31 04:53:11 -0800:
On Jan 31, 2014, at 1:30 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Zane Bitter's message of 2014-01-30 19:30:40 -0800:
On 30/01/14 16:54, Clint Byrum wrote:
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [ build_server,
fixed_ip ]}, /image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Well, consider that when this build is complete you'll still have the
server you used to build the image still sitting around. Of course you
can delete the stack to remove it - and along with it will go the image
in Glance. Still seem useful?
No, not as such. However I have also discussed with other users having
an OS::Heat::TemporaryServer which is deleted after a wait condition is
signaled (resurrected on each update). This would be useful for hosting
workflow code as the workflow doesn't actually need to be running all
the time. It would also be useful for heat resources that want to run
code that needs to be contained into their own VM/network such as the
port probe thing that came up a few weeks ago.
Good idea? I don't know. But it is the next logical step my brain keeps
jumping to for things like this.
(I'm conveniently ignoring the fact that you could have set
DeletionPolicy: Retain on the image to hack your way around this.)
What you're looking for is a workflow service (I think it's called
Mistral this week?). A workflow service would be awesome, and Heat is
pretty awesome, but Heat is not a workflow service.
Totally agree. I think workflow and orchestration have an unusual
relationship though, because orchestration has its own workflow that
users will sometimes need to defer to. This is why we use wait
conditions, right?
So yeah, Glance images in Heat might be kinda useful, but at best as a
temporary hack to fill in a gap because the Right Place to implement it
doesn't exist yet. That's why I feel ambivalent about it.
I think you've nudged me away from optimistic at least closer to
ambivalent as well.
We (RH tripleo folks) were having a similar conversation around Heat and
stack upgrades the other day. There is unquestionably a workflow involving
stack updates when a user goes to upgrade their overcloud, and it's awkward
trying to shoehorn it into Heat (Steve Dake agreed). Our first thought was
Tuskar should do that, but our second thought was Whatever the workflow
service is should do that, and Tuskar should maybe provide a shorthand API
for it.
I feel like we (tripleo) need to take a harder look at getting a working
workflow thing available for our needs, soon...
I agree that is a thought that enters my mind as well.
However, I don't know if we're so much shoe-horning the upgrade workflow
into Heat as we are making sure Heat's internal workflow is useful so
that users don't have to write their own workflow to make the expressed
stack a reality.
I'll be starting work on rolling updates for Heat soon. That will provide
users with a way to express that they'd like parallelizable updates to
a certain group to be controlled by a certain waitcondition state. That
feels like workflow because we know the implementation is definitely a
workflow. However, to the user it is just declaring the rules, they're
not actually deciding how to do it.
I would hope that having generic workflows inside heat would free users
from drudgery, and they can write workflows when the flow is sufficiently
complex.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
Zane Thanks for putting this together. This will guide us as we develop some resources in Heat. As chmouel said it would be great if this can be converted to blog article. thanks prasadv On Wed, Jan 29, 2014 at 11:09 PM, Chmouel Boudjnah chmo...@enovance.comwrote: Zane Bitter zbit...@redhat.com writes: As I said, figuring this all out is really hard to do, and the existing resources in Heat are by no means perfect (we even had a session at the Design Summit devoted to fixing some of them[1]). If anyone has a question about a specific model, feel free to ping me or add me to the review and I will do my best to help. Thanks for writing this up Zane, I have been often confused with the modeling system of Heat, it may be worthwhile to store this in documentation or a blog article. Cheers, Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
On Wed, Jan 29, 2014 at 5:03 PM, Zane Bitter zbit...@redhat.com wrote: On 29/01/14 19:40, Jay Pipes wrote: On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote: I've noticed a few code reviews for new Heat resource types - particularly Neutron resource types - where folks are struggling to find the appropriate way to model the underlying API in Heat. This is a really hard problem, and is often non-obvious even to Heat experts, so here are a few tips that might help. Resources are nouns, they model Things. Ideally Things that have UUIDs. The main reason to have a resource is so you can reference its UUID (or some attribute) and pass it to another resource or to the user via an output. If two resources _have_ to be used together, they're really only one resource. Don't split them up - especially if the one whose UUID other resources depend on is the first to be created but not the only one actually required by the resource depending on it. Right. The above is precisely why I raised concerns about the image import/upload tasks work ongoing in Glance. https://wiki.openstack.org/wiki/Glance-tasks-import# Initial_Import_Request At least the dependencies there would be in the right order: ImportTask - Image - Server but if you were to model this in Heat, there should just be an Image resource that does the importing internally. (I'm not touching the question of whether Heat should have a Glance Image resource at all, which I'm deeply ambivalent about.) Maybe I'm just missing the use case, but it seems like modeling anything Glance-y in Heat doesn't quite make sense. If at all, the dependency would run the other way (model heat-things in glance, just as we presently model nova-things in glance). So I think we're in agreement. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
On Thu, Jan 30, 2014 at 1:54 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Mark Washenberger's message of 2014-01-30 12:41:40 -0800:
On Wed, Jan 29, 2014 at 5:03 PM, Zane Bitter zbit...@redhat.com wrote:
(I'm not touching the question of whether Heat should have a Glance
Image
resource at all, which I'm deeply ambivalent about.)
Maybe I'm just missing the use case, but it seems like modeling anything
Glance-y in Heat doesn't quite make sense. If at all, the dependency
would
run the other way (model heat-things in glance, just as we presently
model
nova-things in glance). So I think we're in agreement.
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [ build_server,
fixed_ip ]}, /image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Perhaps I am confused. It would be good to resolve that.
I think this proposal makes sense but is distinct from modeling the image
directly. Would it be fair to say that above you are modeling an
image-build process, and the image id/url is an output of that process?
Maybe the distinction I'm making is too fine. The difference is that once
an Image exists, you can pretty much just *download* it, you can't really
do dynamic stuff to it like you can with a nova server instance.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
On 30/01/14 16:54, Clint Byrum wrote:
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [ build_server, fixed_ip ]},
/image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Well, consider that when this build is complete you'll still have the
server you used to build the image still sitting around. Of course you
can delete the stack to remove it - and along with it will go the image
in Glance. Still seem useful?
(I'm conveniently ignoring the fact that you could have set
DeletionPolicy: Retain on the image to hack your way around this.)
What you're looking for is a workflow service (I think it's called
Mistral this week?). A workflow service would be awesome, and Heat is
pretty awesome, but Heat is not a workflow service.
So yeah, Glance images in Heat might be kinda useful, but at best as a
temporary hack to fill in a gap because the Right Place to implement it
doesn't exist yet. That's why I feel ambivalent about it.
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
Excerpts from Zane Bitter's message of 2014-01-30 19:30:40 -0800:
On 30/01/14 16:54, Clint Byrum wrote:
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [ build_server,
fixed_ip ]}, /image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Well, consider that when this build is complete you'll still have the
server you used to build the image still sitting around. Of course you
can delete the stack to remove it - and along with it will go the image
in Glance. Still seem useful?
No, not as such. However I have also discussed with other users having
an OS::Heat::TemporaryServer which is deleted after a wait condition is
signaled (resurrected on each update). This would be useful for hosting
workflow code as the workflow doesn't actually need to be running all
the time. It would also be useful for heat resources that want to run
code that needs to be contained into their own VM/network such as the
port probe thing that came up a few weeks ago.
Good idea? I don't know. But it is the next logical step my brain keeps
jumping to for things like this.
(I'm conveniently ignoring the fact that you could have set
DeletionPolicy: Retain on the image to hack your way around this.)
What you're looking for is a workflow service (I think it's called
Mistral this week?). A workflow service would be awesome, and Heat is
pretty awesome, but Heat is not a workflow service.
Totally agree. I think workflow and orchestration have an unusual
relationship though, because orchestration has its own workflow that
users will sometimes need to defer to. This is why we use wait
conditions, right?
So yeah, Glance images in Heat might be kinda useful, but at best as a
temporary hack to fill in a gap because the Right Place to implement it
doesn't exist yet. That's why I feel ambivalent about it.
I think you've nudged me away from optimistic at least closer to
ambivalent as well.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] How to model resources in Heat
I've noticed a few code reviews for new Heat resource types - particularly Neutron resource types - where folks are struggling to find the appropriate way to model the underlying API in Heat. This is a really hard problem, and is often non-obvious even to Heat experts, so here are a few tips that might help. Resources are nouns, they model Things. Ideally Things that have UUIDs. The main reason to have a resource is so you can reference its UUID (or some attribute) and pass it to another resource or to the user via an output. If two resources _have_ to be used together, they're really only one resource. Don't split them up - especially if the one whose UUID other resources depend on is the first to be created but not the only one actually required by the resource depending on it. Resources are *not* verbs - you don't need or want a separate resource type for every API call, only the ones that create a Thing with a UUID. The foundational principle of orchestration is that it builds workflows based on explicit relationships defined in templates. This is the core of Heat, and so long as it remains relatively simple it works in extremely powerful ways. It is also brittle, in that if the resource model does not fit it breaks in a myriad of subtle ways. If you find yourself having to hack the workflow in some way not defined in the template - by changing the update order, messing around with implicit dependencies, c. - you are probably Doing It Wrong and the problem is in the resource modelling. Some APIs are just particularly hard to model, and in those cases if you are a member in good standing of the project in question, you should push back and try to get those APIs fixed. It isn't any easier for users than it is for us; the only difference is that Heat has a formal model to expose the brokenness. As I said, figuring this all out is really hard to do, and the existing resources in Heat are by no means perfect (we even had a session at the Design Summit devoted to fixing some of them[1]). If anyone has a question about a specific model, feel free to ping me or add me to the review and I will do my best to help. cheers, Zane. [1] https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote: I've noticed a few code reviews for new Heat resource types - particularly Neutron resource types - where folks are struggling to find the appropriate way to model the underlying API in Heat. This is a really hard problem, and is often non-obvious even to Heat experts, so here are a few tips that might help. Resources are nouns, they model Things. Ideally Things that have UUIDs. The main reason to have a resource is so you can reference its UUID (or some attribute) and pass it to another resource or to the user via an output. If two resources _have_ to be used together, they're really only one resource. Don't split them up - especially if the one whose UUID other resources depend on is the first to be created but not the only one actually required by the resource depending on it. Right. The above is precisely why I raised concerns about the image import/upload tasks work ongoing in Glance. https://wiki.openstack.org/wiki/Glance-tasks-import#Initial_Import_Request Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
On Wed, 2014-01-29 at 20:03 -0500, Zane Bitter wrote: On 29/01/14 19:40, Jay Pipes wrote: On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote: I've noticed a few code reviews for new Heat resource types - particularly Neutron resource types - where folks are struggling to find the appropriate way to model the underlying API in Heat. This is a really hard problem, and is often non-obvious even to Heat experts, so here are a few tips that might help. Resources are nouns, they model Things. Ideally Things that have UUIDs. The main reason to have a resource is so you can reference its UUID (or some attribute) and pass it to another resource or to the user via an output. If two resources _have_ to be used together, they're really only one resource. Don't split them up - especially if the one whose UUID other resources depend on is the first to be created but not the only one actually required by the resource depending on it. Right. The above is precisely why I raised concerns about the image import/upload tasks work ongoing in Glance. https://wiki.openstack.org/wiki/Glance-tasks-import#Initial_Import_Request At least the dependencies there would be in the right order: ImportTask - Image - Server but if you were to model this in Heat, there should just be an Image resource that does the importing internally. (I'm not touching the question of whether Heat should have a Glance Image resource at all, which I'm deeply ambivalent about.) I'm not touching on that at all, either. I'm just pointing out that the task resource object currently being worked on in the Glance API is not really a resource at all -- the resource is an Image. Whether or not the Image resource changes state during certain events (like image upload or translation) does not mean that state change should be represented as a resource in the API. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
Zane Bitter zbit...@redhat.com writes: As I said, figuring this all out is really hard to do, and the existing resources in Heat are by no means perfect (we even had a session at the Design Summit devoted to fixing some of them[1]). If anyone has a question about a specific model, feel free to ping me or add me to the review and I will do my best to help. Thanks for writing this up Zane, I have been often confused with the modeling system of Heat, it may be worthwhile to store this in documentation or a blog article. Cheers, Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
