[skyline][tc] October 2021 - PTG Summary

Jeremy Stanley fungi at yuggoth.org
Tue Oct 26 12:20:55 UTC 2021


On 2021-10-26 17:32:46 +0800 (+0800), Boxiang Zhu wrote:
[...]
> ## 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.

Each of these will need to be in a separate Git repository, rather
than packaging them from a single skyline-apiserver Git repository.

> ## stop using Git's submodule feature
> Is there any reason why we should stop using git's submodule?

The distinct Git repositories should be more loosely coupled so that
you can rely on OpenDev's CI system (Zuul) to use cross-project
change dependencies correctly.

> ## use Python package configuration and tooling consistent with existing OpenStack projects
> Now skyline-apiserver use yaml to parse config and poetry to manage dependency.

OpenStack does not use poetry, currently PBR and SetupTools are used
for packaging other OpenStack deliverables.

> ## 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

I understand, but this is inconsistent with how other OpenStack
deliverables and developed and tested.

> ## 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

Yes, stop using poetry.

> ## 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

I feel like I'm a broken record here, but stop using poetry and you
will be able to do these things the way they're done in OpenStack.

> ## get Python package versions from Git tags rather than hard-coded in configuration files
> Sure, but hard-coded package version is not serious problem.

Using PBR and SetupTools will solve that for you automatically, and
will be compatible with OpenStack's release automation.

> ## 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.
[...]

Yes, but does Skyline have configuration? Does it perform any
logging? Does it use any databases? There are Oslo libraries for
handling tasks common to many OpenStack services so that all
services can do them in a consistent fashion and fixes only need to
be applied in one place to address them for all of OpenStack.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211026/0ba4fdc7/attachment.sig>


More information about the openstack-discuss mailing list