Re: [openstack-dev] [Heat] Introducing Re-Heat
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-b9b0ZXdy1PT2t3dk0authuser=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
Re: [openstack-dev] [Heat] Introducing Re-Heat
Heat updates work pretty well and this is a right way to track all the changes you do with your infrastructure. Heat declarative templates define state of the OpenStack or any other application in a good, well designed abstract form of resources and their dependencies. If you use Heat updates, the sequence of Heat template diffs gives you the history of changes for free. Heat updates approach is used in multiple projects like TripleO, Murano, Solum and this is a proven way to control resources from a single point of control. We use Heat updates in Murano for almost over the year and we were able to cover almost every application life-cycle aspect with Heat updates. On Thu, Oct 2, 2014 at 2:51 PM, Zane Bitter zbit...@redhat.com wrote: 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-b9b0ZXdy1PT2t3dk0authuser=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 -- 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 OpenStack-dev@lists.openstack.org
[openstack-dev] [Heat] Introducing Re-Heat
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-b9b0ZXdy1PT2t3dk0authuser=0 Here is a link to Re-Heat: https://github.com/Mikaayenson/ReHeat I have included the abstract to our paper here: 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 environment 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
Re: [openstack-dev] [Heat] Introducing Re-Heat
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-b9b0ZXdy1PT2t3dk0authuser=0 Here is a link to Re-Heat: https://github.com/Mikaayenson/ReHeat Hi Mika, It looks very similar to the flame project I've been contributing recently: https://github.com/cloudwatt/flame It's be interesting to see if we can join forces. Cheers, -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Introducing Re-Heat
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-b9b0ZXdy1PT2t3dk0authuser =0 Here is a link to Re-Heat: https://github.com/Mikaayenson/ReHeat Hi Mika, It looks very similar to the flame project I've been contributing recently: https://github.com/cloudwatt/flame It's be interesting to see if we can join forces. Cheers, -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hello Thomas, I have seen flame! I think that it's a great project. I believe you are right. I believe there are ideas in both projects that should be merged. I'm hoping that eventually users will be able to snapshot environments as a stack template. Later even have a template management system so that users may be able to revert their environment back to an original stack template. This will be great for testing purposes. If you take a look at the paper, we briefly mentioned Flame as well! I'm hoping that people will be able to see the use cases and power of tools like these. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
