Open Stack

On 2022-06-22 10:12:16 +0200 (+0200), Artem Goncharov wrote:
[...]
> I went multiple times through explaining “change” model to both
> experienced and unexperienced people and is usually painful.

And you also have less trouble explaining the convoluted GitHub
"pull request" workflow to someone who has never heard of Git or
GitHub?

> In the Outreachy we also have same practice each time and this is
> for people just harder to understand (I see project on GitHub, why
> can’t I open PR here like I would do for every other project on
> GitHub).
[...]

OpenStack does its best in the org and repo descriptions on GitHub
to highlight that they're convenience mirrors, and to point to the
community's accepted workflows. Does that get overlooked? Is there
something better that could be done to make it clear?

> BTW, are we absolutely and unbendable strict on using change
> methodology vs pull? I mean would there be conceptual disagreement
> on using PR approach on opendev.org <http://opendev.org/> with
> purely gitea for those “ecosystem” tools? The process (and UI)
> feels exactly like GitHub and I guess we could cover lot of
> concerns. I know we currently do not have Zuul support for gitea
> API, but I would be willing to contribute to that once this is an
> option at all. My experience show that when there is huge
> conceptual barrier it is possible to guide people through by
> moving them slowly into this direction and showing them advantages
> while going forward (first move them from GH to opendev keeping PR
> style, then once people see limitations of PR model show how
> “change” model addresses those concerns) - doing small steps.
[...]

I think supporting multiple commit workflows and code review tools
within the OpenDev Collaboratory would be even more confusing and
add further conceptual barrier (what do you mean to commit to
OpenStackSDK I need to use a different set of tools and review
process than gophercloud, even though they're both in OpenDev?).

But from a technical feasibility standpoint, it's also more than
just the lack of a Gitea driver for Zuul: our current Gitea server
farm is read-only for technical reasons including lack of support in
Gitea for a shared writeable storage backend, the fact that we would
need to set up separate authentication/account management (we still
need help from more people to make progress on our Keycloak SSO
deployment), not to mention it would effectively double the security
risk profile.

> I agree we need to support making landscape flexible. But I am not
> 100% sure we should currently (due to general lack of
> contributions) simply refuse those willing to contribute into
> OpenStack . Terraform is a very prominent example here as well -
> you must be on GitHub to publish your artefacts. Don’t we want to
> have official TF provider following our best practices (therefore
> this is not an infrastructure only question)?
[...]

Is a source code mirror on GitHub not sufficiently "on GitHub" from
Terraform's perspective?

> we may explore publishing to GitHub mirror releases while still
> doing development on gitea. That requires having GH app token
> though (that is actually where those Vault plugins are being
> useful - you just fetch the token from vault and it expires
> afterwards).
[...]

OpenStack's GitHub mirroring relies on a Zuul job with account
credentials for the openstack org encoded as a secret in the job
definition, and other projects do similarly for mirrors to their
respective orgs as well. Performing other API interactions in jobs
is similarly possible, so telling GitHub to make a "release" of
something there would probably be a trivial addition.

> I would rather disagree with such statement: just because you host
> your code on a proprietary hosting (but make it freely available)
> does not mean your are violating this mission. I also believe we
> should be using open source tools (and we do that), but that
> doesn’t mean everyone else is breaking bad [not meant to be
> abusive statement].

You're spending your valuable time producing open source software,
so you must see some value in your choice to make it open source and
would rather users picked it over proprietary alternatives. I
personally would feel rather hypocritical were I to claim that open
source development is a good thing when it's the software I'm
creating, but that I don't find the open source alternatives to
proprietary code hosting and development tools similarly valuable
and would rather choose what's convenient or popular instead. How
can I expect the communities producing those tools to make traction
against proprietary platforms if I choose to be part of that problem
rather than part of the solution? I feel similarly disheartened when
I attend an open source software conference and see someone give a
presentation extolling the virtues of these practices, while clearly
running their slide deck from MacOS or Windows.

> Generally we have again here the same “infra” concerns in the
> discussion (which are already known historically, but anyway
> thanks for making them clear again), but what about other
> opinions? Are there any other thoughts or am I the only one
> interested to get this sorted out?

If I can try to restate your request, it seems like you want to
develop software using some different tool choices than those
available in the OpenDev Collaboratory. All the software we run in
OpenDev (and all the software we use to develop and maintain the
services and deployment in OpenDev) is 100% open source, along with
its configuration. If you want to run a different combination of
those services for your community while reusing some of OpenDev's
solutions, you absolutely can do that and a number of people do so
already.

> Just to repeat, my current case is really about a very strong
> desire and, I would say even need, to have gophercloud be very
> close to OpenStackSDK. Can we at least think about placing them
> under OpenStack GitHub org without Zuul access to have a better
> affiliation with OpenStack (gopher folks, hope you do not mind of
> such step. Or maybe we try to demonstrate here how to make this
> manageable with Zuul - reach me out if there is interest)?
[...]

I'm probably still misunderstanding what you mean by "very close to"
in this statement. If the most important aspect of this is that
gophercloud appears in the openstack org on GitHub, but you don't
wish to actually use the development methodology and code review
workflow of the OpenStack community, then that doesn't seem close at
all. But maybe you mean "close" from a marketing perspective?
Mirrors to GitHub are not something OpenDev sysadmins really even
get involved with, it's just automation individual projects implement
and maintain for themselves, so it's the OpenStack TC's choice as to
what projects they'll allow to appear in their GitHub org, and
really nothing to do with the OpenDev Collaboratory itself.

And one thing I still don't feel like you've covered is your earlier
assertion that gophercloud project leadership was told the OpenInfra
Foundation refused to legally represent them unless they hosted
their development in the OpenDev Collaboratory. As I mentioned in my
earlier reply, there are already OpenInfra projects which do all
their software development in GitHub and run their own CI systems
completely separate from OpenDev, so I really doubt you've been
given an accurate account of what was discussed between foundation
leadership and gophercloud folks. It would probably be good to seek
further clarification there.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220622/19583726/attachment-0001.sig>