| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
See comment on the method "restr_get" for more info.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cloudmasterd
Changes include:
* everest-bootstrap's default mode is now "cloud".
- It is assumed that all systems provisioned by everest-bootstrap will be sent to a cloudmaster
for provisioning. However, a cloudmaster does not necessarily have to control several minions
to qualify. A cloudmaster can be configured to simply control its own disk space.
- The "advanced" mode also expects that systems are getting provisioned in a cloud, and requires
a "cloudmaster" parameter.
- The previous "--config-only" command line parameter has been changed to a mode. Now a user can
select between "standard", "advanced", and "config-only" modes.
- Hooks for cobbler dns have been added. A great deal more work needs to be done here before it
is ready, though.
- everest-bootstrap can now ask everestd if it knows the IP address and hostname of newly provisioned
machines
* everestd can now examine the /var/log/cobbler/install.log file to determine the IP address and hostname
of new systems.
- I suspect that this functionality will get moved from everestd to the cloudmaster. Users of
everest-bootstrap will be directed to the cloud's status page to access the systems' IP addy and
hostnames.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* everest-dsl
* everest-bootstrap
Remaining problems:
* everest-sync still missing a spec file
* everest-repo cannog build RPM without a local copy of "docs" git repo
|
| | |
|
| |
|
|
| |
Spec file / version cleanup
|
| | |
|
| | |
|
| |
|
|
| |
Supplying the email address to the cloudmasterd
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
virtual machines within the cloud.
Updated everest-bootstrap to call the cloud controller when provisioning machines
Removed "koan" operations from everestd. Now everestd only knows how to register machines with everest and cobbler. Basically a rollback to its previous version.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
------------------------------------------------------
The "cloud" mode acts like the "wizard" in the standard mode of everest-bootstrap in that it asks relevant questions for provisioning a new machine.
After collecting the standard information, it registers the new system with cobbler and with everestd. It then asks everestd to koan the new machine.
Adding support to everestd to call func to koan a requested machine on the most suitable everest host
-----------------------------------------------------------------------------------------------------
Now everestd asks "cloud-inventory" which host/vol_group combination is the best fit for a particular machine. Then, everestd will delegate to
func to koan the new machine on the host/vol_group combination.
|
| | |
|
| | |
|
| |
|
|
| |
Hopefully this will make the output a little easier to read
|
| |
|
|
|
| |
This allows you to pass in a yaml description for a node type via stdin or with
the --yaml option. See 'everest-bootstrap advanced -h' for more info.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These changes are to support a oneliner provisioning story in the Everest
environment.
New features:
* We use facts instead of parameters. The can be create prior to koaning a
machine. They can also be managed centrally in a more efficient manner.
* uses the cobbler xmlrpc api to allow users to select which OS that would like
to use for their machine type.
* it's now possible to optionally use Red Hat's DDNS
* added a '--config-only' option. This does not need to be run as root in that
case. This is useful if you simpy want to update a machine's parameters. This
will also be useful when it comes time to port machines over to the use of
parameters. The machines already exist therefore they don't need to be koaned.
TODO:
everest-bootstrap will kick of koan but after it finishes the machine will not
start back up. We can either do some trickery to make the tool smart enough to
know when it finishes or we can try and find a way for Xen to reboot the
machine automatically.
|
| |
|
|
| |
This is precisely why I need to unit::test this stuff
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The major goal of this patchset is to consolidate all machine types and their
corresponding facts logic in one place. As more machine types were getting
created it became unrealistic to have all facts on all machine types. There
were also quite a few complexities involved in the ordering of regexes and such
which made the whole process very error prone. There is now a config file
dropped in /etc/everest by puppet that houses all the logic. The external
nodes script, the nodetypes cgi, and everest-bootstrap all use that file as the
canonical source of information.
Another goal of this patchset is to have all the various responsibilities of
everest-bootstrap at the same level of abstraction. The way we were using the
'main' gem was a little out of hand. In one block you had configuration,
bootstrap logic and two different DSLs. That was a little absurd. This will
allow us to test the tool alot more. I even committed a vew trivial unit tests
for the DDNS stuff.
Instead of adding more and more complex command line options I'm taking the
'wizard' approach. This should help to educate people and over time we can
make this a little more non-interactive.
Tickets fixed:
Making the regex used for scraping the DDNS hash a little more strict
https://engineering.redhat.com/trac/IT_Architecture/ticket/71
Added some tests
Removing CGI call from everest-bootstrap
https://engineering.redhat.com/trac/IT_Architecture/ticket/40
Host bootstrapping will now prompt the user to finish
https://engineering.redhat.com/trac/IT_Architecture/ticket/45
everest-bootstrap will now forcefully unmout when cleaning up
https://engineering.redhat.com/trac/IT_Architecture/ticket/39
everest-bootstrap now requires '--repo'
https://engineering.redhat.com/trac/IT_Architecture/ticket/77
Improving everest-bootstrap DDNS error message
https://engineering.redhat.com/trac/IT_Architecture/ticket/65
|
| |
|
