Renaming: hosts to systems and hostgroups to system_groups

Development
1

I submitted a PR to rename hosts to systems and hostgroups to system_groups in the routes and the UI. I plan to update the /api routes as well but wanted to get some feedback first.

https://github.com/theforeman/foreman/pull/1034

The routes changes were easy:

  • resources :hosts do
  • resources :hosts, :path => :systems do
  • resources :hostgroups, :except => [:show] do
  • resources :hostgroups, :path => :system_groups, :except => [:show] do

This leaves all named URL helper paths the same, so the code doesn't need to change. hosts_paths now goes to /systems and hostgroups_path now goes to /system_groups

All works fine but now the legacy paths /hosts and /hostgroups do not exist. Legacy routes are a "nice to have" for the UI but a "must have" for the API. In order to keep the legacy routes there are two options

  1. Add redirect routes
  2. Add legacy routes

Redirect routes as defined as the example below:

get '/hosts', to: redirect('/systems')

This works fine for GET requests, but does not work for POST/PUT/DELETE, so this is not an option for the API.

I choose to use legacy routes with :as => which changes the name path URL helpers to avoid any clashes with the existing routes.
I added a separate file called config/routes/legacy_routes.rb

It contains the resources that were changed in routes.rb using :path =>, and instead I added :as =>

  • resources :hosts, :as => :old_hosts do

This creates the 7 RESTful (legacy) routes for /hosts and /hosts/:id and creates named path URL helpers such as old_hosts_path, edit_old_host_path(host), etc, which are NOT used in the code, so they won't clash with the real helpers hosts_path, edit_host_path(host), etc.

Questions

  1. Do people see this as the right approach to maintain separate separate legacy routes?
  2. Should API v1 be updated with the new route names and maintain legacy routes, or just leave v1 as is without changing the route names?
  3. Should API v2 have new and legacy routes or just new routes with no legacy routes, since it hasn't been released yet and can still have breaking changes?
  4. I also renamed several other paths in the PR for the routs to better match the UI. Should these changes also be included?
    /config_tempates --> /provisioning_templates
    /ptables --> /partion_tables
    /puppetclasses --> /puppet_classes
    /lookup_keys --> /smart_variables
    /common_parameters --> /global_parameters
    /operatingsystems --> /operating_systems
    /media --> /installation_media
    /models --> /hardware_models
    /usergroups --> /user_groups

Regards,

Joseph

2

What's the background info about the motivation for this name change?

··· > On Nov 17, 2013, at 11:55 AM, Joseph Magen wrote: > > I submitted a PR to rename hosts to systems and hostgroups to system_groups in the routes and the UI. I plan to update the /api routes as well but wanted to get some feedback first. > > https://github.com/theforeman/foreman/pull/1034 > > The routes changes were easy: > > - resources :hosts do > + resources :hosts, :path => :systems do > > - resources :hostgroups, :except => [:show] do > + resources :hostgroups, :path => :system_groups, :except => [:show] do > > This leaves all named URL helper paths the same, so the code doesn't need to change. hosts_paths now goes to /systems and hostgroups_path now goes to /system_groups > > All works fine but now the legacy paths /hosts and /hostgroups do not exist. Legacy routes are a "nice to have" for the UI but a "must have" for the API. In order to keep the legacy routes there are two options > > 1) Add redirect routes > 2) Add legacy routes > > Redirect routes as defined as the example below: > > get '/hosts', to: redirect('/systems') > > This works fine for GET requests, but does not work for POST/PUT/DELETE, so this is not an option for the API. > > I choose to use legacy routes with :as => which changes the name path URL helpers to avoid any clashes with the existing routes. > I added a separate file called config/routes/legacy_routes.rb > > It contains the resources that were changed in routes.rb using :path =>, and instead I added :as => > > + resources :hosts, :as => :old_hosts do > > This creates the 7 RESTful (legacy) routes for /hosts and /hosts/:id and creates named path URL helpers such as old_hosts_path, edit_old_host_path(host), etc, which are NOT used in the code, so they won't clash with the real helpers hosts_path, edit_host_path(host), etc. > > Questions > > 1. Do people see this as the right approach to maintain separate separate legacy routes? > 2. Should API v1 be updated with the new route names and maintain legacy routes, or just leave v1 as is without changing the route names? > 3. Should API v2 have new and legacy routes or just new routes with no legacy routes, since it hasn't been released yet and can still have breaking changes? > 4. I also renamed several other paths in the PR for the routs to better match the UI. Should these changes also be included? > /config_tempates --> /provisioning_templates > /ptables --> /partion_tables > /puppetclasses --> /puppet_classes > /lookup_keys --> /smart_variables > /common_parameters --> /global_parameters > /operatingsystems --> /operating_systems > /media --> /installation_media > /models --> /hardware_models > /usergroups --> /user_groups > > Regards, > > Joseph > > > > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.
3

