Hi, Well, it's Skyline Team's first time to attend the PTG : ) Thank you for your attention and discussion of Skyline. And welcome more friends to join us! You can see all the notes in a read-only etherpad here: - skyline etherpad: https://etherpad.opendev.org/p/r.b44d07e6504a4b38514b2717f01aca62 - tc etherpad: https://etherpad.opendev.org/p/r.a07136b01df95515f32c4cb779faa45c#L395 ## reorganize to one Python package per Git repository Now skyline-apiserver has divided the source code into six sections: - skyline-apiserver: core source code of skyline apiserver - skyline-config: config library with yaml to parse config file - skyline-console: git submodule of skyline-console - skyline-log: log library with loguru - skyline-nginx: generate the nginx.conf file with openstack environment - skyline-policy-manager: generate policy yaml file Generally, we just focus on skyline-apiserver. ## stop using Git's submodule feature Is there any reason why we should stop using git's submodule? ## use Python package configuration and tooling consistent with existing OpenStack projects Now skyline-apiserver use yaml to parse config and poetry to manage dependency. ## call Python entrypoints directly from tox instead of using tox as a wrapper around make Scripts[0] get converted to console_scripts entry points, plugins[1] would allow for arbitrary entry points. https://python-poetry.org/docs/pyproject/#scripts https://python-poetry.org/docs/pyproject/#plugins ## constrain Python dependencies and test dependencies in tox configuration (pip -c) Yet, there is no constraints like pip -c in poetry. Find some discussion about this in poetry. But all are closed, not merged. https://github.com/python-poetry/poetry/pull/4005 https://github.com/python-poetry/poetry-core/pull/172 ## track Python dependencies and test dependencies in requirements files Now we track python depentdencies and test dependencies in poetry's tool.poetry.dependencies and tool.poetry.dev-dependencies ## get Python package versions from Git tags rather than hard-coded in configuration files Sure, but hard-coded package version is not serious problem. ## rely more on Oslo libraries (currently only oslo.policy is used) Reuse wherever possible. oslo.policy is used to generate the policy yaml for skyline to use. ## Horizon has plugin support so that projects like Manila can add dashboard support. Skyline's architecture and technology stacks are different from horizon. So we will continue to explore how to gracefully add non-core module functionality via plug-ins. At the same time, we will also improve core component functions. Best Regards Boxiang Zhu