[PATCH] Remove the woefully out-of-date and misleading README.

[Chris Lalancette]

All documentation should now be in the docs directory anyway.

Signed-off-by: Chris Lalancette <clalance(a)redhat.com&gt;
---
 README |  150 ----------------------------------------------------------------
 1 files changed, 0 insertions(+), 150 deletions(-)
 delete mode 100644 README

diff --git a/README b/README
deleted file mode 100644
index 698fce4..0000000
--- a/README
+++ /dev/null
@@ -1,150 +0,0 @@
-Deltacloud Portal provides a web UI in front of the Deltacloud API. With Deltacloud
Portal, your users can:
-
-  * View image status and stats across clouds, all in one place
-  * Migrate instances from one cloud to another
-  * Manage images locally and provision them on any cloud
-
-
-=== Preface ===
-
-There are three ways you can install the portal application (though all require the
framework to be set up as well):
-  1. Install the RPM, found here: http://deltacloud.org/download.html (Note that since
this is not in a yum repo yet, you will have to install whatever dependencies this fails
on)
-  2. Build the RPM from source (this will also get you a local yum repo, so you get all
dependencies for 'free')
-  3. Run as a development build from the directory of your choice, using rails scripts
-
-
-=== Section 1 - Prerequisites ===
-
-1. A working install of Fedora 11 (or any other platform that supports at least Ruby on
Rails 2.3.2)
-2. Set up the framework application, as we need that for the portal to talk to:
-   A. Create some directory to hold all the deltacloud projects
-   B. 'git clone' the following (this process will be simplified soon):
-     * git://git.fedorahosted.org/git/deltacloud/framework.git/
-     * git://git.fedorahosted.org/git/deltacloud/driver-mock.git/
-     * git://git.fedorahosted.org/git/deltacloud/client-ruby.git/
-     * (the following two are optional)
-     * git://git.fedorahosted.org/git/deltacloud/driver-ec2.git/
-     * git://git.fedorahosted.org/git/deltacloud/driver-rhevm.git/
-   C. Follow the directions in the framework README to set it up. We recommend using the
mock driver to start with for simplicity, which has a un/pw in
client-ruby/credentials.yml
-
-
-=== Section 2 - Installing the RPM ===
-
-  NOTE: until we get an RPM of authlogic built, you must install this manually
-        with 'sudo gem install authlogic'. This will eventually be an RPM
dependency
-	for deltacloud-portal.
-
-  1. Get the RPM from http://deltacloud.org/download.html
-  2. install with rpm -ivh <rpm>
-  3. You will need the following, though you may wish to just get the list from trying to
install the RPM above, and try again:
-    * httpd >= 2.0
-    * postgresql-server  
-    * pwgen  
-    * ruby >= 1.8.1
-    * ruby-flexmock  
-    * ruby-postgres  
-    * rubygem(activeldap) >= 0.10.0
-    * rubygem(activerecord) >= 2.1.1-2
-    * rubygem(gettext_rails)  
-    * rubygem(thin) >= 1.2.5
-    * rubygem(rails) >= 2.3.2
-  4. Continue to Section 5 - Database setup
-
-
-=== Section 3 - Building the RPM ===
-
-  NOTE: until we get an RPM of authlogic built, you must install this manually
-        with 'sudo gem install authlogic'. This will eventually be an RPM
dependency
-	for deltacloud-portal.
-
-(# denotes root below)
-
-1. First, get a fully updated F11 installed.
-
-2. Set up passwordless sudo:
-
-# visudo
-
-And add the following line:
-
-<your_username>   ALL=(ALL)       NOPASSWD: ALL
-
-Save and quit visudo.
-
-3. Set up a minimal rpmmacros file.
-
-echo "%_topdir      %(echo \$HOME)/rpmbuild" > ~/.rpmmacros
-
-4. From root of wherever you checked out the project:
-
-./autogen.sh; make publish
-
-5. Create /etc/yum.repos.d/deltacloud-local.repo, change the baseurl to your local
deltacloud-cache/deltacloud directory, which you created above.
-
-[deltacloud-local]
-name=Deltacloud-local
-baseurl=file:///home/deltacloud-user/deltacloud-cache/deltacloud
-enabled=1
-metadata_expire=1
-gpgcheck=0
-
-6. # yum install deltacloud-portal
-
-7. Continue to Section 5 - Database setup 
-
-
-=== Section 4 - Development setup ===
-
-If you will be developing, you need to get the source code from our git repository:
-  git clone git://git.fedorahosted.org/git/deltacloud/portal.git/
-
-The Deltacloud Portal depends on deltacloud-client-ruby.  This has a gemspec available,
but currently the easiest way to include it in the app is to check it out into
vendor/plugins in the portal app like this:
-  [user@plugins]$ git clone git://git.fedorahosted.org/git/deltacloud/client-ruby.git/
-
-This will allow the portal to load it up as a plugin with no additional configuration
needed.
-
-Next, you need to have the correct rubygems installed. If you followed the steps in
'Section 3 - Building the RPM', you can safely skip this step, as the dependencies
should all be installed already. Assuming you have ruby and rails installed, you can get a
basic app running pretty simply.  If you try to start the application, you should get a
warning from rails telling you which gems are missing.  At this point, you can either
install the missing gems with yum (most should be available in RPM format for fedora
users), or gem install <gemname> (you may wish to do that as root, depending on your
system configuration).
-
-
-=== Section 5 - Database setup ===
-
-  1. Assuming you have installed postgres and the ruby-postgres package, you now need to
configure your postgres database.  This entails running initdb and starting postgres (for
Fedora users, this would be:
-     * sudo /sbin/service postgresql initdb
-     * sudo /sbin/service postgresql start
-  2. Next, switch to the postgres user (on Fedora - sudo su - postgres):
-     * $ psql
-     * $ CREATE USER dcloud WITH PASSWORD 'v23zj59an' CREATEDB;
-     * $ \q
-     * $ exit
-  3. On a local system you may need to edit pg_hba.conf to have only the following:
-     *(/var/lib/pgsql/data/pg_hba.conf)
-     *   local all all trust
-     *   host all all 127.0.0.1 255.255.255.255 trust
-  4. From wherever you have the portal app, in the src dir, run the following commands to
set up the tables:
-     * rake db:create:all
-     * rake db:migrate (if you want production rather than the default of
'development', simply export RAILS_ENV=production before running this command)
-     * rake db:test:prepare
-
-
-=== Section 6 - Finishing Setup ===
-
-You should now have everyting configured and installed to run the portal.  If you
followed either of the RPM instructions, you can now run:
-  * service deltacloud-aggregator start
-
-If you followed the development steps:
-  * cd to your src directory and run ruby script/server
-
-Lastly, you will need one or more instances of the Deltacloud framework running for the
portal to talk to.  Directions for this can be found in the framework documentation(which
can be found here: git://git.fedorahosted.org/git/deltacloud/framework.git/).  Assuming
everything is installed for that, start a framework up in the framework directory with
'ruby script/server -p 3001' (so it is on a different port than our portal app). 
You should now be ready to try out the portal application.
-
-
-=== Getting Started ===
-
-For these steps, we will assume the mock driver is setup and running in a framework on
http://localhost:3001/api, and your portal is running on http://localhost:3000 (this will
just be http://localhost/deltacloud if you are running through apache, and can be started
with 'service deltacloud-aggregator start')
-
-When you navigate to the main page of your app, you will be presented with an 'Add
cloud provider' form.  'Name' can be whatever you like, types currently
suppoerted are mock, ec2, and rhevm.  'URL' is the url pointing to your framework
(http://localhost:3001/api for our example).
-
-Upon successful completion of the form, you will be brought to the main page for that
provider.  Here you would click 'Add a pool'.  This form asks you fro the username
and password for the account on the provider's service that you wish to connect to. 
Then just provide a name for what we will call this 'pool'.  Completion of this
form will attempt to connect to the provider associated with this pool and gather some
information such as a list of instances that this user has access to and can be started.
-
-Completion of this form brings you to the main page for the newly created pool.  Click
'Add a new instance' here.  For some providers (especially ec2), it can sometimes
take a little while to get all the data back, so if you go to the new instance for and see
no images, you may need to wait a short time and then try again.
-
-At this point, you should have a list of available instances for your provider/pool
combination, with available actions for each instance in your list.  Note that in the
current version, this page will need to be refreshed in order to see and changes that may
occur in the 'State' column, which tells you the status of your instance.
-- 
1.7.2.2

[Jason Guiditta]

On Thu, 2010-08-26 at 14:56 -0400, Chris Lalancette wrote:
>  All documentation should now be in the docs directory anyway.
>  
>  Signed-off-by: Chris Lalancette <clalance(a)redhat.com&gt;
>  ---
>   README |  150 ----------------------------------------------------------------
>   1 files changed, 0 insertions(+), 150 deletions(-)
>   delete mode 100644 README
>   
ACK, however this brings up something I have been thinking about, wanted
to see what others thought.

I wonder if removing things like this from the specific repos might not
be the way to go long term.  It seems to me, that as we start to have
more components working together (condor, image factory/warehouse, etc),
it might remain useful for someone to be able to clone one of these
repos and get the relevant docs for them.  The point of moving things
into the dcos repo was to make a central location to build the site
from, but it was just aggregator and api when we did that - now things
are a bit more distributed.

I talked to Jim Meyering, and one of his suggestions was to have our
build script for the site grab whatever files we want to include up
there from other repos, but let those projects be the authority on what
is in there.  So the script could, for example, wget the latest README
for condor for its repo, and wrap that in some navigation, etc.  But if
you clone condor repo directly, you still get the docs you need.

Any strong opinions either way?

-j

[Chris Lalancette]

On 08/26/10 - 05:00:21PM, Jason Guiditta wrote:
>  On Thu, 2010-08-26 at 14:56 -0400, Chris Lalancette wrote:
>  > All documentation should now be in the docs directory anyway.
>  > 
>  > Signed-off-by: Chris Lalancette <clalance(a)redhat.com&gt;
>  > ---
>  >  README |  150 ----------------------------------------------------------------
>  >  1 files changed, 0 insertions(+), 150 deletions(-)
>  >  delete mode 100644 README
>  > 
>  
>  ACK, however this brings up something I have been thinking about, wanted
>  to see what others thought.
>  
>  I wonder if removing things like this from the specific repos might not
>  be the way to go long term.  It seems to me, that as we start to have
>  more components working together (condor, image factory/warehouse, etc),
>  it might remain useful for someone to be able to clone one of these
>  repos and get the relevant docs for them.  The point of moving things
>  into the dcos repo was to make a central location to build the site
>  from, but it was just aggregator and api when we did that - now things
>  are a bit more distributed.
>  
>  I talked to Jim Meyering, and one of his suggestions was to have our
>  build script for the site grab whatever files we want to include up
>  there from other repos, but let those projects be the authority on what
>  is in there.  So the script could, for example, wget the latest README
>  for condor for its repo, and wrap that in some navigation, etc.  But if
>  you clone condor repo directly, you still get the docs you need.
>  
>  Any strong opinions either way? 
Yeah, I totally agree with you here.  It is much nicer to digest the whole
thing piece by piece, rather than having to wade in from the top-level.
However, this file is very misleading, so I thought it best to wipe the slate
clean, and then start over.  That way new people won't be led off into old
code.

Let's remove this file, and then work on a better aggregator README that more
reflects the current state of the world.

-- 
Chris Lalancette