> From: "Aaron Stone" <sodabrew@gmail.com>
> To: foreman-dev@googlegroups.com
> Sent: Monday, November 18, 2013 12:25:03 AM
> Subject: Re: [foreman-dev] renaming: hosts to systems and hostgroups to system_groups
>
> What's the background info about the motivation for this name change?

Katello uses the terms systems / system groups. Katello is now part of the Foreman project as a plugin/engine. Several objects for both projects overlap (users, roles, environments, organizations, systems, system groups).

Ohad wanted see a PR of a the changes required for Foreman UI/API to use systems / system groups while still keeps the legacy names hosts / host groups.

There is no decision yet whether this PR will be merged or not. It's just a spike.

Joseph

··· ----- Original Message -----

On Nov 17, 2013, at 11:55 AM, Joseph Magen jmagen@redhat.com wrote:

I submitted a PR to rename hosts to systems and hostgroups to system_groups
in the routes and the UI. I plan to update the /api routes as well but
wanted to get some feedback first.

https://github.com/theforeman/foreman/pull/1034

The routes changes were easy:

  • resources :hosts do
  • resources :hosts, :path => :systems do
  • resources :hostgroups, :except => [:show] do
  • resources :hostgroups, :path => :system_groups, :except => [:show] do

This leaves all named URL helper paths the same, so the code doesn’t need
to change. hosts_paths now goes to /systems and hostgroups_path now goes
to /system_groups

All works fine but now the legacy paths /hosts and /hostgroups do not
exist. Legacy routes are a “nice to have” for the UI but a "must have"
for the API. In order to keep the legacy routes there are two options

  1. Add redirect routes
  2. Add legacy routes

Redirect routes as defined as the example below:

get ‘/hosts’, to: redirect(’/systems’)

This works fine for GET requests, but does not work for POST/PUT/DELETE, so
this is not an option for the API.

I choose to use legacy routes with :as => which changes the name path URL
helpers to avoid any clashes with the existing routes.
I added a separate file called config/routes/legacy_routes.rb

It contains the resources that were changed in routes.rb using :path =>,
and instead I added :as =>

  • resources :hosts, :as => :old_hosts do

This creates the 7 RESTful (legacy) routes for /hosts and /hosts/:id and
creates named path URL helpers such as old_hosts_path,
edit_old_host_path(host), etc, which are NOT used in the code, so they
won’t clash with the real helpers hosts_path, edit_host_path(host), etc.

Questions

  1. Do people see this as the right approach to maintain separate separate
    legacy routes?
  2. Should API v1 be updated with the new route names and maintain legacy
    routes, or just leave v1 as is without changing the route names?
  3. Should API v2 have new and legacy routes or just new routes with no
    legacy routes, since it hasn’t been released yet and can still have
    breaking changes?
  4. I also renamed several other paths in the PR for the routs to better
    match the UI. Should these changes also be included?
    /config_tempates --> /provisioning_templates
    /ptables --> /partion_tables
    /puppetclasses --> /puppet_classes
    /lookup_keys --> /smart_variables
    /common_parameters --> /global_parameters
    /operatingsystems --> /operating_systems
    /media --> /installation_media
    /models --> /hardware_models
    /usergroups --> /user_groups

