Differences

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

--- cloud:intro [2020/01/17 12:04] – kauffman
+++ cloud:intro [2020/05/14 09:27] – chudler
@@ Line 1: / Line 1: @@
 === SCOPE OF THIS DOCUMENT ===
-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.
+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.
-Some things that are not written about here but perhaps should be covered elsewhere
-  * Theory of operations (everything here is by example)
-  * Accomplishing tasks from the Web Interface
-  * Background and History
-  * Alternative Services within CS and without
-  * Organizational Policy, such as who can do what
-  * Deployment Architecture
-  * Systemic Limitations
-  * Good Practices (because they are nascent, at best)
-  * Cloud init, Fog, Terraform, Heat, and other operational tools
-  * Network and Information Security
-  * Backup and Restore
-The list is not comprehensive.
-=== A WORD ABOUT SECURITY ===
-The security of the virtual computers that you launch is __your responsibility__. With this software you are able to create wildly insecure configurations that will be hacked within seconds, with no hope of recovering. This can put all of us at risk. The highest risk that you will encounter is to expose your computers to the Internet. Beware of the dangers associated with doing so!
 === INTRODUCTION AND NOTES ===
-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:
+This cluster can spring into being computer resources without the involvement of other personnel. The software has some exotic capabilities, but this is a common subset:
   * L2 and L3 Network
@@ Line 34: / Line 13: @@
   * Security groups (firewall service)
-Some want
-  * Distributed/Replicated hash tables (K/V store, Object Storage)
-The cloud can also manage resources on your behalf that are traditionally handled by a human operator. This is less common, and amounts to cognitive debt that you may eventually have to pay:
+The cloud can also manage resources on your behalf that are traditionally handled by a human operator:
   * Load balancer
   * NFS
-  * Rancher Kubernetes (among others)
+  * Hadoop
-  * Lots more
+  * Rancher Kubernetes
+  * Container Runtime
+More notes can be found at [[ cloud:naq | Frequently Asked Questions ]]
+=== A WORD ABOUT SECURITY ===
+The security of the virtual computers that you launch is __your responsibility__. With this software you are able to create insecure configurations that will be hacked, with no hope of recovering. This can put all of us at risk. The highest risk that you will encounter is to expose your computers to the Internet. Beware of the dangers associated with doing so!
+======Getting and Using Access======
 == Web Access and Certificates ==
 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)
 === PROJECTS ===
 Openstack requires Users and their cloud resources to belong to a Project. Users have pre-defined Roles within that Project, such as Member or Admin. The Role, Project, and User together constitute in-context access control. So, when a user is in a certain Project, that User can read, modify, destroy the cloud resources in that Project, or even create new resources. All actions depend on the precise Role of the User in the project. Non-members of a project are not able to do anything with cloud resources of the project to which they are a non-member, including View Access. Users can belong to any number of Projects, and with potentially different Roles. Project Admins can modify the memberships of their own Projects. However, there is __not__ a Role known as Owner.
 == Your Default Project ==
@@ Line 309: / Line 292: @@
 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.
-=== NAQ  (Never Asked Questions) ===
-Q: Why does it use a self-signed certificate?
-A: This is a loose end that might be addressed in the future. Let us know if it overburdens you. Note: we are unlikely to acknowledge security concerns associated with this.
-Q: What are all of the services enabled?
-A:
-  * cinder-backup
-  * heat
-  * barbican
-  * mistral
-  * ironic (we *do* support baremetal instances!)
-  * octavia
-  * sahara
-  * manila
-  * ganesha
-  * ceph (that is, ceph as a service. Your instances can be ceph clients in a software-defined manor if you wish, directly accessing RBD)
-  * MDS/RADOS/"Kitchen Sink" (you can have a distributed POSIX via ceph, or an object store, etc).
-  * swift
-  * designate
-  * DVR/HA
-  * Full Blown OVN, as you desire
-  * nova
-  * placement (standalone)
-  * glance
-  * gnocchi (as-a-service. Hundreds of metrics are collected for everything in your project)
-Q: What about containers (docker)?
-A: We do not provide any support for them directly. We expect that you will want to manage this from inside the VMs that you create. We have no plans to deploy Magnum right now.
-Q: My servers are in ERROR state!!!
-A: If the servers had been running previously, this is bad and may not be recoverable. Talk to us ASAP about anything that you know. We'll troubleshoot. The upside is that the servers might be gone but the volumes and anything else associated with them (ports, etc) can be attached to entirely new servers, as is often done in clouds.
-Q: How fast is it?
-A: We haven't done enough measurements, but believe it to be good enough for instructional use (compare with research use). There is some evidence that it can sustain 100MB/s random writes through to the backend
-Q: Is my data safe?
-A: PROBABLY NOT AT THIS STAGE!  The backend is fully redundant and replicated 4x across a cluster of several dozen servers (etc, etc). The problem is that software failures are still happening on the backend and operators want to know why.
-Q: How does the SSH key injection work?
-A: Cloud-init. You won't be able to do this unless you are using a "cloud-ready" operating system
-Q: What operating systems are supported?
-A: We are prepared to run any workload if you are willing to put in requisite work also. We know it to be compatible with all major Unixes and Windows. Building an image is required before an instance can be launched and this is usually done with image building tools (chroot, et al).
-Q: What about limitations?
-A: The following quotas are set on your account and projects, only for the safety of the cloud. We will lift these easily if you need it (values are unspecified here, as yet, sorry):
-  * gigabytes
-  * volumes
-  * secgroups
-  * secgroup-rules
-  * server-groups
-  * ram
-  * instances
-  * fixed-ips
-  * server-group-members
-  * cores
-  * per-volume-gigabytes
-  * backup-gigabytes
-  * snapshots
-  * volumes
-  * backups
-  * subnetpools
-  * ports
-  * subnets
-  * networks
-  * floating-ips
-  * routers
 == URLS ==