Welcome to developer documentation for Leapp!ΒΆ
Leapp is an OS and application modernization framework.
- Resources not included in this RTD:
- NVR schema used for for leapp-related rpm packages.
Contents:
- Terminology
- Tutorials
- Installing the development environment
- Creating a new repository for actor development
- Creating your first actor
- How to create a Leapp actor for RHEL 7 to 8 upgrade
- Introduction
- Setting up the development environment
- Tools
- Creating an actor
- Including an actor in the RHEL 7 to 8 upgrade process
- Inter-actor communication
- Testing your new actor
- Writing tests for an actor
- Best practices
- Contributing actors to the Leapp project
- FAQ
- In which existing workflow phase should I place my new actor?
- How to stop the upgrade in case my actor finds a problem with the system setup?
- How to stop execution of my actor in case of an unexpected error?
- How does the logging work?
- What Python version my actor/tests code should be compatible with?
- How to add tests to my new actor?
- How to use libraries or data files in my new actor?
- Where can I report an issue or RFE related to the framework or other actors?
- Where can I seek help?
- How to properly inhibit the RHEL 7 to 8 upgrade process
- Using messaging to send data between actors
- Asking user questions
- Linking repositories
- Working with workflows
- Workflow APIs
- Writing tests for actors
- Debugging actors
- Leapp repositories
- Infrastructure
- Best Practices for actor developmemt
- Follow the contribution guidelines
- Avoid running code on a module level
- Avoid certain global imports
- Use the snactor tool for development
- Move generic functionality to libraries
- Discover standard library functions
- Prefer using stdlib functions over shell commands
- Utilize messages produced by existing actors
- Write unit testable code
- Do not introduce new dependencies
- Use convenience exceptions to stop the actor‘s execution
- Use the LEAPP and LEAPP_DEVEL prefixes for new envars
- Tests for actors
- Architecture overview
- Inplace Upgrade Workflow
- Contributing to the Leapp project
- Coding Guidelines for the Leapp project
- Frequently Asked Questions
- What is Leapp?
- How can I get on board with contributing to Leapp?
- What is an actor and what does it do?
- When and why do I need to write an actor?
- How can I exchange any data between actors?
- What do I have to do in order to execute actor I just wrote?
- What should I do if I need to execute multiple actors? Can I somehow ensure the dependencies between them?
- How can I specify what run time dependencies will my actor have?
- How can I distinguish between actors that I depend on directly (I need to consume their output) and indirectly (I just need them to be executed as part of the upgrade as I don‘t handle the upgrade of that specific piece; think PHP vs. Apache - upgrade of Apache is independent of the upgrade of PHP but it needs to be done to enable its upgrade)?
- Once I write an actor that consumes data from some other actors, how can I be sure that the format will not change on the producing side in the future?
- What are the best practices for writing actors?
- What are the requirements for actors to be accepted by upstream?
- How can I debug my actor? Is there a standard/supported way how to log and get logs from actors/channels?
- Are there some technical limitations for an actor? E.g. maximum time execution, size of the input/output, libraries I can use... In case there are, is it possible to specify that the actor needs e.g. longer time for execution?
- Are there some actions that are either forbidden or not recommended to be done in actors?
- I got an error about PES data/ Repositories mapping where I find such files?
- Python documentation for the leapp package
- Subpackages
- Submodules
- leapp.compat module
- leapp.config module
- leapp.exceptions module
- leapp.snactor.fixture module
- Module contents