Regards,

Joseph

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

> What's the background info about the motivation for this name change?

Thanks for picking this up Aaron!

Last week, a few of us got together to discuss how to move forward
with Katello integration efforts.

One of the topics identified was that we have different terms for
similar things, and similar names for different things, for example:

Host vs System
Puppet Environment vs Lifecycle envionment
Hostgroup vs System group.

Normally, renaming things is a huge pain, and should be avoided unless
really required, some of us thought that the term system actually is
more applicable these days for systems management, therefor we've
agreed to try (e.g. couple of days effort) and understand what is the
actual impact to foreman and its users.

The goals that we've defined are:

  1. Change all references from Host to System, Hostgroup to System
    Definition(?), config_templates to provisioning templates etc.
  2. Update the API to reflect that, but make sure its 100% compatible
    with older API usage (e.g. nothing breaks)
  3. Consider changing the code objects as well (e.g. was not sure if we
    want to change Host::Managed to System::Managed for example).

Hope this helps,

Discussion please :slight_smile:

Thanks
Ohad

··· On Sun, Nov 17, 2013 at 5:25 PM, Aaron Stone wrote: > >> On Nov 17, 2013, at 11:55 AM, Joseph Magen wrote: >> >> I submitted a PR to rename hosts to systems and hostgroups to system_groups in the routes and the UI. I plan to update the /api routes as well but wanted to get some feedback first. >> >> https://github.com/theforeman/foreman/pull/1034 >> >> The routes changes were easy: >> >> - resources :hosts do >> + resources :hosts, :path => :systems do >> >> - resources :hostgroups, :except => [:show] do >> + resources :hostgroups, :path => :system_groups, :except => [:show] do >> >> This leaves all named URL helper paths the same, so the code doesn't need to change. hosts_paths now goes to /systems and hostgroups_path now goes to /system_groups >> >> All works fine but now the legacy paths /hosts and /hostgroups do not exist. Legacy routes are a "nice to have" for the UI but a "must have" for the API. In order to keep the legacy routes there are two options >> >> 1) Add redirect routes >> 2) Add legacy routes >> >> Redirect routes as defined as the example below: >> >> get '/hosts', to: redirect('/systems') >> >> This works fine for GET requests, but does not work for POST/PUT/DELETE, so this is not an option for the API. >> >> I choose to use legacy routes with :as => which changes the name path URL helpers to avoid any clashes with the existing routes. >> I added a separate file called config/routes/legacy_routes.rb >> >> It contains the resources that were changed in routes.rb using :path =>, and instead I added :as => >> >> + resources :hosts, :as => :old_hosts do >> >> This creates the 7 RESTful (legacy) routes for /hosts and /hosts/:id and creates named path URL helpers such as old_hosts_path, edit_old_host_path(host), etc, which are NOT used in the code, so they won't clash with the real helpers hosts_path, edit_host_path(host), etc. >> >> Questions >> >> 1. Do people see this as the right approach to maintain separate separate legacy routes? >> 2. Should API v1 be updated with the new route names and maintain legacy routes, or just leave v1 as is without changing the route names? >> 3. Should API v2 have new and legacy routes or just new routes with no legacy routes, since it hasn't been released yet and can still have breaking changes? >> 4. I also renamed several other paths in the PR for the routs to better match the UI. Should these changes also be included? >> /config_tempates --> /provisioning_templates >> /ptables --> /partion_tables >> /puppetclasses --> /puppet_classes >> /lookup_keys --> /smart_variables >> /common_parameters --> /global_parameters >> /operatingsystems --> /operating_systems >> /media --> /installation_media >> /models --> /hardware_models >> /usergroups --> /user_groups >> >> Regards, >> >> Joseph >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.
5

