Open Stack

Hi Anne

I agree that our users are more likely using puppet or ansible, but from other projects I have received feedback to not include non-OpenStack projects in my samples.  Yes cloud-init is not really OpenStack either, but it is packaged into all of the “cloud images” that people utilize.  That’s the reason for my selecting cloud-init.  If others feel that including puppet or ansible  would be acceptable, the I could certainly add that as an example later.

Craig Sterrett

From: Anne Gentle [mailto:annegentle at justwriteclick.com]
Sent: Tuesday, August 30, 2016 4:36 PM
To: Sterrett, Craig <craig.sterrett at intel.com>
Cc: Lana Brindley <openstack at lanabrindley.com>; openstack-docs at lists.openstack.org
Subject: Re: [OpenStack-docs] Need help with FirstApp Doc for heat



On Tue, Aug 30, 2016 at 5:59 PM, Sterrett, Craig <craig.sterrett at intel.com<mailto:craig.sterrett at intel.com>> wrote:
The orchestration chapter is very basic, really just covering how to create a stack once you download a template, and does not cover the details of the template.  What I am proposing is, to duplicate the entire FirstApp using heat, reproducing what is being done by the SDK function calls using heat.

Okay, but if the FirstApp guide is meant for SDKs, and heat/orchestration/ceilometer/autoscaling is for deployment, let's talk about a new chapter or a different guide.

Beyond user-data, consider the use of ansible, or puppet, or chef. To me this sounds more scalable to the types of info and deployment scenarios our users are interested in. What do you think?


The getting started chapter will show you how to  create a heat template that launches an instance defining the image, flavor, key, security group and network, and then pass in the commands to install the Fractals application into user_data, and lastly associate a floating IP, with each section of the template explained.  The end result will be the fractal application running and accessible by the floating IP
The introduction will add in creating security groups, and splitting the application services across two instances.

Scaling out in that SDK guide is here:
http://developer.openstack.org/firstapp-libcloud/scaling_out.html

To me, this is a bit of a square peg in a round hole.

Scaling out discusses how to further split out the fractal app into 3 groups of services, and how to use heat ResourceGroup to kick off multiple instances for each of the services.  It also shows how you can pass IP addresses of created instances back and use str_replace to modify configuration files for the Fractal app as needed when you split up the app into 3 separate pieces.
Block storage adds in how to create cinder block storage using heat and how to prepare the disk and mount the disk, and install the MySQL db on it.
I was going to change the Orchestration to Autoscaling, and add in how to setup ceilometer to monitor and automatically scale the different components up and down, adding in how to use metadata to define groups of instances the ceilometer alarms are looking at, allowing for multiple scaling groups.
Networking covers how to create 3 separate networks for the 3 different groups of services in the Fractal app , with routers and load balancers and floating IP’s.


All this sounds great, but for simplicity's sake and for accelerating the writing and reviewing, I'd suggest a new chapter on deployment, and in any chapters that have a heat approach, a pointer to that new chapter. Or, write a "deploying apps" chapter in the user-guide in openstack-manuals. That definitely provides less complexity since it uses no conditional text. There are more reviewers there too. Unless you actually prefer fewer reviews, I could argue either way. :)

Also consider there's an effort going on for a content sprint with the working title of "Moving apps to OpenStack" and an outline here: https://docs.google.com/document/d/1mR-M2ufn0lviyGughNdm0zFz9O6AlYFUSr3JKqoaiv4/edit That's happening next month, in September. See the thread at http://lists.openstack.org/pipermail/user-committee/2016-August/001203.html

I'm only connecting the dots here, not trying to sway you one way or another. My sense is that you have a good idea of what to write, and trying to fit in the FirstApp conditional text boxes will be slower than "just write it in an existing non-conditional guide."

Anne

Craig Sterrett

From: Anne Gentle [mailto:annegentle at justwriteclick.com<mailto:annegentle at justwriteclick.com>]
Sent: Tuesday, August 30, 2016 2:14 PM
To: Lana Brindley <openstack at lanabrindley.com<mailto:openstack at lanabrindley.com>>
Cc: openstack-docs at lists.openstack.org<mailto:openstack-docs at lists.openstack.org>
Subject: Re: [OpenStack-docs] Need help with FirstApp Doc for heat



On Tue, Aug 30, 2016 at 3:53 PM, Lana Brindley <openstack at lanabrindley.com<mailto:openstack at lanabrindley.com>> wrote:
Hi Craig,

FirstApp docs aren't part of the openstack-manuals project. I think Tom (cc'd) can probably help you out with contribution information.

It is: https://github.com/openstack/governance/blob/master/reference/projects.yaml#L430

I'd like to hear ideas for where this exact content belongs really -- it's the firstapp, deployed with Orchestration (heat), right? Seems like this content could be in its own chapter, ignoring any conditionals, or making the entire chapter conditional for its own output.

Say more about the outline you're proposing, and when/where/why this chapter http://developer.openstack.org/firstapp-libcloud/orchestration.html is opposite of your thinking for inserting heat templates in the guide?

Anne



Thanks,
Lana

On 31/08/16 01:19, Sterrett, Craig wrote:
> Hello
>
> I have been asked to create a FirstApp for heat.  It looks like the FirstApp documents get generated with lots of static text, and modifying the code blocks for the different SDKs.  My problem is that I would like to modify a lot of the static text, since it is fairly specific to SDKs and not really accurate for heat.  I would also like to rename a section, changing the Orchestration section to Autoscaling since all of my document is Orchestration.
>
> Any suggestions about the best way to go about this?
>
> Thanks, Craig Sterrett
>
>
> _______________________________________________
> OpenStack-docs mailing list
> OpenStack-docs at lists.openstack.org<mailto:OpenStack-docs at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
--
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com


_______________________________________________
OpenStack-docs mailing list
OpenStack-docs at lists.openstack.org<mailto:OpenStack-docs at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



--
Anne Gentle
www.justwriteclick.com<http://www.justwriteclick.com>



--
Anne Gentle
www.justwriteclick.com<http://www.justwriteclick.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20160902/3c106aa9/attachment-0001.html>