There are a lot of issues in Crowbar due to the legacy of poor internals. This is blocking things quite a bit when it comes to improving Crowbar for adding new features. Let's fix it!

So far, 39 pull requests opened!

One source of truth for network configuration

This will significantly simplify the code, but also opens the door to changing the IP ranges used for networks.

See the following PRs:

Continue move to role recipes (all merged)

This matters as this will solve a lot of issues caused by inconsistencies related to node state changes, and also because we can simplify things quite a bit.

See the following PRs:

Rework automatic assignment of roles to new nodes (all merged)

This simplifies the code a lot, and also fix problems related to non-allocated nodes getting assigned some roles they don't need (which is causing issues when a barclamp needs to be re-applied, or when the non-allocated nodes get forgotten).

See the following PRs:

Go towards no chef-client on boot

This is one step in the direction of not having chef-client run all the time, and therefore have Crowbar less invasive.

See the following PRs:

Unsubmitted changes:

  • In order to validate that we don't need to reconfigure everything on boot, I deployed a cloud, with most roles disabled for the readying state, I disabled the chef-client service, and I rebooted the nodes. It seems that we're doing a good job at making the config persistent on disk, without a need for chef:
    • all openstack roles are good
    • in crowbar-core, most roles are good. I didn't check dns-client (currently configured to be running for "all" states, sounds wrong), crowbar (only matters for admin server anyway), deployer-client (required for ohai data to be updated), ipmi-discover (might be needed to update the ipmi data on boot), network (this needs some more attention, as there's code to kill NICs not managed by crowbar on boot)
    • MISSING: crowbar-ceph roles, crowbar-ha roles (especially with drbd)
  • Conclusion is that we don't need most of the roles on boot.
  • See https://github.com/vuntz/crowbar-core/commits/no-readying and https://github.com/vuntz/crowbar-openstack/commits/no-readying

Go towards minimum amount of recipes on each chef-client run

We want to have Crowbar less invasive, and part of this is to not have chef reconfigure everything every time.

See the following PRs:

Unsubmitted branches (WIP):

Go towards no periodic chef-client run

We want to have Crowbar less invasive, and part of this is to not have chef reconfigure everything every time.

No code yet, but some thoughts. Currently, periodic chef-client runs are useful for:

  • heartbeat through ohai data (from deployer-client role)
    • we might keep the periodic run just for this; if we do that, we would only run this in "ready" state, and instead add a "converging" state that would allow to run all roles
  • updating config of a service, when another service is changed on another node (for instance: making sure the neutron config is up-to-date on nova-compute nodes)
    • this should be handled through a trigger mechanism when applying a barclamp
  • reconfiguring the repos on the nodes when updating the list of repos in crowbar webui
    • this should be handled through a trigger mechanism
  • updating the config on nodes after editing one node (changing alias, public name, availability zone) -- including dns config on dns-server
    • this should be handled through a trigger mechanism when changing some attributes; however, we need to be clever as changing the public name of a controller is important for nearly all nodes while changing the public name of a compute node doesn't matter

General cleanup of code (all merged)

See the following PRs:

VXLAN with Linuxbridge (all merged)

This is a request we've got several times, so here it is.

See the following PRs:

Various bug fixes (all merged)

See the following PRs:

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 14

Activity

  • over 7 years ago: aspiers liked this project.
  • over 7 years ago: tbechtold liked this project.
  • over 7 years ago: m_meister liked this project.
  • over 7 years ago: evshmarnev liked this project.
  • over 7 years ago: romanarcea liked this project.
  • over 7 years ago: vuntz started this project.
  • over 7 years ago: vuntz originated this project.

  • Comments

    • aspiers
      over 7 years ago by aspiers | Reply

      This is incredible work. Congratulations!

    Similar Projects

    This project is one of its kind!