On Tue, 2020-04-14 at 11:47 +0200, Dmitry Tantsur wrote:
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.
kayobe is perhaps an example although the fact it used a biforst deployed ironic to provision hardware for use with kolla-ansible to build a cloud slightly complicate that example. https://docs.openstack.org/kayobe/latest/ kayobe's use of bifrost/ironic is as a barematal host provider, it then treats openstack as an application that is deployed on those hosts. if it was useful to them to provision spark or k8s on those host instead i am sure they would jsut swap out kolla-ansible for another deployment tool to deploy there workload. this is effectivly how i would expect standalone ironic to be used most often. to prepare physical host with a base OS that is then manage by another tools that only/predomently deals with the software confituretion without having to worry about how the hardware was intially bootstraped. in that useage model none of the other openstack compnents are required although it may be useful to still have keystone and swift for auth and image storage althouth tftp works equally well in a static deployment.
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