Welcome to developer documentation for Leapp!ΒΆ
Leapp is an OS and application modernization framework.
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
- Deprecation
- List of the deprecated functionality in leapp
- current upstream development (till the next release + 6months)
- v0.15.0 (till Mar 2023)
- What is covered by deprecation process in leapp?
- What does it mean that something is deprecated?
- What is the deprecation process for leapp?
- How do I find out what is deprecated?
- How to deprecate entities in leapp?
- Additional various outputs of snactor and leapp
- Additional simple usage examples of @deprecated
- Leapp repositories
- Repository Directory Layout
- Leapp repository for RHEL 7 to RHEL 8 upgrade
- How to create a Leapp actor for RHEL 7 to 8 upgrade
- How to properly inhibit the RHEL 7 to 8 upgrade process
- Environment variables for the el7toel8 repository
- LEAPP_GRUB_DEVICE
- LEAPP_NO_RHSM
- LEAPP_OVL_SIZE
- LEAPP_DEBUG
- LEAPP_VERBOSE
- LEAPP_CONFIG
- LEAPP_LOGGER_CONFIG
- LEAPP_ENABLE_REPOS
- LEAPP_SERVICE_HOST
- LEAPP_PROXY_HOST
- LEAPP_TARGET_PRODUCT_CHANNEL
- LEAPP_NO_NETWORK_RENAMING
- LEAPP_DATABASE_FORCE_SYNC_ON
- LEAPP_NO_INSIGHTS_REGISTER
- LEAPP_NO_RHSM_FACTS
- LEAPP_NOGPGCHECK
- LEAPP_TARGET_ISO
- LEAPP_UNSUPPORTED
- Development environment variables for the el7toel8 repository
- LEAPP_DEVEL_RPMS_ALL_SIGNED
- LEAPP_DEVEL_TARGET_RELEASE
- LEAPP_DEVEL_SKIP_CHECK_OS_RELEASE
- LEAPP_DEVEL_DM_DISABLE_UDEV
- LEAPP_DEVEL_SOURCE_PRODUCT_TYPE
- LEAPP_DEVEL_TARGET_PRODUCT_TYPE
- LEAPP_DEVEL_USE_PERSISTENT_PACKAGE_CACHE
- LEAPP_DEVEL_DATABASE_SYNC_OFF
- LEAPP_DEVEL_INITRAM_NETWORK
- LEAPP_DEVEL_KEEP_DISK_IMGS
- Deprecated functionality in the el7toel8 repository
- Infrastructure
- Best Practices for actor development
- 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
- 1. Avoid Inheriting from Multiple Classes
- 2. Avoid Operator Overloading
- 3. Avoid ‘In-Your-Face‘ error/exception messages
- 4. Avoid
**kwargslike a plague - 5. Import things the right way
- 6. Avoid Using Assertions For Control Flow & Mutating Operations
- 7. Avoid Map, Reduce and Too Complex Comprehensions
- 8. Avoid Deeply Nested Block Scopes
- 9. Write Docstrings That Work Well With Tools
- 10. Avoid Shadowing Python Builtins
- 11. String Formatting
- 12. Docstrings
- 13. Underscore usage
- 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