Dredging up this thread because I was reminded of it today by a question
on ask.openstack.org.
On 18/07/14 09:19, Ayenson, Michael D. wrote:
Hello All,
My name is Mika Ayenson and I have to privilege to intern at Johns Hopkins - Applied
Physics Lab. I'm really excited to release the latest proof of concept
"Re-Heat" Re-Heat is a JHUAPL developed tool for OpenStack users to help them
quickly rebuild their OpenStack environments via OpenStack's Heat .
Here is a link to the Re-Heat paper:
https://drive.google.com/open?id=0BzTq-ZB9F-b9b0ZXdy1PT2t3dk0&authuser=0
Here is a link to Re-Heat: https://github.com/Mikaayenson/ReHeat
I have included the abstract to our paper here:
This makes me sad. Not because it isn't great work - I'm sure it is. It
makes me sad because when I read statements like:
In the context of “entire lifecycle” management, Heat is the “create” aspect of
OpenStack orchestration.
I realise that we have completely failed to communicate what Heat is :(
To be clear, in the context of "entire lifecycle" management, Heat is
the "entire lifecycle" aspect of OpenStack orchestration.
I know I, and I suspect many of us, always hoped that this would be
exactly the kind of application where Heat could make a difference,
helping scientists to make their research more repeatable.
Heat does that by allowing you to represent your infrastructure as code,
and store it under version control. Messing with it behind Heat's back
instead of by modifying the template is the infrastructure equivalent of
connecting a debugger and messing with the machine code at runtime
instead of changing the source. It's the opposite of repeatable. And
developing tools to make using this broken pattern more convenient is a
step in the wrong direction IMHO.
I strongly recommend you try using the stack update mechanism instead.
It's not perfect, but it's getting better all the time. We welcome any
feedback you have.
To be clear, I do think there is a really good use of this kind of
technology, and it's the one that the Flame developers are targeting:
bringing existing applications under Heat's management.
cheers,
Zane.
Abstract
OpenStack has experienced tremendous growth since its initial release just over
four years ago. Many of the enhancements, such as the Horizon interface and Heat,
facilitate making complex network environment deployments in the cloud from scratch
easier. The Johns Hopkins University Applied Physics Lab (JHU/APL) has been using
the OpenStack environment to conduct research, host proofs-of-concepts, and perform
testing & experimentation. Our experience reveals that during the environment
development lifecycle users and network architects are constantly changing the
environments (stacks) they originally deployed. Once development has reached a
point at which experimentation and testing is prudent, scientific methodology
requires recursive testing be conducted to determine the repetitiveness of the
phenomena observed. This requires the same entry point (an identical environment)
into the testing cycle. Thus, it was necessary to capture all the changes made to
the initial !
environmen
t during the development phase and modify the original Heat template. However, OpenStack
has not had a tool to help automate this process. In response, JHU/APL developed a
poof-of-concept automation tool called "Re-Heat," which this paper describes in
detail.
I hope you all enjoy this as I have truly enjoyed playing with HEAT and
developing Re-Heat.
Cheers,
Mika Ayenson
_______________________________________________
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
