Differences

This shows you the differences between two versions of the page.

--- cloud:intro [2019/12/06 14:26] – chudler
+++ cloud:intro [2019/12/13 08:18] – chudler
@@ Line 1: / Line 1: @@
 === SCOPE OF THIS DOCUMENT ===
-This guide will cover a common subset of tasks that a user would need to perform to have a set of clustered computer instances and associated resources, isolated from others, and accessible to a project for any general purpose, both long-term and short. We are catering heavily to short-term usage, perhaps lasting a few quarters.
+This guide covers the common subset of tasks that users would need to perform to have a set of clustered computer instances and associated resources, isolated from others, and accessible to a project for any general purpose, both long-term and short. We are catering heavily to short-term and periodic usage, perhaps lasting no more than a few quarters.
-Some things that are not here but perhaps should be covered elsewhere
+Some things that are not written about here but perhaps should be covered elsewhere
-  * Theory of operations (everything is by example)
+  * Theory of operations (everything here is by example)
-  * Tasks accomplished from the Web Interface
+  * Accomplishing tasks from the Web Interface
   * Background and History
-  * Organizational Policy, such as who can do what.
+  * Alternative Services within CS and without
+  * Organizational Policy, such as who can do what
   * Deployment Architecture
-  * Limitations
+  * Systemic Limitations
-  * User management, Group management, and similar concepts
   * Good Practices (because they are nascent, at best)
   * Cloud init, Fog, Terraform, Heat, and other operational tools
-  * Security
+  * Network and Information Security
   * Backup and Restore
@@ Line 26: / Line 26: @@
 === INTRODUCTION AND NOTES ===
-This cluster can spring into being computer resources, easily, and without any involvement of other personnel. The software has some exotic capabilities, but almost everyone will use this common subset:
+This cluster can spring into being computer resources, easily, and without the involvement of other personnel. The software has some exotic capabilities, but almost everyone will use a common subset:
   * L2 and L3 Network
   * Router (SNAT and DNAT devices, etc)
   * Compute, and all that it entails such as RAM, CPU, Disk, ...
-  * Block Storage (volume mounts)
+  * Additional Block Storage (volume mounts)
   * Security groups (firewall service)
@@ Line 42: / Line 42: @@
   * NFS
   * Rancher Kubernetes (among others)
+  * Lots more
 == Web Access and Certificates ==
-The cloud is named **Overcloud**. The web interface at [[https://overcloud.cs.uchicago.edu]] uses a non-public certificate authority. You will have to accept it for all purposes: API, HTTPS, and CLI clients.
+The cloud is named **Overcloud**. The web interface uses a non-public certificate authority and can be reached at [[https://overcloud.cs.uchicago.edu]]. You will have to accept the certificate for all purposes: API, HTTPS, and CLI clients.
 NOTE: Our cloud DNS service might not meet your needs. Please test it anyway if you know how (TODO: document)
@@ Line 166: / Line 167: @@
 After creating your own network and subnet(s), a router is also needed. However, a router is **not** needed if your instances only talk to each other. The router will take the gateway of your subnet automatically, and allow clients to access the internet via outbound NAT. Much more is possible, and a router is a prerequisite for the next step, which is inbound NAT (DNAT).
 <code>openstack router create --enable myrouter
-openstack router add subnet mysubnet</code>
+openstack router add subnet myrouter mysubnet</code>
 With the router created and attached to your subnet, develop it further. First, you need to obtain a free IP address on the UC Campus. We call this network __campus37__.
 <code>openstack floating ip create campus37</code>
-The output of the command is shown below. Take not of the IP Address:
+The output of the command is shown below. Take note of the IP Address:
 <code>
 +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
@@ Line 242: / Line 243: @@
 You could also use the web interface to access the console, but that's not quite the same.
 As before, in the Network Gear section, get a campus IP address from our pool.
-<code>$ openstack floating ip create</code>
+<code>openstack floating ip create
+openstack server add floating ip myserver 128.135.37.XX
+</code>
+Note that the command is showing you a deeper and more rare UX pattern than before:
+<code>
+openstack server $action $subresource $more_options
+</code>
 At last, you can ssh into 128.135.37.XX. It is important for you to realize that your __local__ server IP does not change (no new interface is given to the instance). Instead, the router on the subnet simply performs DNAT on behalf of the clients. Here's another possibility:
 <code>$ openstack server add network myserver campus37</code>
-**Now** your server does have a new interface attached to it, and will be served a DHCP address there. You will almost certainly have to inform the OS about this, and the cloud tools won't help you with that...
+**Now** your server does have a **new** network interface attached to it, and will be served a DHCP address on it. You will almost certainly have to inform the OS about this manually; the cloud may not help you do that.
+This section added a floating ip address directly to the server. You must realize that a router was needed on the subnet for that to happen. We had created the router earlier for the purpose of SNAT, and had we not done that, this command would have failed. This means that if you are not doing SNAT, you should create a router anyway, but __do not__ give it a campus address of its own.
 == A WORD ABOUT CLOUD INIT ==
-Your author uses cloud init extensively and does not imagine a life without it. It is optional. The file used in these examples is attached to this email, but you should develop your own if you use it at all.
+Your author uses cloud init extensively and does not imagine a life without it. It is optional. The file used in these examples is available on request, but you should develop your own if you use it at all.
-== FAQ, NAQ  (Never Asked Questions) ==
+=== NAQ  (Never Asked Questions) ===
 Q: Why does it use a self-signed certificate?