HostUnification » History » Revision 4
Revision 3 (Justin Sherrill, 04/29/2015 10:15 PM) → Revision 4/25 (Justin Sherrill, 05/04/2015 10:26 AM)
h1. Host Unification h2. Main Goals * Unify "Content Hosts" and Hosts so that they are one object based on a 'Host'. The content and subscription portions simply become attributes/concerns/aspects of a Host object. * h2. Design h4. Ideal Design We have presented two designs, one design based somewhat on this discussion: https://groups.google.com/forum/#!searchin/foreman-dev/shim/foreman-dev/9ByQmAtKokQ/W2V924xqtYUJ !http://projects.theforeman.org/attachments/download/1239/aspect.png! !http://projects.theforeman.org/attachments/download/1231/aspect.png! The goal is to open a pull request with this design implemented for the Puppet related portion and if feedback is positive to proceed with the Content and Subscription portions. h4. Fallback design: If this does not go favourably, we present this alternative design which is very similar but simpler in nature: !http://projects.theforeman.org/attachments/download/1229/simple.png! h2. Api/Cli changes At a minimum, no api/cli changes would be needed and all functionality could remain with the proposed designs using existing controllers and cli commands. However given that the current katello systems controller is 'deprecated', we greatly need to plan for a supported api. Based on the discussions here: https://groups.google.com/forum/#!topic/foreman-dev/4Y4qxyknMwI The apis for interacting with the different aspects: <pre> GET /api/v2/hosts?search="content_attr=foo" GET /api/v2/hosts/:id/content/ GET /api/v2/hosts/:id/subscription/ </pre> to update a host's content: <pre> PUT /api/v2/hosts/3/ {'content_view_id': 5} OR PUT /api/v2/hosts/3/content {'content_view_id': 5} </pre> Sample hammer commands <pre> hammer host content details --id=3 hammer host content update --content-view=myView hammer host content errata apply --host-id=3 --errata-ids=RHSA-2014:3 </pre> h2. User Stories (P1): (1 man sprint = 20 points) * As a user, I should be able to create a host without a puppet environment (1) * As a developer, I want to split out all puppet conerns to their own 'aspect' (10) * As a user, i expect host create/update/delete to be dynflowed (wrapping the AR action), via foreman_tasks or in core to allow plugins to hook into CUD to interact with backend services (4) * As a developer, i want to migrate the existing content host model to the new unified models for content and subscriptions (10) * As a developer, I want to migrate all the existing content host dynflow actions to use the new unified model (4) * As a user, i want an upgrade provided to move existing content-hosts to the new unified models (4) * As a developer, I want to pull system packages into the database (3) * As a user, I should be able to search hosts by content attributes (2) * As a user, I should be able to search hosts by subscription attributes (2) * As a user, I expect subscription facts to live alongside puppet facts. (4) * As a user, I should be able to add & remove hosts to host collections instead of content-hosts (4) * As a user, bulk actions should be based off hosts instead of content hosts (2) * As a user, I should be able to register a host with subscription-manager via username and password with the new data model, and a Host should be created (2) * As a user, I should be able to register a host with subscription-manager via activation key with the new data model, and a Host should be created (2) * As a user, I should be able to register with subscription-manager to an existing host that has never registered with sub-man before (2) * As a user, I should be able to register with subscription-manager to an existing host that has previously registered with subscription-manager, and have the old registration be removed, generating a new UUID (2) * As a user, virt-who should continue to work with the new unified model, including hypervisor registration. An hypervisor registered through virt-who would have content capabilities. (5) * As a user, i expect package profile uploading to continue to work under the unified model (1) * As a user, i expect client actions (errata install, package install, etc..) to continue to work under the unified model (3) * As a user, i expect the subscription and content aspects of hosts to be identified by their host id, not a uuid (3) * As a user, i expect to be able to find the uuid of a host with subscriptions within the UI/hammer (1) * As a user, i expect to be able to search hosts by applicable errata (.5) * As a user, i expect to be able to search hosts by installed package (.5) * As a user, i expect to be able to search hosts by subscription facts (.5) * As a user, i expect existing apis (and thus hammer commands and the UI) to continue to work under the new model, if new apis are not added (8) H2. User Stories (P2) * As a user, i expect an api for interacting with content and subscription aspects of hosts (6) * As a developer, the content hosts UI needs to utilize new apis for interacting with the subscription and content aspects of a host (8) * As a developer, I want to pull in subscriptions and related hosts into the database (6) * As a user, I expect to search for hosts by their subscriptions (.5) * As a user, i expect the following hammer commands to be migrated: > * hammer content-host errata apply -> hammer host content errata apply (.5) > * hammer content-host errata info -> hammer host content errata info (.5) > * hammer content-host errata list -> hammer host content errata list (.5) > * hammer content-host package install -> hammer host content package install (.5) > * hammer content-host package remove -> hammer host content package remove (.5) > * hammer content-host package upgrade -> hammer host content package upgrade (.5) > * hammer content-host package upgrade-all -> hammer host content package upgrade-all (.5) > * hammer content-host package-group install -> hammer host content package-group install (.5) > * hammer content-host package-group remove -> hammer host content package-group remove (.5) > * hammer content-host update -> hammer host content update (for updating content view, lifecycle environment) (.5) > * hammer content-host update -> hammer host subscription update (for updating service-level, release-version) (.5) > * hammer host puppet-classes (.5) > * hammer host puppetrun (.5)