[
https://issues.apache.org/jira/browse/YUNIKORN-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896047#comment-17896047
]
Craig Condit commented on YUNIKORN-2962:
----------------------------------------
With regard to the ASF Code of Conduct, no violations (alleged or otherwise)
have occurred. The ASF Code of Conduct says nothing whatsoever about "requiring
open discussion" about code reverts. That said, in each case that you have made
this assertion, we have, in fact, operated by your own standard (i.e. "open
discussion"). The open discussion happened on the JIRA and GitHub PRs for the
relevant issues under discussion here.
A point of correction: there have not been "several contributions reverted"
There has also only been *one* previously-committed PR that has been
subsequently reverted: YUNIKORN-2606 (Modular sidebar with remote components),
which was reverted by YUNIKORN-2954. This JIRA was not "unilaterally reverted"
– in fact, YUNIKORN-2954 was submitted by a PMC member (myself) along with
relevant documentation as to why, and approved by [~pbacsko], another PMC
member. In between, YUNIKORN-2949 (Load external Scheduler Service using Module
Federation), which you failed to mention here, was submitted, building upon
YUNIKORN-2606 and if committed, would have wholesale replaced huge portions of
the YuniKorn Web UI without any user-visible indication that what was being
displayed on screen was not, in fact, a part of Apache YuniKorn. This was
rejected, but its submission triggered further review of YUNIKORN-2606 (the
implications of which had not yet been fully understood) and it became apparent
that this was not a direction we wanted to pursue. I opened YUNIKORN-2954 and
provided my justification {*}in the JIRA description and pull request{*}.
Nothing was done arbitrarily or in secret as you allege.
Additionally, the assertion that the "patches" (only one in fact) were reverted
by maintainers at the "same leadership level as those who approved the
patch[es] originally" is false – YUNIKORN-2606 was approved by a single
committer, and the reversion was submitted by a PMC member and approved by a
second PMC member.
The only other potential revert that is on the table is YUNIKORN-2925 (Remove
internal objects from application REST endpoint), which was created by
[~wilfreds], another PMC member. I agree with this revert as well; we don't
want to have internal objects in the REST API, nor historical information. That
is what we have built the YuniKorn event system for. [~pbacsko], who approved
the original PR, has also commented on the reversion with additional REST API
endpoints that should probably be cleaned up as well. This would seem to
indicate that he too has had a change of heart regarding the wisdom of keeping
the original PR intact. The fact is, we don't revert commits arbitrarily or
frequently, but sometimes things slip through and we need to course-correct.
Now for some less-technical points...
Project naming of G-Research History Server: Simply changing the spelling of
"yunikorn" to "unicorn" is not sufficient differentiation under U.S. Trademark
Law, as this would almost certainly run afoul of the [confusingly
similar|https://www.law.cornell.edu/wex/confusingly_similar] test. Some
possible suggestions: Use your company name (i.e. G-Research History Server), a
generic identifier (Scheduling History Server) or pick a distinct project name,
i.e. Monocerus, another mythical creature related to the unicorn. Trademark law
also allows you to reference trademarked entities in your documentation. For
example, this would be okay: "G-Research History Server is a history service
designed to integrate with the Apache YuniKorn scheduler for Kubernetes". This
makes clear that your project is independent, while also providing clarity as
to its purpose. Ultimately, it's your project – name it whatever you want
(while respecting trademark law).
Regarding the comment that "it was suggested to us that it was better [for the
history server] to be out of tree", this was discussed during the initial
proposal by G-Research of the history server during the May 1, 2024 YuniKorn
community meeting. As I recall, there were significant concerns raised about
the validity of augmenting the REST API with history information. We were by
this point well underway with designs and development of the (now mature) event
system for YuniKorn, where real-time events would be emitted to an external
consumer. A very large motivator for that design was to ensure that a future
history server (yes, you're not the first to think of one) would be able to
scale well and not bog down YuniKorn itself with non-scheduler overhead. The
G-Research approach was very much at odds with that (already agreed upon)
direction. When these concerns were raised, it was suggested that perhaps the
G-Research history server would be better done "out of tree" (as you say)
{*}due to fundamental disagreements about the technical approach used{*}. Also,
I'm fairly certain the consensus was that it would be perfectly fine for the
G-Research history server to be a completely standalone component, and that it
should probably evolve to consume the event API rather than the existing REST
API. Personally, I haven't kept up on the progress (if any) towards that end
since. At no point was it suggested during that meeting that the best way
forward would include replacing key components of the *official* YuniKorn Web
UI with components from the history server, and in fact, I believe that would
be a grave mistake.
My own concern that your changes were "geared towards permitting proprietary
extensions to YuniKorn" is misstated. My quote for context: "[The modular
sidebar] provide[s] invasive hooks for adding proprietary and/or non-standard
components to YuniKorn. It also opens up YuniKorn to potential remote code
execution vulnerabilities. This goes against our open development philosophy."
The hooks are, in fact, invasive (providing no benefit to other users),
certainly enable non-standard components, and can be used to embed proprietary
components into YuniKorn. Furthermore, the embedding is done in such a way that
it is impossible for an end-user of the combined product to see that the
G-Research provided components are not, in fact, a part of Apache YuniKorn.
This creates needless confusion and could lead to a lot of user-submitted bug
reports directed towards us about components which we have no control over.
Finally, JIRA is for issue tracking (i.e. bugs, features, documentation
updates). For future reference the appropriate forum for a discussion like this
would be the
[yunikorn-dev|https://lists.apache.org/[email protected]]
mailing list. Therefore, I will be closing this issue.
> Governance clarification: guidance requested on extending Yunikorn core
> functionality
> -------------------------------------------------------------------------------------
>
> Key: YUNIKORN-2962
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2962
> Project: Apache YuniKorn
> Issue Type: Task
> Reporter: David Gantenbein
> Priority: Major
>
> Hey,
>
> If you’re not aware, G-Research Open Source Software (GR-OSS), has been
> working in and around the YuniKorn ecosystem for the last several months.
> We’ve actively contributed a number of enhancements to the project, along
> with several features related to our need for a persistent record of YuniKorn
> events merged[0][1][2].
>
> However, recently many of our contributions to Apache YuniKorn appear to have
> been reverted unilaterally with minimal explanation. It’s unclear to us where
> the open discussion about this removal, as required by the ASF Code of
> Conduct, occurred for this – we’re interested and would like to participate
> in those technical discussions in the future. We’ve tried to glean the
> primary points of contention here:
>
> First, our choice of name for the (formerly) YuniKorn-history-server project
> was unwise given YuniKorn is a trademark of the Apache Software Foundation
> (ASF). We’ve rectified this issue by renaming the project to
> unicorn-history-server. The original name was driven by our hope that
> unicorn-history-server may one day find its home as an official part of the
> YuniKorn. We hope our swift resolution of this concern is evidence of our
> commitment to the same open philosophies held by the ASF.
>
> Next, Craig Condit stated a concern[3] that our changes were geared towards
> permitting proprietary extensions to YuniKorn. GR-OSS is an open source
> policy office that does not write any proprietary code as part of our
> mission. In fact, the unicorn-history-server is Apache 2.0 licensed, just
> like YuniKorn. Our team made extensive efforts to devise the most minimally
> intrusive changes possible after it was suggested to us that it was better to
> be out of tree – we’d be thrilled if the solution to this problem would be
> the unicorn-history-server being adopted as part of yunikorn-core; in lieu of
> this, keeping a plugin mechanism is a base-level requirement for the
> unicorn-history-server to function. We hope that our reputation as good
> upstream citizens and operators can help you understand that we have no
> hidden agendas – we aren’t even a product company.
>
> Finally, it was suggested[4] that the getApplication API endpoint was
> inappropriate due to its exposure of internal YuniKorn data structures. We’re
> open to feedback regarding this feature and how to improve it, but again,
> we’re confused as to where these discussions are happening and how to get
> involved in them. In the original proposal of this feature[5], we added tests
> and modified the implementation at the request of project maintainers – it’s
> upsetting to have all that work and cooperation discarded without even a
> conversation.
>
> Our desire is to remain a part of the YuniKorn community, but we’re very
> confused about the governance and technical design process for the project –
> according to [https://yunikorn.apache.org/community/people/], the maintainers
> reverting our patches are at the same leadership level as those who approved
> the patches originally. Can we get some clarity on the reasoning for
> reverting the patches and documentation of the open community collaboration,
> as required by the ASF Code of Conduct, that precipitated this removal – this
> appeared to have been mentioned in the October 30th meeting[6], but this date
> is after the revert of the patches, so we assume there must have been another
> discussion.
>
> If there’s anything further we need to do in order to spawn the technical
> dialogue needed to address your concerns with unicorn-history-server and the
> supporting elements, please let us know. Our desire is to implement something
> in an open way that meets not only the needs of G-Research, but also those of
> the overall YuniKorn community.
>
> Thanks for your time,
> Rich Scott, Open Source Developer
> Denis Coric, Open Source Developer
> Jay Faulkner, Open Source Developer
> Dave Gantenbein, Director of Software Development
> Alexander Scammon, Head of Open Source Development
> G-Research Open Source Software
>
> 0: https://issues.apache.org/jira/browse/YUNIKORN-2606
> 1: https://issues.apache.org/jira/browse/YUNIKORN-2652
> 2: [http://tiny.cc/ag5tzz]
> 3: https://issues.apache.org/jira/browse/YUNIKORN-2954
> 4: https://issues.apache.org/jira/browse/YUNIKORN-2925
> 5: [https://github.com/apache/yunikorn-core/pull/897]
> 6: [Apache YuniKorn Community Sync
> Up|https://docs.google.com/document/d/165gzC7uhcKc5XDWiMYSRKBiPQBy2tDtXADUPuhGlUa0/edit?tab=t.0#heading=h.6wgz1xgh0qde]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
