pulpcore 3.7.3 and pulp_ansible 0.5.0 #61
Conversation
|
@jlsherrill is pulp_ansible 0.5.0 OK for Katello? |
|
its not actually, there's a few changes we need to make: https://projects.theforeman.org/issues/31197 can you hold on that upgrade for now? |
|
but still give us 3.7.3 ;) Or you could put ansible 0.5.0 in 3.8 repos, that'd be fine |
|
Well, I could... But galaxy-ng was asking for a 3.7 with ansible 0.5.0… Shall I pull y'all in a mail and we discuss there? |
|
did they give you an eta? we can probably get it done in the next few days |
|
@newswangerd @Spredzy can one of you chime in? What's the timeline requirement for your RC2 in terms of packaging? |
|
We need this, yesterday. The Tower team is entering dev freeze tomorrow, 4 November, and wanted to test that everything is working today (packages included). This includes both upstream and downstream builds. |
|
What I've realized is the repo galaxy_ng receives their bits from is hosted at To resolve this, one idea is to have a new place for the galaxy_ng bits to be hosted from that is separate from Katello's use. I believe the Ansible group needs to provide such a webserver and the build team published their bits to that location. |
|
@evgeni @chouseknecht @jlsherrill From what I can gather, it looks like we need a solution to facilitate both projects abilities to consume a specific x.y line without stepping on the other's toes. We will need to start looking into options. @bmbouter I appreciate your suggestion, but the reason this exists is to maintain a central location and infrastructure for consuming the work, helping reduce those exact duplications of effort. |
^ is what I'm advocating for. Also it's not just specific x.y of pulpcore, it could be the same x.y of pulpcore and a different x.y of a specific plugin, e.g. pulp_ansible. |
|
I'll go ahead and merge this and deal with the consequences on our side. Definitely a process we need to improve |
No description provided.