4:12 a.m.
Hi, all
with ongoing process of removing code from Ansible core into collections
[1] I'd like to raise a question - how can we build and provide RPMs from
Ansible collection?
We currently use more and more Ansible community modules in TripleO:
- Openstack modules has already moved to be in Openstack repo and won't be
present in Ansible 2.10.
- Podman modules will move to a different collection and won't be present
in Ansible 2.10
Both of them are used now and won't be provided by Ansible anymore.
I think it's worth to set up this the sooner the better to prevent
unnecessary delays in the future.
Thanks
[1]
https://www.ansible.com/blog/thoughts-on-restructuring-the-ansible-project
--
Best regards
Sagi Shnaidman
4:07 a.m.
I would go for the least problematic approach: starting to build collections ASAP.
Collections can be used starting with Ansible 2.9.
My gut feeling is that RPM approach would cause more problems than fixing.
Remember that we test our code on lots of platforms, with virtualenvs (usually tox) and
which in most cases are isolated.
This means that even if we have the RPM-with-module today, we may not be able to use it.
Even worse: upstream testing is done using Ubuntu, does this mean that we start building
debs too?
Ansible 2.9 introduced a way to install modules, via collections, which is not platform
dependent.
I would personally try to avoid reinventing the wheel and use official way.
Cheers
Sorin
On 19 Feb 2020, at 10:12, Sagi Shnaidman <sshnaidm(a)redhat.com>
wrote:
Hi, all
with ongoing process of removing code from Ansible core into collections [1] I'd like
to raise a question - how can we build and provide RPMs from Ansible collection?
We currently use more and more Ansible community modules in TripleO:
- Openstack modules has already moved to be in Openstack repo and won't be present in
Ansible 2.10.
- Podman modules will move to a different collection and won't be present in Ansible
2.10
Both of them are used now and won't be provided by Ansible anymore.
I think it's worth to set up this the sooner the better to prevent unnecessary delays
in the future.
Thanks
[1] https://www.ansible.com/blog/thoughts-on-restructuring-the-ansible-project
--
Best regards
Sagi Shnaidman
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
5:06 a.m.
Even worse: upstream testing is done using Ubuntu, does this mean
that we start building debs too?
TripleO is not tested with Ubuntu and we don't ship anything in OSP
for Ubuntu, so no, we're not going to start building debs.
Ansible 2.9 introduced a way to install modules, via collections,
which is not platform dependent.
We need to test what we ship to customers, so we need to figure that
out first for Ansible, together with the Ansible team.
Has shipping on Red Hat CDN for Collections been defined by the
Ansible organization?
e.g. for Python we do not ship wheels, we ship Python RPMs. OTOH, for
CI pieces which do not get shipped to customers installing from pypi
is fine and we're doing it, so native Ansible Collections for CI
framework dependencies will be fine too.
Alan
5:22 a.m.
We need to test what we ship to customers, so we need to figure that
out first for Ansible, together with the Ansible team.
Has shipping on Red Hat CDN for Collections been defined by the
Ansible organization?
TBH, I don't think Ansible team is a part to consult with. Openstack
modules are moved to Openstack repository and Ansible team has no any
relation to it now.
As well as Podman modules that will be moved soon (hopefully when I find
the time) to CRIO namespace (https://github.com/containers)
The whole point of Ansible 2.10 is to remove all community modules from
core and takeover of responsibilities for them to interested parties.
So I think nothing should block us to build/ship the RPMs
Thanks
--
Best regards
Sagi Shnaidman
7:25 a.m.
On Tue, Feb 25, 2020 at 12:23 PM Sagi Shnaidman <sshnaidm(a)redhat.com> wrote:
We need to test what we ship to customers, so we need to figure that
> out first for Ansible, together with the Ansible team.
> Has shipping on Red Hat CDN for Collections been defined by the
> Ansible organization?
>
TBH, I don't think Ansible team is a part to consult with. Openstack
modules are moved to Openstack repository and Ansible team has no any
relation to it now.
As well as Podman modules that will be moved soon (hopefully when I find
the time) to CRIO namespace (https://github.com/containers)
The whole point of Ansible 2.10 is to remove all community modules from
core and takeover of responsibilities for them to interested parties.
So I think nothing should block us to build/ship the RPMs
My understanding is that 2.10 sill move some supported modules also to
collections and they have defined the way to deliver it using both galaxy
for upstream and automation hub for downstream [1][2]. We could confirm
with Ansible team if they plan to deliver it *only* via automation-hub or
also using packages, but I guess we will rely on what they provide for all
supported content. I think it'd be good to have a clear picture of what
they will support and how they will deliver it.
For the collections maintained in OPenStack, it may make sense to build
RPMs for it to keep our rpm-based workflow.
[1] https://www.ansible.com/products/automation-hub
[2] https://www.ansible.com/blog/getting-started-with-automation-hub
Thanks
--
Best regards
Sagi Shnaidman
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
10:06 a.m.
On Tue, Feb 25, 2020 at 14:25 Alfredo Moralejo Alonso wrote:
On Tue, Feb 25, 2020 at 12:23 PM Sagi Shnaidman
<sshnaidm(a)redhat.com> wrote:
> We need to test what we ship to customers, so we need to figure that
>> out first for Ansible, together with the Ansible team.
>> Has shipping on Red Hat CDN for Collections been defined by the
>> Ansible organization?
>>
>
> TBH, I don't think Ansible team is a part to consult with. Openstack
> modules are moved to Openstack repository and Ansible team has no any
> relation to it now.
> As well as Podman modules that will be moved soon (hopefully when I find
> the time) to CRIO namespace (https://github.com/containers)
> The whole point of Ansible 2.10 is to remove all community modules from
> core and takeover of responsibilities for them to interested parties.
> So I think nothing should block us to build/ship the RPMs
>
>
My understanding is that 2.10 sill move some supported modules also to
collections and they have defined the way to deliver it using both galaxy
for upstream and automation hub for downstream [1][2]. We could confirm
with Ansible team if they plan to deliver it *only* via automation-hub or
also using packages, but I guess we will rely on what they provide for all
supported content. I think it'd be good to have a clear picture of what
they will support and how they will deliver it.
For the collections maintained in OPenStack, it may make sense to build
RPMs for it to keep our rpm-based workflow.
Could we investigate and/or design an `ansible-galaxy-rpm` tool to
produce and maintain the spec files?
If that doesn't exist, it could be a very useful thing to have. As an
example, the haskell packages in fedora are produced using a `cabal-rpm`
tool and it seems like a viable solution to use for maintaining the
ansible collection as rpm.
-Tristan
[1] https://www.ansible.com/products/automation-hub
[2] https://www.ansible.com/blog/getting-started-with-automation-hub
> Thanks
> --
> Best regards
> Sagi Shnaidman
> _______________________________________________
> dev mailing list
> dev(a)lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
>
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
4:33 a.m.
On Tue, Feb 25, 2020 at 14:25 Alfredo Moralejo Alonso wrote:
> On Tue, Feb 25, 2020 at 12:23 PM Sagi Shnaidman <sshnaidm(a)redhat.com>
> wrote:
>> We need to test what we ship to customers, so we need to figure that
>>> out first for Ansible, together with the Ansible team.
>>> Has shipping on Red Hat CDN for Collections been defined by the
>>> Ansible organization?
>>>
>>
>> TBH, I don't think Ansible team is a part to consult with. Openstack
>> modules are moved to Openstack repository and Ansible team has no any
>> relation to it now.
>> As well as Podman modules that will be moved soon (hopefully when I find
>> the time) to CRIO namespace (https://github.com/containers)
>> The whole point of Ansible 2.10 is to remove all community modules from
>> core and takeover of responsibilities for them to interested parties.
>> So I think nothing should block us to build/ship the RPMs
>>
>>
> My understanding is that 2.10 sill move some supported modules also to
> collections and they have defined the way to deliver it using both galaxy
> for upstream and automation hub for downstream [1][2]. We could confirm
> with Ansible team if they plan to deliver it *only* via automation-hub or
> also using packages, but I guess we will rely on what they provide for all
> supported content. I think it'd be good to have a clear picture of what
> they will support and how they will deliver it.
>
> For the collections maintained in OPenStack, it may make sense to build
> RPMs for it to keep our rpm-based workflow.
>
Could we investigate and/or design an `ansible-galaxy-rpm` tool to
produce and maintain the spec files?
If that doesn't exist, it could be a very useful thing to have. As an
example, the haskell packages in fedora are produced using a `cabal-rpm`
tool and it seems like a viable solution to use for maintaining the
ansible collection as rpm.
I felt curiosity for this, and had a look at the Ansible Galaxy API.
It seems to be quite straightforward, so I have created
https://github.com/javierpena/galaxy-collection-to-rpm with a simple script to create the
spec file for a collection.
If we wanted to build some collections using DLRN, we could add some code to provide
better support, similar to what was done in the past for Ruby gems [3].
Regards,
Javier
[3] -
https://github.com/softwarefactory-project/DLRN/commit/cd64b6b172362dbada...
-Tristan
>
> [1] https://www.ansible.com/products/automation-hub
> [2] https://www.ansible.com/blog/getting-started-with-automation-hub
>
>
>
>> Thanks
>> --
>> Best regards
>> Sagi Shnaidman
>> _______________________________________________
>> dev mailing list
>> dev(a)lists.rdoproject.org
>> http://lists.rdoproject.org/mailman/listinfo/dev
>>
>> To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
>>
> _______________________________________________
> dev mailing list
> dev(a)lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
5:35 a.m.
Regarding "TripleO is not tested with Ubuntu" statement, let me give one random
example:
Look at: https://review.opendev.org/#/c/709188/
All "tox" jobs (linters, unittests, molecule) are running on Ubuntu upstream and
they so test bits of tripleo code, on Ubuntu.
Also upstream molecule jobs are based on tox, so at least some of them run **from**
ubuntu, with redhat hosts (containers or VMs).
What we need to remember is that Controller can be an Ubuntu machine, and I am not sure if
we can fully avoid that.
So, instead of saying "is not tested with Ubuntu", we should better say that we
"do not test deployment on non redhat platforms".
The funny part comes in: when you install ansible modules/collections, you are high-likely
to do it on the controller, where you may not even have sudo.
On 25 Feb 2020, at 11:06, Alan Pevec <apevec(a)redhat.com>
wrote:
> Even worse: upstream testing is done using Ubuntu, does this mean that we start
building debs too?
TripleO is not tested with Ubuntu and we don't ship anything in OSP
for Ubuntu, so no, we're not going to start building debs.
> Ansible 2.9 introduced a way to install modules, via collections, which is not
platform dependent.
We need to test what we ship to customers, so we need to figure that
out first for Ansible, together with the Ansible team.
Has shipping on Red Hat CDN for Collections been defined by the
Ansible organization?
e.g. for Python we do not ship wheels, we ship Python RPMs. OTOH, for
CI pieces which do not get shipped to customers installing from pypi
is fine and we're doing it, so native Ansible Collections for CI
framework dependencies will be fine too.
Alan
1545
days inactive
1552
days old
7 comments
6 participants
participants (6)
-
Alan Pevec -
Alfredo Moralejo Alonso -
Javier Pena -
Sagi Shnaidman -
Sorin Sbarnea -
Tristan Cacqueray