Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Better setup mechanism #398

Merged
merged 45 commits into from Feb 20, 2016
Merged

Better setup mechanism #398

merged 45 commits into from Feb 20, 2016

Conversation

SunilMohanAdapa
Copy link
Member

The actual set of changes are small and easy. Each application required updates and I made those changes make the number of lines modified large. I tried to make all of those changes separately for easy review.

As side-effect of the implementation, I see much faster page loads due to elimination of package installation and also ability to perform queued installations and parallel setups.

Most of the intended changes are completed but very small parts remain. Here are my design notes they may be useful.

Design notes

Usability

  • DONE Applications should be visible without getting setup. Description
    should be visible before setup. Plinth should provide a generic
    mechanism for starting setup.
  • DONE Must be very simple for applications to write setup mechanisms.
    Setup process should have a synchronous flow if possible. Plinth
    should automatically show a progress of the setups happening.
  • DONE Ability to run --setup during first install to setup critical
    packages. This should be synchronous and should not start a server.
  • TODO Ability to upgrades applications during Plinth upgrade. Package
    manager will be running during Plinth upgrade. Plinth will be
    restarted, during upgrades. Initially this may be implemented by
    users having to manually run the setup process again. Later a
    background process which waits for package manager to finish can
    automatically trigger upgrades.
  • DONE Ability for application to specify that they are critical for
    operation of Plinth and must be installed by default.

Design for Application:

  • DONE Applications will specify a version number (simple integer) in their
    init module. This will be incremented whenever the application
    intends to upgrade an existin setup.
  • DONE Application will implement setup(), they will call utility methods
    to run a pre-setup operation, install packages and post-install
    operation.
  • DONE Application setup process shall be idempotent.
  • DONE Application setup process will receive the older version as
    arguments. This may be used to perform upgrades instead of fresh
    setup. Older version will be NULL for first time setup.
  • DONE Application will have a flag to indicate that it is critical for the
    functionality of Plinth. This application will be setup initially.

Design for Plinth:

  • DONE Currently setup version numbers of applications will be stored by
    Plinth and will be compared with current module version numbers to
    see if an application needs upgrading.
  • DONE Using a middleware, Plinth will intercept all module views and check
    if the module requires setup or upgrades. It will prompt and show
    progress accordingly instead of allowing the view to be shown.
  • DONE Plinth will implement a '--setup' command line which will upgrade
    all applications and install critical ones.
  • TODO Plinth setup process will proceed in the dependency order. If a
    setup for an application fails, it's dependencies will not be setup.
  • DONE Show errors during installation properly
  • DONE Handle empty setup
  • DONE Remove old style package views and decorators

@SunilMohanAdapa
Make app names as module identifiers
7f4c5f7 
- The last part of the module import path is the module name.  This also
  becomes the Django app name.  Apps names have to be unique.  Hence,
  there is no scope for two different modules with same name but
  different load path to exist in the project.

- Most uses of list of loaded modules are dealing with app names instead
  of full module load path.  This is due to the fact that Django deals
  with app names and not module paths.

- It is also somewhat clumsy to access a loaded module as we are
  re-importing every time to get access module.

- Simplify all of the above by using app names are module identifiers
  and maintaing an ordered dictionary of app names to loadded modules.

- Remove unused imports.

- Minor styling fixes.
@SunilMohanAdapa
Cleanup final use of urls.patterns() method
1e8cc6f 
- As deprecated in Django 1.9.
@SunilMohanAdapa
package: Proper string casting of PackageException
20a9748
@SunilMohanAdapa
package: Expose starting install without thread
716ba5f
@SunilMohanAdapa
models: New model to store module setup versions
2bba8b0
@SunilMohanAdapa
setup: New module to handle application setup
be6ccab 
- There shall be a setup helper object in every module.  The setup
  process will simply call methods in helper.

- Helper is responsible for loading/storing/checking module setup
  versions.

- Methods help in showing progress of setup process automatically.
@SunilMohanAdapa
module_loader: Add setup helper to every module
80d9f0d 
- During initialization add a setup helper to every module.  For use
  later.
@SunilMohanAdapa
views: New view to show setup need and progress
7a4a8fb
@SunilMohanAdapa
middleware: New middleware to check need for setup
8dcafe3 
- Call the setup helper to check if a installation or update of a module
  is required.

- Show installation and progress using the setup view.
@SunilMohanAdapa
main: Add command argument to setup essential apps
2c83604 
- The --setup argument sets up all applications that declare themselves
  as essential.

- This is done synchronously.

- Plinth exits after the setup is complete.

- Plinth fails with an error in case any of the setup tasks fail.  The
  process will be continued on next invocation or access of application
  from UI.
@SunilMohanAdapa
templates: Base template for all applications
45a1bff 
To show introduction and title of a module which will be available as
properties of a module.  This allows the setup process to show the
introduction to the application instead of a blank page.
@SunilMohanAdapa
privoxy: Use new setup mechanism
b112c82
@SunilMohanAdapa
apps: Use new setup mechanism
83a56bb
@SunilMohanAdapa
avahi: Use new setup mechanism
ad8fea5
@SunilMohanAdapa
config: Use new setup mechanism
9d1a940
@SunilMohanAdapa
datetime: Use new setup mechanism
0e0b831
@SunilMohanAdapa
deluge: Use new setup mechanism
68881f7
@SunilMohanAdapa
diagnostics: Use new setup mechanism
28a889c
@SunilMohanAdapa
dynamicdns: Use new setup mechanism
1842db4
@SunilMohanAdapa
firewall: Use new setup mechanism
38bf4d4 
- Also reorganize module to separate out views.
@SunilMohanAdapa
ikiwiki: Use new setup mechanism
cceddf5
@SunilMohanAdapa
letsencrypt: Use new setup mechanism
cef8f5c
@SunilMohanAdapa
monkeysphere: Use new setup mechanism
608d19d
@SunilMohanAdapa
monkeysphere: Fix error with no host keys
1f8ccb6
@SunilMohanAdapa
mumble: Use new setup mechanism
41e730d
@SunilMohanAdapa
names: Use new setup mechanism
0568bf2
@SunilMohanAdapa
networks: Use new setup mechanism
335eecc
@SunilMohanAdapa
openvpn: Use new setup mechanism
b916d95
@SunilMohanAdapa
owncloud: Use new setup mechanism
166ff9b 
- Also reorganize views.
@SunilMohanAdapa
pagekite: Use new setup mechanism
5e09493
@jvalleroy jvalleroy merged commit 55cabda into freedombox:master Feb 20, 2016
@jvalleroy
Copy link
Member

I've merged this with a few minor fixes. Please check that my changes are correct.

@SunilMohanAdapa
Copy link
Member Author

Thanks for the changes. They look good.

@SunilMohanAdapa SunilMohanAdapa deleted the better-setup branch June 12, 2016 11:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@SunilMohanAdapa @jvalleroy