Hi,
As explained during the CentOS Interlock, I'd like to take over Ansible maintenance within the Config Management SIG. I need at least Julien's and Fabian's official approval by email on centos-devel to do so.
The goal of this particular effort will be to: * ship "ansible" (S)RPMs and their dependencies not in CentOS itself * write documentation on how to do this rebuild again if needed * write documentation on how to install Ansible as shipped by the SIG
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Current status: * build targets and tags for Ansible 1.9 and 2.0 are already in CBS ( https://bugs.centos.org/view.php?id=10850 ) * these are multiarch (x86_64 + aarch74) - ansible is noarch which is OK on paper, yet due to https://bugzilla.redhat.com/show_bug.cgi?id=1392918 it could be problematic (Fabian, thanks for the heads-up) * ansible 1.9, 2.1, 2.2 have all been built in CBS by different SIGs * ansible 1.9 to 2.2 have all been built in Fedora's koji for EPEL
Checklist: * access to cbs (I'm good) * request the missing build targets & tags (2.1 & 2.2) via bugs.centos.org * enough github access rights to https://github.com/centos-sig-configmanagement to create and manage repositories there * commit access to https://github.com/centos-sig-configmanagement/ansible - note that I /will/ replace that repository by a new one, with a git branch per ansible version
Timetable: I aim to ship ansible 1.9 to 2.2 by early January. It is expected that some versions might ship much earlier than others. Testing is expected to be minimal for the first iteration of the project.
Comments welcome of course.
Best regards, François
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ? Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
[1]: https://github.com/ansible/ansible/releases
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
François
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter] _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Le samedi 12 novembre 2016 à 18:12 +0100, François Cami a écrit :
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
I brought that issue with the other developers of Ansible. There is plan to remove it from epel (1.9), and I suspect the last update will be to fix CVE-2016-8628, then it will likely be declared officially EOL.
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
Porting the software to 2.X is a option (albeit I guess not the favored one)
While there isn't much serious security issue with Ansible[1], relying on obsoletes version is bad. If some playbooks can't be ported to 2.X or if there is no will or timeline to that to happen, it is effectively not maintained to my eyes.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
I think we need to have a specific page that outline the timeline of support, but that would be much easier if we knew the upstream policy, which I plan to ask to be clarified upstream.
[1] the worst problems found so far requires a root compromised server in the first place _and_ a very specific set of playbook, cf CVE-2016-8628, CVE-2014-4966 (I can give details offlist if people are interested).
On Mon, Nov 14, 2016 at 2:40 PM, Michael Scherer mscherer@redhat.com wrote:
Le samedi 12 novembre 2016 à 18:12 +0100, François Cami a écrit :
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
I brought that issue with the other developers of Ansible. There is plan to remove it from epel (1.9), and I suspect the last update will be to fix CVE-2016-8628, then it will likely be declared officially EOL.
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
Porting the software to 2.X is a option (albeit I guess not the favored one)
While there isn't much serious security issue with Ansible[1], relying on obsoletes version is bad. If some playbooks can't be ported to 2.X or if there is no will or timeline to that to happen, it is effectively not maintained to my eyes.
See below :)
To clarify: while I plan to make 1.9 available, it is best thought as a historical effort like http://vault.centos.org/ and our users will be encouraged to use the future ansible2 repository.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
I think we need to have a specific page that outline the timeline of support, but that would be much easier if we knew the upstream policy, which I plan to ask to be clarified upstream.
Awesome, thank you!
François
[1] the worst problems found so far requires a root compromised server in the first place _and_ a very specific set of playbook, cf CVE-2016-8628, CVE-2014-4966 (I can give details offlist if people are interested). -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Le lundi 14 novembre 2016 à 14:55 +0100, François Cami a écrit :
On Mon, Nov 14, 2016 at 2:40 PM, Michael Scherer mscherer@redhat.com wrote:
Le samedi 12 novembre 2016 à 18:12 +0100, François Cami a écrit :
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
I brought that issue with the other developers of Ansible. There is plan to remove it from epel (1.9), and I suspect the last update will be to fix CVE-2016-8628, then it will likely be declared officially EOL.
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
Porting the software to 2.X is a option (albeit I guess not the favored one)
While there isn't much serious security issue with Ansible[1], relying on obsoletes version is bad. If some playbooks can't be ported to 2.X or if there is no will or timeline to that to happen, it is effectively not maintained to my eyes.
See below :)
To clarify: while I plan to make 1.9 available, it is best thought as a historical effort like http://vault.centos.org/ and our users will be encouraged to use the future ansible2 repository.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
I think we need to have a specific page that outline the timeline of support, but that would be much easier if we knew the upstream policy, which I plan to ask to be clarified upstream.
Awesome, thank you!
So after asking and not getting satisfying answer, and after searching again if I didn't miss something, I opened: https://github.com/ansible/community/issues/143
Even if the situation with ansible-ceph is less dire than what I understood (sorry if I did sounded too harsh), the problem will repeat itself for others versions and others projects, so the document is really needed.
I really wonder if one solution couldn't also to deliver each installer as a container, bundling a specific version of ansible for that installer to be run.
On Mon, Nov 14, 2016 at 6:40 AM, Michael Scherer mscherer@redhat.com wrote:
Le samedi 12 novembre 2016 à 18:12 +0100, François Cami a écrit :>> Yes.
There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
Porting the software to 2.X is a option (albeit I guess not the favored one)
While there isn't much serious security issue with Ansible[1], relying on obsoletes version is bad. If some playbooks can't be ported to 2.X or if there is no will or timeline to that to happen, it is effectively not maintained to my eyes.
Ansible 2.2 support is in a PR, here: https://github.com/ceph/ceph-ansible/pull/1068
The current problem with the ceph-ansible project is that we lack a robust CI framework to test all the codepaths, which means that PRs get merged with little to no testing at this point. We're working to change that, sometimes at the expense of merging things quickly.
- Ken
On 11/14/2016 08:41 AM, Ken Dreyer wrote:
The current problem with the ceph-ansible project is that we lack a robust CI framework to test all the codepaths, which means that PRs get merged with little to no testing at this point. We're working to change that, sometimes at the expense of merging things quickly.
Do you think this current work with getting multiple Ansible versions in ci.centos.org as well as Francois' work overall with Ceph in CentOS CI might help supplement the upstream CI need?
Regards,
- Karsten
On Tue, Nov 15, 2016 at 11:42 AM, Karsten Wade kwade@redhat.com wrote:
On 11/14/2016 08:41 AM, Ken Dreyer wrote:
The current problem with the ceph-ansible project is that we lack a robust CI framework to test all the codepaths, which means that PRs get merged with little to no testing at this point. We're working to change that, sometimes at the expense of merging things quickly.
Do you think this current work with getting multiple Ansible versions in ci.centos.org as well as Francois' work overall with Ceph in CentOS CI might help supplement the upstream CI need?
I think that will help. There's a lot of "pip installs" going on currently for https://jenkins.ceph.com/job/ceph-ansible-pull-requests/ :)
- Ken
I think our use case will have to keep using Ansible from pip as long as we are running off of static jenkins slaves on ci.centos.org, though.
We have different projects leveraging Ansible for CI and they are using different versions of Ansible, thus we bootstrap a new virtualenv on each job so we don't conflict with each other.
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Tue, Nov 15, 2016 at 1:49 PM, Ken Dreyer kdreyer@redhat.com wrote:
On Tue, Nov 15, 2016 at 11:42 AM, Karsten Wade kwade@redhat.com wrote:
On 11/14/2016 08:41 AM, Ken Dreyer wrote:
The current problem with the ceph-ansible project is that we lack a robust CI framework to test all the codepaths, which means that PRs get merged with little to no testing at this point. We're working to change that, sometimes at the expense of merging things quickly.
Do you think this current work with getting multiple Ansible versions in ci.centos.org as well as Francois' work overall with Ceph in CentOS CI might help supplement the upstream CI need?
I think that will help. There's a lot of "pip installs" going on currently for https://jenkins.ceph.com/job/ceph-ansible-pull-requests/ :)
- Ken
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
I just learned that Ansible is already packaged in SIGs [1].
Can we straigthen that out so that there's not multiple individuals working towards the same goals ?
[1]: http://cbs.centos.org/koji/buildinfo?buildID=11347
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Sat, Nov 12, 2016 at 12:12 PM, François Cami fcami@fedoraproject.org wrote:
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
François
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter] _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Sorry, I had meant to reply earlier.
We (PAAS Sig) need ansible for our OpenShift installer. We already have it packaged in CentOS, and as it's pointed out, many other groups are using that package.
I would like to transition to using the ansible from the Config Management SIG, as long as it is compatible/comparable to the ansible released by RHEL and EPEL. I wasn't part of the conversation at CentOS Interlock, but I sure hope that is one of the goals.
The problem is, we can't wait until January. Our product is already out and needs an ansible update to 2.2.0, so that is going to be coming out soon. We plan on doing our ansible 2.2.0 release, and then start a transition to using the Config Management ansible.
That's my plan. If someone has better ideas, I won't mind hearing them.
Troy
On Mon, Nov 14, 2016 at 4:58 PM, David Moreau Simard dms@redhat.com wrote:
I just learned that Ansible is already packaged in SIGs [1].
Can we straigthen that out so that there's not multiple individuals working towards the same goals ?
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Sat, Nov 12, 2016 at 12:12 PM, François Cami fcami@fedoraproject.org wrote:
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
François
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter] _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 14/11/16 23:16, Troy Dawson wrote:
Sorry, I had meant to reply earlier.
We (PAAS Sig) need ansible for our OpenShift installer. We already have it packaged in CentOS, and as it's pointed out, many other groups are using that package.
I would like to transition to using the ansible from the Config Management SIG, as long as it is compatible/comparable to the ansible released by RHEL and EPEL. I wasn't part of the conversation at CentOS Interlock, but I sure hope that is one of the goals.
The problem is, we can't wait until January. Our product is already out and needs an ansible update to 2.2.0, so that is going to be coming out soon. We plan on doing our ansible 2.2.0 release, and then start a transition to using the Config Management ansible.
That's my plan. If someone has better ideas, I won't mind hearing them.
I think thats a sound plan.
w.r.t inheriting changes from another SIG's content - I've spoken in the past about having a testable path, so every change for a component needed by SIG A but owned by SIG B, should come through a test(ed/able) path if possible.
that would help reduce the number of versions we need to keep around, wherin a SIG had to tag locally content they were not ready to move to upstream yet
On 15 Nov 14:36, Karanbir Singh wrote:
On 14/11/16 23:16, Troy Dawson wrote:
Sorry, I had meant to reply earlier.
We (PAAS Sig) need ansible for our OpenShift installer. We already have it packaged in CentOS, and as it's pointed out, many other groups are using that package.
I would like to transition to using the ansible from the Config Management SIG, as long as it is compatible/comparable to the ansible released by RHEL and EPEL. I wasn't part of the conversation at CentOS Interlock, but I sure hope that is one of the goals.
The problem is, we can't wait until January. Our product is already out and needs an ansible update to 2.2.0, so that is going to be coming out soon. We plan on doing our ansible 2.2.0 release, and then start a transition to using the Config Management ansible.
That's my plan. If someone has better ideas, I won't mind hearing them.
I think thats a sound plan.
w.r.t inheriting changes from another SIG's content - I've spoken in the past about having a testable path, so every change for a component needed by SIG A but owned by SIG B, should come through a test(ed/able) path if possible.
that would help reduce the number of versions we need to keep around, wherin a SIG had to tag locally content they were not ready to move to upstream yet
That is the plan ; we would only release ansible versions that can use other sig's installers. That is not an optional step.
I am still waiting for CI access to get that started.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 15/11/16 14:39, Julien Pivotto wrote:
On 15 Nov 14:36, Karanbir Singh wrote:
On 14/11/16 23:16, Troy Dawson wrote:
Sorry, I had meant to reply earlier.
We (PAAS Sig) need ansible for our OpenShift installer. We already have it packaged in CentOS, and as it's pointed out, many other groups are using that package.
I would like to transition to using the ansible from the Config Management SIG, as long as it is compatible/comparable to the ansible released by RHEL and EPEL. I wasn't part of the conversation at CentOS Interlock, but I sure hope that is one of the goals.
The problem is, we can't wait until January. Our product is already out and needs an ansible update to 2.2.0, so that is going to be coming out soon. We plan on doing our ansible 2.2.0 release, and then start a transition to using the Config Management ansible.
That's my plan. If someone has better ideas, I won't mind hearing them.
I think thats a sound plan.
w.r.t inheriting changes from another SIG's content - I've spoken in the past about having a testable path, so every change for a component needed by SIG A but owned by SIG B, should come through a test(ed/able) path if possible.
that would help reduce the number of versions we need to keep around, wherin a SIG had to tag locally content they were not ready to move to upstream yet
That is the plan ; we would only release ansible versions that can use other sig's installers. That is not an optional step.
I am still waiting for CI access to get that started.
it might just be me, but i dont see a request from you filed at bugs.c.o, do you have a number handy ?
On 15 Nov 16:21, Karanbir Singh wrote:
On 15/11/16 14:39, Julien Pivotto wrote:
On 15 Nov 14:36, Karanbir Singh wrote:
On 14/11/16 23:16, Troy Dawson wrote:
Sorry, I had meant to reply earlier.
We (PAAS Sig) need ansible for our OpenShift installer. We already have it packaged in CentOS, and as it's pointed out, many other groups are using that package.
I would like to transition to using the ansible from the Config Management SIG, as long as it is compatible/comparable to the ansible released by RHEL and EPEL. I wasn't part of the conversation at CentOS Interlock, but I sure hope that is one of the goals.
The problem is, we can't wait until January. Our product is already out and needs an ansible update to 2.2.0, so that is going to be coming out soon. We plan on doing our ansible 2.2.0 release, and then start a transition to using the Config Management ansible.
That's my plan. If someone has better ideas, I won't mind hearing them.
I think thats a sound plan.
w.r.t inheriting changes from another SIG's content - I've spoken in the past about having a testable path, so every change for a component needed by SIG A but owned by SIG B, should come through a test(ed/able) path if possible.
that would help reduce the number of versions we need to keep around, wherin a SIG had to tag locally content they were not ready to move to upstream yet
That is the plan ; we would only release ansible versions that can use other sig's installers. That is not an optional step.
I am still waiting for CI access to get that started.
it might just be me, but i dont see a request from you filed at bugs.c.o, do you have a number handy ?
Sorry, I did just mail CICO people, did not create a ticket. mea culpa.
Fixed now:
https://bugs.centos.org/view.php?id=12221 https://bugs.centos.org/view.php?id=12222
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Nov 14, 2016 at 11:58 PM, David Moreau Simard dms@redhat.com wrote:
I just learned that Ansible is already packaged in SIGs [1].
Yes indeed! Quoting my original email: "* ansible 1.9, 2.1, 2.2 have all been built in CBS by different SIGs" In fact the goal of the current effort is to make Ansible consumable by other SIGs so that they depend on Config Management repositories if they want to instead of tagging ansible itself into their own repositories.
Can we straigthen that out so that there's not multiple individuals working towards the same goals ?
Agreed :)
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Sat, Nov 12, 2016 at 12:12 PM, François Cami fcami@fedoraproject.org wrote:
On Sat, Nov 12, 2016 at 6:02 PM, David Moreau Simard dms@redhat.com wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ?
The answer is quite probably "no".
Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Yes. There will be a note in the wiki making that clear. Tbh I have no other choice as ceph upstream repeatedly told me the ceph-ansible playbook is only validated against ansible-1.9 for now.
One of the goals of the ansible effort is to test that particular playbook against different ansible versions and fix the bugs in the playbook. I'd rather start from a known-working environment than from a broken one to do so.
François
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
David Moreau Simard Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter] _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12 Nov 12:02, David Moreau Simard wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ? Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
It looks like it would be valuable to have an ansible2 tag -- and repo. Because that is what most users will want (we can keep 21 and 22 for power users that want more API compat.).
On Sat, Nov 12, 2016 at 11:19 PM, Julien Pivotto roidelapluie@inuits.eu wrote:
On 12 Nov 12:02, David Moreau Simard wrote:
On Sat, Nov 12, 2016 at 11:37 AM, François Cami fcami@fedoraproject.org wrote:
Version-wise, I plan to deliver 1.9/2.0/2.1/2.2 in separate repositories managed by separate centos-release-ansible-{19,20,21,22} RPMs. Any issue during the build and test phases will be reported here or on IRC. Persistent issues will be posted to the wiki.
Does upstream Ansible even support as far back as 1.9.x and 2.0.x ? Are you going to be shipping what are basically EOL and unsupported/unmaintained versions ?
Looking at releases [1], the last 2.0.x and 1.9.x versions were both in April 2016 -- not /that/ old by any stretch but still old enough to question upstream about their supportability.
It looks like it would be valuable to have an ansible2 tag -- and repo. Because that is what most users will want (we can keep 21 and 22 for power users that want more API compat.).
Noted, thanks for the suggestion.
François
-- (o- Julien Pivotto //\ Config Management SIG V_/_ https://frama.link/cfgmgmt
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Timetable: I aim to ship ansible 1.9 to 2.2 by early January. It is expected that some versions might ship much earlier than others. Testing is expected to be minimal for the first iteration of the project.
Seems like a good way to jump start this would be to rebuild EPEL's 1.9 and 2.2 in cbs right away.
Comments welcome of course.
Best regards, François _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
David Moreau Simard -
François Cami -
Jason Brooks -
Julien Pivotto -
Karanbir Singh -
Karsten Wade -
Ken Dreyer -
Michael Scherer -
Troy Dawson