Open Stack

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211026/161e5041/attachment.htm>