Eiffel Summit 2021 takeaways

###### tags: `Summit 2021.1` # Eiffel Summit 2021 takeaways To be filled in during and after the summit ## Facts - About 35-45 participants on all sessions :) - 55 persons registered on the [self sign in document](https://docs.google.com/document/d/14cWpihcB-Cv0DLkat3-bigJQJOWBf_5ou158BGbEHFM/edit#) - Not too many companies represented though ## Areas to improve - Did we get any improvement areas from the poll? - See the answers at https://docs.google.com/forms/d/1jGZyMAyHVYNedHAcY98YV_nMB6qECpYsptL0w_3Z-gI/edit#responses - Answers in Markdown https://hackmd.io/6EK7rwLdQpyxLKqBiU74Yw - We forgot to invite - Software Center - Linköping University - Promote the summit on LinkedIn ## Proposed topics for future monthly meetings - SDKs - Visualizations - Event repositories - Protocol workshop - Source changes - Break out structs, such as meta object Should we set up a document that everyone in the community could add their wanted topics? Google document? ## Session recap - How do we take care of all discussion topics brought up on the summit? Write down each of them as issues and discuss them in TC/monthly meetings? - Where there any comments in the chat worth keeping or working on? ### General takeaways - Not many topics came to final conclusions, so almost all of them could be worth coming back to in coming summits or monthly meetings - Only 3 out of 5 TC members participated (Tobias was sick and David was absent). Better luck next time :) - Not too many questions and actions from the first days topics. Probably as they were more presentation types than discussion type topics. - Time consuming to capture and make sure things are followed up after the summit. Could we make that easier next time? Dedicating someone to lurk the meetings and take notes but not participating too much, or to make it easier for everyone to continuously share thoughts and takeaways during the conference? Through some web form rather than everyone writing in the same HackMD document? ### What is Eiffel and why? No questions, no action ### Getting started No questions, no action ### The Eiffel landscape - Question: Some questions for clarifications, on Eiffel Intelligence for example - Action: No direct action, but for coming presentations on the landscape: Complement presentation based on the questions recieved ### Changes in the Paris and Lyon editions of the protocol - Q: Where do the protocol names come from? - Q: Will domain id be removed from meta.source? - Q: Did the glossary change in Paris? No but it was added then. - A: No direct action, but for coming presentations in this area: Complement presentation based on the questions recieved ### Technical Committee updates No questions, no action ### Maintainer role - Q: Quite some questions and discussions - A: TC: Discuss the proposition, enhance it, enforce it - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### New routing key standard No questions, no action ### What's cooking in the community? - GitHub actions - A TC: Consider GitHub actions as a recommendation for all repos? Leverage on Nordix for that? - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### What's cooking in the community? - Eiffel visualizations at Axis Two different visualizations presented - Eiffel Eye (for event debugging) and Follow-my-commit (for end-users) - Q: Can it show events sent within activities? Yes, if they are linked correctly - Q: Are there any ideas for additional/custom schema rules on top of the protocol, to enable e.g. Follow-my-commit? No solution exists yet. - Q: Is there a tool in the community to show the whole chain of event up- och downstream from an event? Eiffel Vici is there, but it aggregates events. - A: How to collaborate on event graph visualization? (Axis solution: Eiffel Eye, dependent on eiffel-goer) - Solved 2022-01-04: Part of TC agenda for 2022-01-13 - A: How to collaborate on Follow-my-commit? Make it a topic in a monthly community meeting? - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### What's cooking in the community? - Exposing logs from ancillary activities - Q: What kind of logs? Any log collected in an ancillary service - Q: Are the actual logs stored in Elasticsearch? Yes, one document in ES per log entry. - Q: What about access rules or authorization? All log entries might not be allowed to be accessed by anyone, is that considered? Yes, different domains (accessed through different url parts) in the log store could have different access rules - Q: Access rules through e.g. logging in to Follow-my-commit and just getting access to the relevant logs through that user? Maybe, or if you have access to Follow-my-commit you should have access to all logs as well. - Q: Do you also use Kibana to visualize logs and other data? Yes, Kibana and Grafana. - No actions defined ### Eiffel vs CDF SIG Events - Q: All source code changes are not done through PRs. Is that accounted for? No, there is no event yet for direct merge to master. - Q: Why is a less generic representation chosen (Pipeline/Task/Build)? More concrete activities is desired to represent. Not yet discussed through enough. - Q: What are the chances for this protocol to become big? As long as relevant people/organizations are involved it could be big. - Q: Have there been thoughts on migration from Eiffel to CD Events? No plans yet, but it is our intention to get there. - Q: What about the lack of links? Discussions are ongoing. There seems to be interest in something similar to the Eiffel links. Links will maybe be optional in CD Events. - Q: How would the context be materialized in the events? Similar to e.g. flow context in Eiffel. We should show more complex pipelines to CDF to show the benefit/needs of links between events. - A: We have some work to do to align the new protocol with Eiffel, revealed by the questions above. - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### eiffel-broadcaster Jenkins plugin - A: How to show existing Eiffel repos not in the eiffel community org in github, like this Jenkins plug-in for example? What about maintenance roles? - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### Event SDKs - Q: Should old editions be deprecated? And should old event versions be removed from the Github source tree then? - Q: Should protocol releases always include updated SDKs? - Q: Many other questions on different aspects of SDKs - A: Plan for a monthly meeting on SDKs - Solved 2021-12-09 through the [monthly meeting on SDKs](https://hackmd.io/aEpAat1iQgmM4C0RmNmiCg) ### Accessing an event repository - Q: What areas should be looked into when improving eiffel-goer, with experience taken from Eiffel Event Repository? - Querying for events with in a large ER sometimes takes a lot of time - Some discussions on performance and characteristics of databases - Security - Authenticating and authorizing - Master thesis output: https://github.com/eiffel-community/eiffel-persistence-technology-evaluation - A: We should join forces over the whole community to create a good event repository. Topic for a monthly meeting? - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### Discussion: Event type categorization - Q: Do we need to categorize event types? - It's probably a question on scale, and if domains are used or not. In large scale setups with multiple domains, the event families is a convenient way to set up message federation. - It's probably context dependent. Depending on the use case there could be different needs for categorization. - It relates also to this issue: https://github.com/eiffel-community/eiffel-remrem-semantics/issues/140 - This could be a topic for a coming monthly meeting - A lot of good discussions. To be kept for future reference on this topic - A: TC - How to follow up this topic? - Solved 2022-01-04: Part of TC agenda for 2022-01-13 ### Discussion: Source code events - Reasoning on why a full commit DAG in Eiffel is needed - Reasoning on what is lacking in the current Eiffel events (SCC & SCS) - https://github.com/eiffel-community/eiffel/issues/261 - A lot of good discussions. To be kept for future reference on this topic - A: We need to be aligned with CD Events on this before introducing this change - We need to make sure that CD Events does not go in the wrong direction here. Focusing on underlying Git structure or on the user facing parts of it (through a selection of SCM systems) - We could show the same picture as used here to SIG Events, as it is not at all tied to Eiffel currently - Sven volunteered to present this to SIG Events - Thought from Emil: The actual PR (or MR or Gerrit change) *object* is not represented in this suggestion. Only PRs referencing commits. Shouldn't it be the other way around? I.e. a commit that is pushed to SCM should reference a PR. In that way a PR/MR/Change event would only contain the immutable references to the SCM system, without any information about that commits are tied to it. Then each commit, when pushed, is tied to an existing (or new) PR/MR/Change event object. - What about Git Submodules, how should they be represented? - Could EiffelAnnouncementEvent be used instead? It's probably better to have more specific events, instead of using a such generic event for multiple purposes. - A: Provide some additional examples in the issue - We should request examples based on valid use cases - For example the merge strategies (fast forward, etc) - Actions should be considered in coming community meeting on Feb 3rd ### Discussion: Using Eiffel to implement event-triggered pipelines - Issue: How to monitor a network of pipelines (pipeline of pipelines) and retrigger failing pipelines for example - One option is to have a central orchestrator, or set up "orchestration domains" - A lot of good discussions. To be kept for future reference on this topic - No specific follow-up questions put. ### Discussion: Extracting common structures - A lot of good discussions. To be kept for future reference on this topic - Could some of the complexity be handled in,the SDKs instead of in the joint schemas? How to define such rules in a way that all SDKs would adhere to them? Through a new layer of overall event structure rules from which all schemas and some SDK parts are generated? - A: Review the meta PR - A: Relate the meta extraction to SIG Events Cloudevents top layer - A: Should the extracted objects be versioned or not? Probably yes? Should a consumer need to know about individual extracted object versions, or should it always be referenced from a specific event version? Should the event reference a versioned extracted type or just the type generically? - Related: If the Cloudevents spec has a new release, would all events need to be updated? I.e. what is the chicken and what is the egg? - How to deal with versioning of the cloudevents spec vs the individual event versions? - The meta object is kind of special, compared to other objects in the events. All other objects are "sub" to the event type, but meta is kind of "super" to it, so should it really be treated the same way? - Q: Should the guinea pig be the "meta" object or instead some other object, like gitIdentifier or logs object? - If it works for meta it works for everything else, so it makes sense to start there. - Actions should be considered in a coming community meeting (not planned yet)