On Mon, Apr 13, 2020 at 10:53 PM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com> wrote:
On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
[...]
Why *can't* OpenShift include OpenStack projects? I haven't seen this adequately explained.
It's less of a technical issue, but more of misunderstanding that including an OpenStack project does not involve literally installing OpenStack. And no matter what we think, for a lot of people OpenStack==Nova (another marketing issue to address?).
[...]
I don't understand why that would make a difference in this case, unless you're saying that the people who make architectural decisions about what's included in OpenShift have no actual familiarity with Ironic and OpenStack. If you know anyone who works at that company, can you help them understand the difference?
This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.
I'm sure one time challenges would have been greater initially, but ongoing headaches would be less IMHO. All headaches there are a result of how people want to do their jobs and achieve/interpret goals with perceptions while trying to match that up to policy and procedural frameworks. In essence, without further delineation, it is an uphill battle that focuses on finding the string "OpenStack" and directing it to that process.
That may be true, but those problems are internal to Red Hat, aren’t they?
This particular one - yes. Sigh, I regret bringing up metal3, but I wanted an example that I'm well familiar with... It's not only about OpenShift. Please. Dmitry
On one hand, large distributions want us to have stable branches every year or two. Even what we have is too much.
On the other - we have small consumers who could benefit from just pulling the latest(ish) release and knowing that if a serous bug is found there, they won't have to update to the next feature (and potentially major) release.
[...]
This sounds like a problem shared by, well, basically every other project in OpenStack too. Perhaps it's an opportunity to collaborate on finding solutions. -- Jeremy Stanley