Aaron,

I updated the PR to say "DO NOT MERGE" to make it more clear.

Joseph

··· ----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Monday, November 18, 2013 9:14:26 AM > Subject: Re: [foreman-dev] renaming: hosts to systems and hostgroups to system_groups > > ----- Original Message ----- > > From: "Aaron Stone" > > To: foreman-dev@googlegroups.com > > Sent: Monday, November 18, 2013 12:25:03 AM > > Subject: Re: [foreman-dev] renaming: hosts to systems and hostgroups to > > system_groups > > > > What's the background info about the motivation for this name change? > > Katello uses the terms systems / system groups. Katello is now part of the > Foreman project as a plugin/engine. Several objects for both projects > overlap (users, roles, environments, organizations, systems, system groups). > > Ohad wanted see a PR of a the changes required for Foreman UI/API to use > systems / system groups while still keeps the legacy names hosts / host > groups. > > There is no decision yet whether this PR will be merged or not. It's just a > spike. > > Joseph > > > > > > > > On Nov 17, 2013, at 11:55 AM, Joseph Magen wrote: > > > > > > I submitted a PR to rename hosts to systems and hostgroups to > > > system_groups > > > in the routes and the UI. I plan to update the /api routes as well but > > > wanted to get some feedback first. > > > > > > https://github.com/theforeman/foreman/pull/1034 > > > > > > The routes changes were easy: > > > > > > - resources :hosts do > > > + resources :hosts, :path => :systems do > > > > > > - resources :hostgroups, :except => [:show] do > > > + resources :hostgroups, :path => :system_groups, :except => [:show] do > > > > > > This leaves all named URL helper paths the same, so the code doesn't need > > > to change. hosts_paths now goes to /systems and hostgroups_path now goes > > > to /system_groups > > > > > > All works fine but now the legacy paths /hosts and /hostgroups do not > > > exist. Legacy routes are a "nice to have" for the UI but a "must have" > > > for the API. In order to keep the legacy routes there are two options > > > > > > 1) Add redirect routes > > > 2) Add legacy routes > > > > > > Redirect routes as defined as the example below: > > > > > > get '/hosts', to: redirect('/systems') > > > > > > This works fine for GET requests, but does not work for POST/PUT/DELETE, > > > so > > > this is not an option for the API. > > > > > > I choose to use legacy routes with :as => which changes the name path URL > > > helpers to avoid any clashes with the existing routes. > > > I added a separate file called config/routes/legacy_routes.rb > > > > > > It contains the resources that were changed in routes.rb using :path =>, > > > and instead I added :as => > > > > > > + resources :hosts, :as => :old_hosts do > > > > > > This creates the 7 RESTful (legacy) routes for /hosts and /hosts/:id and > > > creates named path URL helpers such as old_hosts_path, > > > edit_old_host_path(host), etc, which are NOT used in the code, so they > > > won't clash with the real helpers hosts_path, edit_host_path(host), etc. > > > > > > Questions > > > > > > 1. Do people see this as the right approach to maintain separate separate > > > legacy routes? > > > 2. Should API v1 be updated with the new route names and maintain legacy > > > routes, or just leave v1 as is without changing the route names? > > > 3. Should API v2 have new and legacy routes or just new routes with no > > > legacy routes, since it hasn't been released yet and can still have > > > breaking changes? > > > 4. I also renamed several other paths in the PR for the routs to better > > > match the UI. Should these changes also be included? > > > /config_tempates --> /provisioning_templates > > > /ptables --> /partion_tables > > > /puppetclasses --> /puppet_classes > > > /lookup_keys --> /smart_variables > > > /common_parameters --> /global_parameters > > > /operatingsystems --> /operating_systems > > > /media --> /installation_media > > > /models --> /hardware_models > > > /usergroups --> /user_groups > > > > > > Regards, > > > > > > Joseph > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >