Five days + twelve authors + one book sprint = one great book on OpenStack architecture
Author: Nick Chase
A distinctive feature of OpenStack is that you can find a lot of information on how to perform specific actions, for example, launch an instance or install a test cloud on VirtualBox. However, there is not much information that gives you a general idea, for example, on how to design a massively scalable cloud based on OpenStack or a cloud optimized for providing streaming content.
How OpenStack book sprint went
(Photo taken from: openstack.org .)
So last week, twelve OpenStack experts and technical writers from companies specializing in various areas of the OpenStack ecosystem gathered on VMware’s Palo Alto campus to participate in a book sprint to develop the OpenStack Architecture Design Guide. The goal of the event was to get a ready-made book on designing OpenStack clouds in just five days.
In comparison, I wrote my first book — a fairly simple introduction to Active Server Pages 3.0 — for seven weeks, then there were months of editing before the book went to print. Writing a more significant book never took me less than six months. Therefore, when I volunteered to participate in the sprint, I confess that I did not expect much from him. Of course, I knew that at the end of the week we would have a book. I just did not expect the result to be a really cool guide.
The process of writing the book itself was very regulated, but this did not limit us, since we had a feeling that we had decided on the direction. We started by discussing the target audience — architects who design OpenStack systems or specialists who evaluate them for future use. Then we applied the brainstorming method to determine the possible structure.
Having decided that we mainly need to cover the groups of options for using OpenStack-based clouds, we collectively discussed all the different types that you can cover by writing them on stickers and combining them into groups on a marker board (we just say that the phrase “continuous integration / continuous deployment "(CI / CD) and" development / testing "(dev / test) were on the minds of many of us). It soon became clear that we have seven main categories of clouds, including “designed for computing” and “massively scalable”.
Then we split into two groups, each of which was supposed to collectively discuss the structure of the categories obtained in half an hour. It is interesting that, despite the use of different terminology, the structure to which both groups came as a result was almost the same (that is, we avoided the struggle not for life but for death, which is always nice).
After that, our group of 12 people was divided into 3 groups of 4 participants, each of which took up writing one section. At the end of Monday, we had already written 15 thousand words (10 thousand of which, of which we are still convinced, were written by Beth Cohen).
I was stunned.
What struck me was not how much material we received, but the fact that the material actually turned out to be quite good.
By Wednesday morning the book was almost ready, it was necessary to edit it. The groups read sections written by others, trying to fill in any spaces, and Beth and I began to edit the text to bring it to a single style. Then two more steps followed: technical editing by Alexandra Settle, Scott Lowe and Sean Winn, and checking the text for factual errors.
Long before Friday we had a book that we can be proud of.
The OpenStack Architecture Design Guide is intended for architects and evaluators. Since the deployment process is described in the OpenStack Operations Guide, we have not included it in our book. The Design Guide describes the following types of clouds based on OpenStack:
• general purpose;
• intended for calculations;
• intended for data storage;
• designed for building networks;
• multisite;
• hybrid;
• massively scalable;
• special cases (clouds that do not fall into the above categories, for example, having multiple hypervisors).
We touched on various issues, such as user requirements, technical issues and issues related to the operation of each type of cloud, then we discussed the architecture itself and gave a number of specific examples that will simplify the understanding of the material.
Probably the most interesting thing in the book sprint is that it is largely a reflection of the OpenStack initiative in miniature. We all work in different companies, some of which are not in very good relations with each other, but in that room it did not matter. We were just people who did the job and did it as well as we could, working overtime, joking about our "evil overlords" (sprint organizers Adam Hyde and Faith Bosworth) and laughing at everything so as not to go crazy.
We witnessed how Alex found out that American moonshine is very different from what they drink in Australia, and its transformation from a timid novice to a confident writer and editor (but I’ll put two spaces anyway after the point, I'm sorry). Anthony Veiga and Sean Collins never ceased to amaze us with their knowledge of networking principles. Sebastian Gutierrez showed how passionate he is about data storage, especially the wonders of the Ceph system. Vinny Valedez created more cool charts in two days than I did in the whole of last year. Maish Saidel-Keesing and Kevin Jackson have constantly inspired us to become better with their hard work and sense of humor. I still laugh at Steve Gordon's cool humor. And I apologize to everyone who still has music from Doctor Who in their heads.
Our goal was to provide a resource to the OpenStack community that would help implement the tool that we are all passionate about. Did we joke about this? Of course yes. But ultimately, we would not be there if we did not believe in the future of OpenStack and in what we can do with OpenStack if we do it right.
The OpenStack Architecture Design Guide will be freely available electronically as part of the OpenStack documentation, and, as with the previously published Operation Guide and Security Guide, everyone will be able to propose their own edits that will be made to it as a living document, which will only get better and better. It will also be available in paper form through Lulu. Follow the news here or subscribe toOpenStack: Now to be notified as soon as the paper version is available.
Original article in English .
A distinctive feature of OpenStack is that you can find a lot of information on how to perform specific actions, for example, launch an instance or install a test cloud on VirtualBox. However, there is not much information that gives you a general idea, for example, on how to design a massively scalable cloud based on OpenStack or a cloud optimized for providing streaming content.
How OpenStack book sprint went
(Photo taken from: openstack.org .)
So last week, twelve OpenStack experts and technical writers from companies specializing in various areas of the OpenStack ecosystem gathered on VMware’s Palo Alto campus to participate in a book sprint to develop the OpenStack Architecture Design Guide. The goal of the event was to get a ready-made book on designing OpenStack clouds in just five days.
In comparison, I wrote my first book — a fairly simple introduction to Active Server Pages 3.0 — for seven weeks, then there were months of editing before the book went to print. Writing a more significant book never took me less than six months. Therefore, when I volunteered to participate in the sprint, I confess that I did not expect much from him. Of course, I knew that at the end of the week we would have a book. I just did not expect the result to be a really cool guide.
How does a book sprint go
The process of writing the book itself was very regulated, but this did not limit us, since we had a feeling that we had decided on the direction. We started by discussing the target audience — architects who design OpenStack systems or specialists who evaluate them for future use. Then we applied the brainstorming method to determine the possible structure.
Having decided that we mainly need to cover the groups of options for using OpenStack-based clouds, we collectively discussed all the different types that you can cover by writing them on stickers and combining them into groups on a marker board (we just say that the phrase “continuous integration / continuous deployment "(CI / CD) and" development / testing "(dev / test) were on the minds of many of us). It soon became clear that we have seven main categories of clouds, including “designed for computing” and “massively scalable”.
Then we split into two groups, each of which was supposed to collectively discuss the structure of the categories obtained in half an hour. It is interesting that, despite the use of different terminology, the structure to which both groups came as a result was almost the same (that is, we avoided the struggle not for life but for death, which is always nice).
After that, our group of 12 people was divided into 3 groups of 4 participants, each of which took up writing one section. At the end of Monday, we had already written 15 thousand words (10 thousand of which, of which we are still convinced, were written by Beth Cohen).
I was stunned.
What struck me was not how much material we received, but the fact that the material actually turned out to be quite good.
By Wednesday morning the book was almost ready, it was necessary to edit it. The groups read sections written by others, trying to fill in any spaces, and Beth and I began to edit the text to bring it to a single style. Then two more steps followed: technical editing by Alexandra Settle, Scott Lowe and Sean Winn, and checking the text for factual errors.
Long before Friday we had a book that we can be proud of.
What the OpenStack Architecture Design Guide covers
The OpenStack Architecture Design Guide is intended for architects and evaluators. Since the deployment process is described in the OpenStack Operations Guide, we have not included it in our book. The Design Guide describes the following types of clouds based on OpenStack:
• general purpose;
• intended for calculations;
• intended for data storage;
• designed for building networks;
• multisite;
• hybrid;
• massively scalable;
• special cases (clouds that do not fall into the above categories, for example, having multiple hypervisors).
We touched on various issues, such as user requirements, technical issues and issues related to the operation of each type of cloud, then we discussed the architecture itself and gave a number of specific examples that will simplify the understanding of the material.
What the community really means
Probably the most interesting thing in the book sprint is that it is largely a reflection of the OpenStack initiative in miniature. We all work in different companies, some of which are not in very good relations with each other, but in that room it did not matter. We were just people who did the job and did it as well as we could, working overtime, joking about our "evil overlords" (sprint organizers Adam Hyde and Faith Bosworth) and laughing at everything so as not to go crazy.
We witnessed how Alex found out that American moonshine is very different from what they drink in Australia, and its transformation from a timid novice to a confident writer and editor (but I’ll put two spaces anyway after the point, I'm sorry). Anthony Veiga and Sean Collins never ceased to amaze us with their knowledge of networking principles. Sebastian Gutierrez showed how passionate he is about data storage, especially the wonders of the Ceph system. Vinny Valedez created more cool charts in two days than I did in the whole of last year. Maish Saidel-Keesing and Kevin Jackson have constantly inspired us to become better with their hard work and sense of humor. I still laugh at Steve Gordon's cool humor. And I apologize to everyone who still has music from Doctor Who in their heads.
Our goal was to provide a resource to the OpenStack community that would help implement the tool that we are all passionate about. Did we joke about this? Of course yes. But ultimately, we would not be there if we did not believe in the future of OpenStack and in what we can do with OpenStack if we do it right.
The OpenStack Architecture Design Guide will be freely available electronically as part of the OpenStack documentation, and, as with the previously published Operation Guide and Security Guide, everyone will be able to propose their own edits that will be made to it as a living document, which will only get better and better. It will also be available in paper form through Lulu. Follow the news here or subscribe toOpenStack: Now to be notified as soon as the paper version is available.
Original article in English .