Trends and statistics plugin

Development RFCs
1

Post The Road to Making Puppet Optional by @tbrisker mentions in point 10. extracting trends and statistics to separate plugin.

I’ve started a trello board to track this effort. We plan to remove these from foreman core in release 2.2. If you will want to use this funcionality from that point on, you will need to install plugin foreman_statistics.

If you wish to follow or even help this effort, use the board as reference, I’ll keep it up to date. If you have any suggestions or concerns please share them here as soon as possible. Once the repository for the plugin is created, I’ll update this thread.

4 Likes
2

Can you also update this post here? It makes following easier if we have to look only at one source for everything. Only having the biggest steps here would be enough. Thanks!

1 Like
3

Have you considered a Github project? We haven’t used them, but I’d be happy to create GitHub - theforeman/foreman_statistics: Foreman plugin to present statistics and trends and give you permissions. That also makes it easier to follow since it doesn’t require yet another platform.

1 Like
4

I’m definitelly up for it we could even to start the plugin directly there :slight_smile:
I wanted to move it under theforeman org only after the plugin’s in some shape, but there is no real reason to it :thinking:

Let’s do GitHub project :+1:

5

There’s now a statistics team:

It should have access to the repo:

4 Likes
6

Functionality extraction - lessons learned

I’m very close to releasing the first version of the plugin, so I’ve decided to share how it went.

In general this was very easy to do, as the trends are not tied up to other funcionalities. But there still were some difficulties I’ve faced during working on this and I’d like to share

Premisses I wanted to achieve during the extraction:

  • Make the transition as smooth as possible.
  • The code to be extracted should work for at least one more version, whilst the plugin can be installed and tested with this version.
  • The plugin can be installed and removed easily and the old code that is in core should be still working.

I’ve decided to move the plugin to isolated_namespace for two main reasons.

  1. I believe it’s a good practice, as the plugins are guaranteed not to collide with their routes and classes.
  2. It’s much easier to notice we’ve missed something that should’ve been moved and is still used from the core code.

Models

The models are now in an isolated namespace, so it’s necessary to adjust the STI and class references. I needed to move the associations to the right classes and add a migration that will adjust the STI on existing records.

Controllers

Routes from core can live alongside the routes from plugin, thanks to the isolated namespaces.

Only the menu items have to be adjusted to point to the plugin routes and we are all set.

Migrations

Migrations are a bit tricky, as Rails won’t allow us to have two same migrations alongside each other, I’ve decided to add a new migration path that would be kept only as an extraction point and if we decide to keep the migrations as they are. This migration path is only added if the version of foreman is higher than version, that is planned not to include the extracted code.

Best case scenario we will create new migrations, that will rename or create the namespaced tables and thus finish the migration to the new

Settings

Settings turn out to be the hardest, as it’s almost impossible to adjust the existing setting category. I’m currently trying to improve the situation, so I’m not going to write more here. Please follow Setting in memory, only changed values in database for details.

Permissions

I’ve kept the same permissions as we had, so I only needed to adjust the routes and resources the permissions are related to. For that in memory I needed to remove the old ones and add the same ones with new routes and in the database migrate the resources for those permissions. It could definitely be easier for plugins to adjust permissions, but I’ve decided not to touch this as it can be done without too much pain even now.

5 Likes
7

Thanks @ezr-ondrej, great write up! Few follow up questions

Looking back now, was the namespace worth the effort? Would you go with that option again if you didn’t need to have the code both in core and in plugin for a transition period?

I recall when template inputs was migrated from plugin to the core, I ended up with just moving files from one repo to another. That worked, because the migration had the same number and Rails automatically detected, whether it needs to be applied or not. Of course it had to be removed from the original place, meaning the new plugin version was required for a given Foreman release. However that seems to become more and more common.

Assuming there wasn’t a need for having a transition period of feature remains in core but also runs as a plugin, would this be usable or even easier? Of course given there’s no namespace migration.

8

It didn’t took as much effort, so I believe it was worth it. There were few hiccups, but it helped to quickly discover some places I’d forget otherwise. IMHO the clean code is worth it so my answer is definitely yes, but again Trends nor Statistics were very closely tied up in core’s code, so hard to say if I’d be as optimistic in case of Puppet.

It’d be definitely a way to go and I belive it’s still a way we can take once we’re releasing for Foreman 2.2, given we decide not to namespace the tables maybe even if we do, because that way the plugin takes over the ownership of those migrations. If we just delete them, we have tables, that are kept in database and hard to get rid of.