Feature #3860
closed
Implement fully automated provisioning
Description
Razor does use tags and policies to define rules which assigns OS and hostname. We can add also assigning puppet classes (host groups) and we can do fully automated provisioning too.
-- from 7910 --
In Foreman, we can easily implement automated discovery by creating new model called DiscoveryRule with:
- name: name a the rule
- query: scoped_search expression
- host group: associated host group
- hostname: safemode expression to generate hostname (e.g. "node#{facts[:mac]}.example.com")
- max count: maximum allocation for this rule
- priority: integer giving rule priorities
- enabled: temporary disable a rule
For each discovered node, our plugin would execute query for each rule sorted by given priority. If a rule matches, host group is associated, host created and node rebooted for provisioning. Counter for each rule is increased and if it hits maximum count, query is no longer active. To speed up queries, we will add "and hostname = 'discovered_host_name'" to each query.
In the UI, we will need to create:
- rules CRUD
- re-apply automated provisioning button on the Discovered Hosts
Foreman core integration require to decrease counter when a host is deleted. For fluent user experience, we may want to add new button Delete and Reboot so users are able to return machines back to pool easily.
Updated by Lukas Zapletal over 9 years ago
- Has duplicate Feature #7910: Implement razor-like automated provisioning added
Updated by Bryan Kearney over 9 years ago
Just thinking out loud (scope creep ahead)
1) I assume this would include rules per org and location, so that one org can have different cases to auto-provision
2) It would be nice to have emails/notifications sent out when rules activate
3) I assume full rbac for access to the rules
Updated by Ohad Levy over 9 years ago
Bryan Kearney wrote:
Just thinking out loud (scope creep ahead)
1) I assume this would include rules per org and location, so that one org can have different cases to auto-provision
not sure about this one, as initially discovered hosts land in the 'default org of your liking'.
I could see some sort of an approval process (and maybe an org selection) as a useful thing (e.g. before you turn away your db passwords, allow the new system to access).
Updated by Lukas Zapletal over 9 years ago
Thinking loud:
If we implement this scoped_search rule engine, can we leverage it for the purpose of setting up organization and location for newly discovered (and possibly incoming registered) hosts?
I mean, once we have it, we can easily build another set of screens to do this. Or we can incorporate everything into one set of screens. Think of Zimbra filters - they also allows you to drop mails into folders and set various flags.
Updated by Greg Sutcliffe over 9 years ago
I think we need to solve Disocvery on multiple subnets first (via allowing a PXE Default template per subnet) - I can't see mutliple Locs/Orgs wanting to share the same subnet. It's far more likely that subnet will be isolated - eg Client1 has discovery on 10.1.2.0/24 but Client2 has discovery on 172.20.10.0/24.
Once we have that, we be a lot more flexible with passing kernel options specific to a subnet into the discovery image, for use when registering the host. We can also be a lot smarter about detecting which subnet the host is on, and using it to guess things like the Loc/Org/Subnet/Domain, etc.
I like the use of scoped search rules for the actual automation though, but watch out for the fact that by default all facts are strings, so rules like "memorysize > 4096" for 4Gb servers won't work without some changes.
Updated by Greg Sutcliffe over 9 years ago
- Description updated (diff)
I've copied the description from 7910 since all the discussion is happening here.
Updated by Greg Sutcliffe over 9 years ago
- Has duplicate deleted (Feature #7910: Implement razor-like automated provisioning)
Updated by Greg Sutcliffe over 9 years ago
- Is duplicate of Feature #7910: Implement razor-like automated provisioning added
Updated by Greg Sutcliffe over 9 years ago
- Status changed from Duplicate to Needs design
Duplicate relation reversed too.
Updated by Lukas Zapletal over 9 years ago
- Category set to Discovery plugin
- Assignee set to Lukas Zapletal
Good catch with facts, our long-term goal is to support non-string facts too in future (Facter 2.0 feature). We can just live with this fact for now maybe... A Tech Preview :-)
Updated by The Foreman Bot over 9 years ago
- Status changed from Needs design to Ready For Testing
- Pull request https://github.com/theforeman/foreman_discovery/pull/97 added
- Pull request deleted (
)
Updated by Lukas Zapletal over 9 years ago
- Related to Tracker #8332: [Discovery 2.0] Usability alignment and autoprovisioning added
Updated by Lukas Zapletal over 9 years ago
- Related to Feature #4528: Support Facter 2 structured facts added
Updated by Lukas Zapletal over 9 years ago
For the record, the way we are finalizing auto-provisioning feature is no per org/loc support, except you can set which org/loc all the discovered (thus auto-provisioned) hosts land.
Permissions for rules do not allow per-resource granularity, but it does support RBAC (Discovery Manager can manage rules, Reader can read them).
No e-mails or notifications support in this first cut as well.
But Greg has a working code of per-subnet Default PXELinux template which allows at least some flexibility. First of all, a lock on this template will no longer be necessary. Second, we can easily extend our Discovery Image to accept arbitrary facts via kernel command line, so each organization/location (subnet) can set their own facts to trigger different rules.
This is what we have right now, I am finishing with unit tests this week.
Updated by Anonymous over 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset d3e7c8b925a4da8ad18ddffee67225452915ff3d.