cylc / cylc-admin Goto Github PK

Project planning for the Cylc Workflow Engine.

Home Page: https://cylc.github.io/cylc-admin/

License: GNU General Public License v3.0

cylc

cylc-admin's Introduction

Cylc (pronounced silk) is a general purpose workflow engine that also manages cycling systems very efficiently. It is used in production weather, climate, and environmental forecasting on HPC, but is not specialized to those domains.

Quick Start

Installation | Documentation

# install cylc
conda install cylc-flow

# extract an example to run
cylc get-resources examples/integer-cycling

# install and run it
cylc vip integer-cycling  # vip = validate, install and play

# watch it run
cylc tui integer-cycling

The Cylc Ecosystem

cylc-flow - The core Cylc Scheduler for defining and running workflows.
cylc-uiserver - The web-based Cylc graphical user interface for monitoring and controlling workflows.
cylc-rose - Provides integration with Rose.

Migrating From Cylc 7

Migration Guide | Migration Support

Cylc 8 can run most Cylc 7 workflows in compatibility mode with little to no changes, go through the migration guide for more details.

Quick summary of major changes:

Python 2 -> 3.
Internal communications converted from HTTPS to ZMQ (TCP).
PyGTK GUIs replaced by:
- Terminal user interface (TUI) included in cylc-flow.
- Web user interface provided by the cylc-uiserver package.
A new scheduling algorithm with support for branched workflows.
Command line changes:
- cylc run <id> -> cylc play <id>
- cylc restart <id> -> cylc play <id>
- rose suite-run -> cylc install; cylc play <id>
The core package containing Cylc scheduler program has been renamed cylc-flow.
Cylc review has been removed, the Cylc 7 version remains Cylc 8 compatible.

Citations & Publications

Copyright and Terms of Use

Cylc is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Cylc is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with Cylc. If not, see GNU licenses.

Contributing

Contributions welcome:

Read the contributing page.
Development setup instructions are in the developer docs.
Involved change proposals can be found in the admin pages.
Touch base in the developers chat.

This repository contains some code that was generated by GitHub Copilot.

cylc-admin's People

Contributors

Stargazers

Watchers

Forkers

hjoliver oliver-sanders kinow sadielbartholomew dwsutherland wxtim gaybro8777 dpmatthews datamel metronnie jarich thecompetenza markgrahamdawson

cylc-admin's Issues

cylc/cylc-uiserver

profiling: profile the UIS against the "complex" workflow

It would be good to profile the UI Server against the "complex" workflow running with something like a 1-5 second sleep for a few cycles to give us a good benchmark for expected resource usage.

Suggested experiment:

Create an environment with no other Jupyter Server extensions (including Jupyter Lab).
- So we are profiling Cylc, the whole Cylc and nothing but the Cylc.
Clear your cylc-run directory (including stopped workflows).
- So we are only measuring the impact of the one workflow.
Profile the cylc gui command.
- This will give us a memory watermark for an idle UIS.
- Profile the default landing page (i.e. the Dashboard).
Run the "complex" workflow (located in the Cylc 7 source code under etc/dev-suites).
- I would pick a 1-5 second sleep (whatever works best for your platform, note the value you choose).
- Start it --paused.
- Set the final cycle point to a few cycles in the future (note the value you use).
- Suggest profiling the workflow too so we can compare the memory fluctuation of the two side-by-side.
Profile the cylc gui command.
- Open a tree view on the "complex" workflow.
- Unpause the workflow.
- Let the workflow run to completion, give it a few seconds, then end the experiment.

Suggest using Memory Profiler on both the workflow and UIS and generating memory usage graphs for both. CPU usage is also of interest.

Add pre-commit hooks to prevent issues with build tools earlier

Suggested by @sgaist (thanks!). We have pull requests where contributors may spend a long time trying to fix the build (especially around things like 80 characters-lines, and simple unit tests).

It is simply impossible to wait for the functional tests, or even the unit tests I think, as you wouldn't want to wait 1 minute for a git commit ... to finish. So the hook must be kept as simple as possible.

Example of hooks from other projects:

JupyterHub
- https://github.com/jupyterhub/jupyterhub/blob/master/.pre-commit-config.yaml
  - order imports (some IDE's, linters, and other tools try to keep them in order)
  - checks the extra line in the file
  - checks that executables have shebangs
  - run flake8
  - etc
Tornado
- https://github.com/pandas-dev/pandas/blob/master/.pre-commit-config.yaml
  - also runs flake8, black
  - sorts imports
SQLAlchemy
- https://github.com/sqlalchemy/sqlalchemy/blob/master/.pre-commit-config.yaml
  - Just blacks and a custom zimports script

This also means that users contributing to the project are not able to commit without a working environment (well, there's always --no-verify I guess). For JupyterHub, last time I tried to commit something there, it raised an error and asked me to activate my virtualenvironment if I remember well 👍

EDIT: list of projects that would need the pre-commit hooks added:

Packaging end-game.

For cylc-8, the cylc-flow workflow service can now be installed as a Python package using pip (library plus CLI scripts).

In due course we need to consider, test, and document how to install cylc-8 (all components) by other packaging systems too (noting that pip is only for Python packages):

conda
Linux system package managers: yum, apt, ...
Docker (and HPC containers: singularity, ...)
other?

Cylc Rose Release 1.1.1

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
Test cylc-doc (run a test build, perform any required fixes).
List the milestones for release below (delete entries as appropriate).

Milestones for release:

The release actions close the milestones for you automatically.

cylc-rose: https://github.com/cylc/cylc-rose/milestones/1.1.1

PyPi / GitHub releases:

Trigger releases via GitHub actions.

Forge (check dependencies match):

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.
It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-rose (pin to latest cylc-flow)

Finally:

close this issue 🚀

Relase 8.1.1

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
All bugfix branches should be merged into master.
Ensure major changes are listed in cylc-doc (reference/changes).
Test cylc-doc (run a test build, perform any required fixes).
Run cylc-flow functional tests against locally available platforms.
List the milestones for release below (delete entries as appropriate).

Milestones for release:

The release actions close the milestones for you automatically.

metomi-isodatetime:
cylc-flow:
cylc-ui:
cylc-uiserver:
metomi/rose:
cylc-rose:
cylc-doc:

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.
(logical release order)
R1 = """
   cylc_flow & metomi_rose => cylc_rose
   cylc_flow & cylc_ui => cylc_uis
"""

Info on version pinning

Cylc plugins (i.e. cylc-rose and cylc-uiserver) are "pinned" to the minor version of cylc-flow. E.G. if the cylc-flow version is 8.1.2 the plugins should be pinned to 8.1.

More Information

metomi-isodatetime
cylc-flow (bump metomi-isodatetime if required)
cylc-ui
cylc-uiserver ([update the ui via GH action first)
metomi-rose (bump metomi-isodatetime if required)
cylc-rose

Forge (check dependencies match):

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If the PR doesn't get opened automatically

Create a new branch, change the version, reset the build number and update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump intersphinx versions if required (cylc-doc/src/conf.py)
- review deployment instructions
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
metomi-rose
- build & deploy documentation (manual process ATM)
discourse post

Metadata:

GH Actions should automatically open PRs that bump the dev version of the projects. Check and merge them (can push alterations to PR branch if needed).

Pin downstream components to the next cylc-flow dev release:

cylc-uiserver (pin cylc-flow to next upcoming version)
cylc-rose (pin cylc-flow to next upcoming version)

Pin components in GH Actions tests:

cylc-doc (update versions in .github/workflows/test.yml "install libs to document" step(s) as appropriate)
metomi-rose (update versions in .github/actions/install-libs as appropriate)

Finally:

close this issue 🚀

Consistent reporting of tracebacks

We need to agree when tracebacks should be reported and then implement the agreed approach across the codebase.

Proposal:

in debug mode always print a traceback
in production mode only print a traceback for errors not specifically handled (then users can help us debug unexpected errors)

For an example of inconsistency, create a workflow with a space after a continuation line. cylc validate just returns an error message but cylc run reports a traceback as well.

cylc server monitor

Writing this up here as it's uncertain where this code would live.

At the Met Office we have a pool of 12 16 servers which suites can run on. To help us keep track of the health of these servers and the usage of Cylc on them we wrote a tool which provides a web dashboard with:

Plots of the number of running suites, server load, memory usage and CPU for the suite servers.
Plot of the number of suites running under each Cylc version.
Graph of the number of running suites and active users.
Listing of all suites running on the suite servers with info such as run time and memory usage.
Listing of all processes running on the suite servers which aren't Cylc processes.

This is important functionality for larger sites, there are lots of ways in which is can be improved (e.g. daily job counts).

This code is written in Python2.6 and has to run in a bare environment so is kinda ugly and not especially portable. It needs a re-write!

We should be able to re-implement this functionality within the Cylc UI/UI-Server infrastructure to provide an admin dashboard. That way this functionality would ship with Cylc and be available to all.

This would involve the creation of a dashboard for Cylc admins (we could make it accessible to all users), it would require an always-running UI Server running under a specified account, which, depending on site specifics may require certain privileges to be effective. It will need to maintain a database, sqlite3 is more than sufficient.

Infrastructure aside the actual code component is pretty simple:

The current implementation is a few thousand lines of code, with modern Python and packaging a direct re-implementation could be much lighter.
Server info can come from psutils.
Suite listings can come from the UI Server suite discovery service.
The rest is data management and plotting.

Infrastructure wise:

The server side component of this code could live in:
- The UI Server
- Another repo which provides plugin extensions to the UI Server.
The UI component of the code could live in:
- The UI
  - Would inflate dependencies but thanks to webpack this wouldn't impact load times.
- Another Vue project.

Tools for conda feedstock dependency updates?

The 8.0rc3 release has shown it is too easy to forget to update dependencies on the conda-forge feedstock repos. If we could help automate it, either looking for a pre-existing tool or creating some kind of GH Actions workflow that can cross-reference setup.cfg and the recipe/meta.yaml to make sure the dependencies match

Dead-ended Cylc conda packages

There are two cylc conda packages that we stopped publishing at older versions.

the "cylc" meta-package

We abandoned this after 8.0b1, so if a user (quite reasonably) types conda install cylc they will get ancient development releases of our components.

blargh $ conda search cylc
Loading channels: done
# Name                       Version           Build  Channel             
cylc                           8.0a1          py37_0  conda-forge         
cylc                           8.0a1  py37hc8dfbb8_1  conda-forge         
cylc                           8.0a1          py38_1  conda-forge         
cylc                           8.0a2  py37hc8dfbb8_0  conda-forge         
cylc                           8.0a2  py37hc8dfbb8_1  conda-forge         
cylc                           8.0a2  py37hc8dfbb8_2  conda-forge         
cylc                           8.0a2  py38h32f6830_0  conda-forge         
cylc                           8.0a2  py38h32f6830_1  conda-forge         
cylc                           8.0a2  py38h32f6830_2  conda-forge         
cylc                           8.0b0  py37h89c1867_0  conda-forge         
cylc                           8.0b0  py38h578d9bd_0  conda-forge         
cylc                           8.0b1  py37h89c1867_0  conda-forge         
cylc                           8.0b1  py38h578d9bd_0  conda-forge

cylc-ui

We stopped publishing this as a separate conda package after 8.0rc1. In the 23 May Cylc meeting, no one present could remember if this was a deliberate decision or not. We don't need it as a separate package (it is bundled with cylc-uiserver), but older versions were published so we should do something to indicate they should not be user.

blargh $ conda search cylc-ui
Loading channels: done
# Name                       Version           Build  Channel             
cylc-ui                          0.1               0  conda-forge         
cylc-ui                          0.1               1  conda-forge         
cylc-ui                          0.1               2  conda-forge         
cylc-ui                          0.2               0  conda-forge         
cylc-ui                          0.2               1  conda-forge         
cylc-ui                        0.3.0      ha770c72_0  conda-forge         
cylc-ui                        0.4.0      ha770c72_0  conda-forge         
cylc-ui                        0.5.0      ha770c72_0  conda-forge         
cylc-ui                        1.0.0      ha770c72_0  conda-forge

Create Cylc Wikipedia article

Hi,

When searching for Cylc on search engines, some of the top results (with privacy filters) include Cylc links. But Google and other search engines give Wikipedia articles a high rank in the result hits.

Other tools such as Emacs, PBS, SLURM, have already pages. And when searching for some terms, Google - for instance - will display extra information retrieved from Wikipedia.

I started a draft for Cylc some time ago, and had another go at it now over these long holidays: https://en.wikipedia.org/wiki/User:Brunodepaulak/sandbox. It's normal to use a sandbox when preparing a new page. If we decide to go ahead with it, myself or somebody else would have to submit it to review/approval, before it gets published.

After that, searching for Cylc should bring our results with a slight advantage. Plus, personally I like Wikipedia articles for its flatness, so that I can check information about a project without having to dig into its website (guess that was the idea of DOAP).

Cheers
Bruno

meta packages

closes: #76, #27, #75, cylc/cylc-flow#4158

Open proposal to discuss the packaging-end-game for Cylc 8.

Doesn't really need a full-blown proposal-document, there isn't any fine print to haggle over.

cylc => cylc-flow

Early in the Cylc 8 project we renamed cylc => cylc-flow, some of the motivation:

We were considering having a stripped-down cylc-flow package which just had client/message functionality for use on job hosts.
We wanted the cylc namespace for the meta-package.
We considered separating the library and application layers of Cylc.
Cylc Flow sounded cool.

In retrospect this might not have been the best idea:

The client/message only package never materialised.
All of the cylc-* projects have cylc-flow as a dependency making cylc-flow the "core" component.
- Note: The cylc command is provided by cylc-flow other cylc projects register their subcommands via entry points.
Separating the library and application would be a lot of work for no gain (especially given the previous point).
We are less convinced by the role of the meta package than we were.

The meta-package

The intention of the meta package was to provide a one-click install for a fully-functional Cylc stack.

# i.e. this:
$ conda install cylc

# does the same as this:
$ conda install cylc-flow cylc-uiserver cylc-rose metomi-rose

Advantages:

The versions of each component get "pinned" in the meta-package ensuring environment consistency.
- However, we don't actually need a meta-package to enforce this consistency (1).
- For example cylc-rose has both metomi-rose and cylc-flow as dependencies.
- This means that if you install cylc-rose your package manager (pip, conda) will ensure the two are compatible.
Ease of installation.
- Seemed like a good idea at the time, however, environments may have lots of variables.
- What bits of the system do they want installed in which places?
- What if they want to set the version of Python? Wouldn't we want to fix that in the meta-package?
- What if they want (or don't want) optional Cylc dependencies (e.g. Pandas used for cylc-report-timings)?
- What if they want to install the UI Server with the optional "hub" dependency.
- What if they want to install the Hub without the "configurable-http-proxy".
- Handling the matrix of "Cylc packages", "Cylc package installation options", "Cylc package dependency installation options" gets really, really messy.

Disadvantages:

We can't "deselect" packages to install (with conda, pypi is different).
- With Conda you can have multiple outputs, however, these aren't like optional-dependencies in PyPi.
- They are more like top-level projects. E.G. both cPython and PyPy produce the python output.
- So at the moment if you conda install cylc you get the whole lot whether you wanted it or not.
- To get around this we would need special meta outputs e.g. cylc-meta-flow, cylc-meta-uiserver, etc.
Differing versions between cylc and cylc-flow.
- We would expect the meta-package version to start out as the cylc-flow version?
- If we want to make a maintenance release for cylc-uiserver we would need to bump the meta-package maintenance version?
- So the meta-package and cylc-flow versions can mismatch.
- Unless we mandate that there is a cylc-flow maintenance version for each meta maintenance release?
- Otherwise cylc version shows the version of cylc-flow not the meta package which is confusing if you installed via the meta package.
- Where does the meta-package version get shown?

And so the meta-package has begun to look like a [complex] solution in need of a problem.

We would probably be better off adding a few example Conda recipes in cylc-doc and letting users decide how they want to install the stack.

The Future

Consistency

Currently all Cylc projects have a dependency on Cylc Flow.

We can give this dependency a very narrow version range (version "pinning") in order to ensure consistency between the different components.

Terminology: <major>.<minor>.<maintenance>

Packages

There should be one-- and preferably only one --obvious way to do it.

If the meta-package serves little function we should probably cut our losses and get rid of it.

Doing so would leave us with three problems:

The cylc Conda package.
- Currently provides cylc-flow, cylc-rose, cylc-uiserver, metomi-rose.
The cylc PyPi package.
- Currently provides cylc-flow 8.0a0 and nothing else.
The slightly-confusing cylc-flow project name.
- Just seems a bit odd considering that it is the core component of the system.

Options:

We could delete the cylc packages (makes us vulnerable to typo-squatting)
We could make them dead-end packages (i.e. if you try to install them you get an error telling you not to install them).
- I think you can do this on PyPi.
- I have asked the conda-forge people, so far they have said that typosquatting protection comes from the review process...
- ... This is fair, however, would this happen in practice?
We could retire the cylc-flow packages and use these instead.

Related: Should we claim the namespace cycl (and possibly clyc?) since it is such a common typo on pypi/conda-forge.

I think:

If we were to rename cylc-flow back to cylc (lots of work, no gain) then (3).
Otherwise (2)

Proposal

Ok, enough background, the actual proposal is quite simple:

Consistency

Make Cylc projects depend on minor releases of cylc-flow.

Examples:
- cylc-uiserver==1.1.0 might depend on cylc-flow=8.0.* NOT cylc-flow>=8.0.0.
- cylc-rose==1.1.1 might depend on cylc-flow>=8.0.1,<8.1 NOT cylc-flow>=8.0.0.
This means all [core] Cylc packages would have to be released for every minor release of cylc-flow.

I think this is probably the sort of direction we were heading in anyway. We could potentially relax this later on (to the major version) if interfaces settle down.
Namespace

Go for option (2), we don't need a special meta-package, try to make the existing cylc packages "dead-ends".
WIP

Close:
- cylc/cylc-flow#4158
- cylc/cylc-doc#234

Thoughts @cylc/core?

release: 8.0rc1

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Milestones for release

cylc-flow:
cylc-uiserver:
cylc-ui:
cylc-rose:
metomi/rose:
cylc-doc:

Required for all minor releases of cylc-flow.

Se the release docs
for first time instructions and more info.

Prep:

Ensure all milestones complete.
Test cylc-doc (run a test build, perform any required fixes).
Delete entries below for packages you are not releasing.

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.

Forge (check dependencies match):

noarch: python changes:

cylc-flow (released as new 8.0b3 build)
cylc-uiserver
cylc-rose
metomi-rose (cannot be done before 2.0rc1 release)

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If not, create a new branch, change the version, reset the build number and
update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

cylc-flow
cylc-uiserver
metomi-rose
cylc-rose Do not release 1.0.0, only release 1.0.1

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump instersphinx versions if required
- review installation instructions - cylc/cylc-doc#408
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
rose: build & deploy docs
discourse post
- This time around we need to include a note to tell beta users the uiserver config path has changed from hub/ to uiserver/.
- https://cylc.discourse.group/t/cylc-8-0rc1-released/435
cylc/cylc-uiserver#303

Metadata:

Update project versions to the next milestone
AND pin downstream components to the next cylc-flow dev release.

cylc-flow
cylc-uiserver (pin to latest cylc-flow)
cylc-rose (pin to latest cylc-flow)

Finally:

close this issue 🚀

Add GitHub topics

the cylc/cylc project is lacking GitHub topics. Some possible topics include workflow, scheduling, or meta-scheduler. I think metascheduler and meta-scheduler are both empty in GitHub right now 😱

This could result in other users finding Cylc when searching for these topics. This happens with frequency when people go to the repository of another tool with topics, and click on these topics to explore and find related software.

Nightly Development Builds

[as discussed at Exeter meetup June 2019]

Now that we have separated Cylc components into multiple repositories we need to do periodic (e.g. nightly) builds to ensure compatibility is maintained.

This should be done on an umbrella repository (i.e. this one), the test battery could compose of a limited subset of tests from each component along with some purpose written integration tests.

Update SoD proposal: hidden partially-satisfied tasks

cylc/cylc-flow#3823

2022 Cylc Meetings

Following on from #139 ...

organization templates templates

GitHub lets us define issue templates at the organisation level, we can link through to our Discourse forum from this template too.

See for example:

https://github.com/jupyter-server/jupyter_server/issues/new/choose
https://github.com/jupyter-server/.github/blob/master/.github/ISSUE_TEMPLATE/config.yml

Use cylc globally as namespace for cylc, cylc-uiserver, cylc-xtriggers, etc

We have a few more projects now under the cylc organisation. So far I think they are all related to the Cylc core package/module - cylc is a package that contains the cylc module, but package and module are also used interchangeably.

Instead of having packages cylc with module cylc, cylc-uiserver with module cylc_uiserver, cylc-xtriggers with cylc_xtriggers, we can use namespace packages. So we would have:

cylc/cylc repository for cylc package, with the cylc module
cylc/cylc-uiserever repository for cylc-uiserver package, with the cylc.uiserver namespace module
cylc/cylc-xtriggers repository for cylc-xtriggers package, with cylc.xtriggers namespace module (collides with existing module from cylc/cylc)

And so on. This means that packages related to the Cylc core could share the namespace. So for a user, instead of writing:

from cylc.config import SuiteConfig
from cylc_xtriggers import SudoXtriggerForExample

s/he could write:

from cylc.config import SuiteConfig
from cylc.xtriggers import SudoXtriggerForExample

This assuming cylc and cylc-xtriggers have been installed.

I have not used this technique before, but it resembles something similar from Java (modules with common groupId), and the new scoped packages from NPM (e.g. @babel/core, @vue/cli-service).

This issue is both to check with others what is their opinion on this approach, and also to document in further comments my findings while experimenting with it, so that reasons for using or not are clear/transparent to others. Won't have much action until Cylc setup.py is merged first.

Feel free to add comments 👍

[discussion] Adopt -dev (or similar) suffix to versions

Users installing Cylc Flow from the master branch, and then running cylc --version will have a version like 8.0a0 right now. Some projects adopt a suffix like -dev or -dev1, dropping the suffix during the release process.

This would make the release process more complicated, but we have #39 that may help. And this way if a user reports the output of cylc --version, we will know immediately whether it was installed via conda/PYPI/tag, or if it was installed from master.

Some projects that adopt this are

We could apply this to Cylc Flow, Cylc UI Server, and even to Cylc UI in the package.json info.

Cheers
Bruno

Add a SECURITY.md for Cylc?

See:

Not sure if needed.

release: 8.0b3

Addresses #130 (comment)

Release progress:

pypi:

forge:

cylc-flow
metomi-rose
cylc-rose
cylc-uiserver

misc:

cylc-doc
discourse-post

pin downstream to the next cylc-flow dev release

cylc-flow
cylc-rose
cylc-uiserver

interventions: agree on the set-outputs/remove/forget discussions

Proposal cylc set
Proposal task expiration

Release cylc-xtriggers to Conda Forge

@sadielbartholomew fixed some issues in cylc-xtriggers, and then that reminded me that I excluded cylc-xtriggers from the Anaconda cylc recipe to save time (was already building too many projects, and just needed to confirm it worked).

Now that we know it works, we can add cylc-xtriggers and have a complete environment, with extra XTriggers loaded via the setuptools plugin system.

There is some commented code that was intended for cylc-xtriggers in cylc recipe, but we will need to create a cylc-xtriggers recipe from scratch (or from PYPI possibly), upload to a conda channel and update cylc recipe.

2023 Cylc Meetings

Following on from #143

10 January

Recent activity

Attended:

Discussion Topics

cylc-flow 8.1.0: 96 closed issues, 7 open

release end of week?
cylc vro nearly done

cylc-uiserver 1.1.1 and 1.2.0 both in progress

go straight to 1.2.0 but make sure the 1.x bug fixes are merged to master (include J-Hub 3.0 bug workaround)

cylc-ui: 1.4.0: 62 closed, 3 open

release soon with 8.1.0
job log view (MH) very close to being done

Master branch protection

HO to do: merge via PR only, no force-push or deletion
(Met O has daily back-ups just in case)

OS to present a webinar to IS-ENES3 in mid March. Should end up on you tube.

UK team to start work on rose edit and rosie soon, less time on Cylc

And will start pushing all users on to Cylc 8 very soon; lots of support likely needed.

HO to report on DS and AC hours left on UMP contract etc.

flake8-type-checking

Turns out we were importing a bunch of things for type checking without putting them behind if TYPE_CHECKING blocks. This was slowing Cylc runtime down. This PR addresses the issue for cylc-flow and adds a flake8 check to prevent this from happening again:

cylc/cylc-flow#5770

Quick easy fix!

Suggest adding the flake8-type-checking plugin to our other repos and fixing anything it complains about:

cylc/cylc-flow - cylc/cylc-flow#5770
cylc/cylc-uiserver - cylc/cylc-uiserver#513
cylc/cylc-rose - cylc/cylc-rose#257
metomi/rose - metomi/rose#2730
metomi/isodatetime - metomi/isodatetime#239

Create project template

GitHub provides project templates: https://help.github.com/en/articles/creating-a-template-repository

Would be nice to get one for Cylc, as we may end up getting more projects later. It could come with:

CHANGES.md template
CONTRIBUTING.md
LICENSE or COPYING
setup.py (even if not Python, I think it's fair as that's the most common language)
.github/ and templates

release: 8.1.0

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
Ensure major changes are listed in cylc-doc (reference/changes).
Test cylc-doc (run a test build, perform any required fixes).
Run cylc-flow functional tests against locally available platforms.
List the milestones for release below (delete entries as appropriate).

Milestones for release:

The release actions close the milestones for you automatically.

cylc-flow:
cylc-ui:
cylc-uiserver:
cylc-rose:
cylc-doc:

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.
(logical release order)
R1 = """
   cylc_flow & metomi_rose => cylc_rose
   cylc_flow & cylc_ui => cylc_uis
"""

Info on version pinning

Cylc plugins (i.e. cylc-rose and cylc-uiserver) are "pinned" to the minor version of cylc-flow. E.G. if the cylc-flow version is 8.1.2 the plugins should be pinned to 8.1.

More Information

~~metomi-isodatetime~~
cylc-flow (bump metomi-isodatetime if required)
cylc-ui
cylc-uiserver ([update the ui via GH action first)
~~metomi-rose (bump metomi-isodatetime if required)~~
cylc-rose

Forge (check dependencies match):

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If the PR doesn't get opened automatically

Create a new branch, change the version, reset the build number and update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump intersphinx versions if required (cylc-doc/src/conf.py)
- review deployment instructions
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
~~metomi-rose~~
- ~~build & deploy documentation (manual process ATM)~~
discourse post

Metadata:

GH Actions should automatically open PRs that bump the dev version of the projects. Check and merge them (can push alterations to PR branch if needed).

Pin downstream components to the next cylc-flow dev release:

cylc-uiserver (pin cylc-flow to next upcoming version)
cylc-rose (pin cylc-flow to next upcoming version)

Pin components in GH Actions tests:

cylc-doc (update versions in .github/workflows/test.yml "install libs to document" step(s) as appropriate)
metomi-rose (update versions in .github/actions/install-libs as appropriate)

Finally:

close this issue 🚀

Cylc Flow - Profile Battery

The old Cylc profile battery was removed at Cylc 8, it was decided that it would be moved to a top level project outside of Cylc Flow.

The old profile battery was designed to provide support back to Cylc 6 which made it's logic quite messy, as a result it is creaking at the seams and desperate for a re-write. Cylc installation has also changed meaning the profile battery does not work with Cylc 8 anyway.

Thanks to changes made at Cylc 7 the re-write should be pretty simple and can take some code from the old implementation.

Proposal:

The profile battery should generate a Cylc suite to run the experiments.
To install different Cylc versions:
- It will archive cylc code at different versions into the suite directory.
- Create and activate an environment based on a user provided command template (so as to support virtualenv / conda).
- Then pip install in-place.
Results stored in an sqlite3 DB in ~/.cylc.
The battery will be able to profile against:
- Experiment.
- Cylc Flow Version.
- Platform.
- Python Version.

Priority: low

component version compatibility

We need a strategy to handle cross-component version compatibility.

We can make a Cylc meta-package that installs the right, compatible, versions of all components at once, but that doesn't solve the problem of already-running workflows at a large site: new version of Cylc UI and UIS have to be able to handle older WFS versions nicely.

Release process checklist.

We need to clearly define the release process for the release manager to follow (including online documentation update).

This will get more complicated at Cylc 8.

Better presentation of docs?

Via GitHub Pages?

(Rather than view markdown files straight out of the repository?)

Broken links in the cylc-admin homepage

Was looking for the instructions to run everything from scratch, to send over to someone in Twitter, and found one broken link: In https://cylc.github.io/cylc-admin/, the very first link is broken: https://cylc.github.io/cylc-admin/howto/environment

Not sure where it's supposed to point.

2021 Cylc Meetings

Jan 2021

Cylc 7.8.7/7.9.2 released

deployed at MO and NIWA, no probs

Event-driven datastore PR: almost done

rose suite-run migration:

cylc install, reinstall, run1/2/3 dirs, rose-suite.conf plugin
cylc clean
done by end of Jan, if not before

editable mutations
- only thing missing is testing
delta-driven gscan
- need to check workflow "unregister" comes through as a delta
- DS: workflow status flicker hopefully fixed by event-driven PR
- if WF started from UI, need to trigger an immediate scan (config 5 sec delay at the moment)
message triggers (almost done?)
- choose ellipsis demo, with mods
hierarchical gscan
- a bit longer, needs deltas
- (needs more to the datastream? DS)

TODO for cylc-8.0b0 (by end of Feb):

finish existing PRs

UIS

minimal mutation-driven services: start stopped flows
(authorization, if time)

Scheduler

finish existing PRs
finish task state rationalization: queued as xtrigger (plus some trivial renaming?)
- queued as xtrigger
- (need to consider behaviour of multiple queues ... global queues)
- (ditch the trivial changes)
(delta-driven TUI? - nope; beta-1+)

Docs?

HO to consider minimal requirements for beta?

Other:

JR has time on Cylc 8 now 🎉

team meeting minutes

Create a new GH issue every year and record the agenda / minutes for each meeting as a comment on that issue.

This makes minutes a little more discoverable and searchable.

Create a new logo for Cylc

Do we need a new logo for Cylc? Is our logo OK, or is it too similar to logos of other projects? Maybe we can have an open call for submissions for logo ideas & designs.

Centralise Cylc CLI Functionality

At present the cylc command lives in Cylc Flow.

As of cylc/cylc-flow#3413 it is possible for other Cylc components to add their own Cylc commands.

It would probably make more sense for the cylc command to live in a common module which the others could used in turn. This common module should also contain the cylc version command which should now provide the version of the Cylc "super package", and, on-request a list of installed components and their versions. Note the list of installed components could be obtained from "entry points" in some way, this would work for both pipy and conda installations.

This "common module" could be:

(yet) another repository / pypi project.
A git submodule.
Something else?

Agree content of `cylc-flow.rc`

Reference #44

Aim

Before carrying out cylc-flow ticket #3260 get as much agreement as possible on the content of the new cylc-flow.rc.

Background

Before to #2199 (redefining how Cylc submits jobs to compute resources/clusters) we should consider the design of the .rc settings files.

The most logical way to support installation of suites on suite clusters and
job hosts is to migrate our host-based configuration logic to a cluster-based
configuration logic. Some points to consider:

Deprecate global.rc [hosts] section in favour of a [job platforms]
section. The new section should allow us to configure:
- Login hosts.
- Batch system or workload manager, and related settings.
- Directory locations for various usages by suites.
- Communication protocols:
  - Forward (install, submit, poll, kill, view log, log retrieval, etc).
  - Backward (message and manipulation commands).
Deprecate suite.rc relevant settings under [runtime][__MANY__], but have
a top level [job platforms] section that simply mirrors that of global.rc to allow individual suites to override the site/user settings.
Users will configure tasks to run on clusters instead of hosts/batch systems.
If relevant, improve alignment with DRMAA Open Grid Forum API?

So, for example, a suite flow.rc might look like this:

[cylc]
    ...

[scheduling]
    ...

[job platforms]
    [[spice]]
        [[[batch system]]]
            class = slurm
            before command = sshare -u %(user_id)           # Blue Sky thinking
            after command = sacct -j %(jobid)s --format=""
    [[xcs]]
        login hosts = xcslr0, xcslr1
        retrieve job logs = True
        [[[batch system]]]
            class = pbs
        [[[default directives]]]
            --some-directive="directive here!"
    [[desktop]]
        login hosts = vld392

[runtime]
    [[Alice]]
        ...

    [[Bob]]
        ...
        [[[job platform]]]
            platform = desktop

    [[Charlie]]
        ...
        [[[job platform]]]
            platform = spice
        [[[directives]]]
            --mem=5
            --ntasks=1

    [[Dai]]
        ...
        [[[job platform]]]
            platform = cray

Ideally the suite.rc and the global.rc should be replaced by a single configuration, probably called cylc-flow.rc. It is envisaged that some of it's settings are more likely to be set in a global context, and some in a suite context, but the same settings should be available in both cases.

2024 meetings

Issue meeting notes, follows on from #163

Placeholder for 8.0a1 release

(feel free to correct the version if it is not 8.0a1)

This issue is to prepare for the 8.0a1 cross component release of Cylc, which should include the following:

Cylc UI version 0.1: https://github.com/cylc/cylc-ui/milestone/1
- need a release tag in GitHub for conda recipe, i.e. a release with the zipped dist build for production
- need an updated git rev in Conda recipe: https://github.com/cylc/cylc-conda/blob/master/recipes/cylc/meta.yaml
Cylc Flow version 8.0a1: https://github.com/cylc/cylc-flow/milestone/77
- need a PYPI release (can use test PYPI, we should learn as much as possible from @matthewrmshin, he is the one with most up to date hands-on experience) for the conda recipe
- need to change the recipe to use the PYPI version instead of building from GitHub: https://github.com/cylc/cylc-conda/blob/master/recipes/cylc-flow/meta.yaml
- need to confirm if we need to update the metomi-isodatetime recipe to match Cylc Flow requirements: https://github.com/cylc/cylc-conda/blob/master/recipes/metomi-isodatetime/meta.yaml
Cylc UI Server version 0.1: https://github.com/cylc/cylc-uiserver/milestone/1
- need a PYPI release: cylc/cylc-uiserver#63
- need to change the recipe to use the PYPI version instead of building from GitHub: https://github.com/cylc/cylc-conda/blob/master/recipes/cylc-uiserver/meta.yaml
- need to confirm if we need to update the graphene-tornado recipe to match what Cylc UI Server requires: https://github.com/cylc/cylc-conda/blob/master/recipes/graphene-tornado/meta.yaml
Cylc Conda recipe:
- We need to include the configurable-http-proxy now to the recipe cylc/cylc-conda#9 (if too hard, we will ask users to install manually for now)

Some other pending issues that I am not sure if they are a requirement for this 8.0a1 release:

Do we need to worry about using Conda Forge, or are we going to keep using a channel (everything is in my personal channel)
Do we need the extra cylc-xtriggers now? https://github.com/cylc/cylc-conda/issues/7
- After chatting with @hjoliver this one doesn't seem to have high priority for now
  This is not exactly how the release process should be, so this is not fixing #39 , but I think it will contribute for that issue.

profiling: run cylc 7 profile tests against cylc 8

Cylc 7 had an on board automated profile battery which provided us with insights into Cylc's scaling characteristics.

This profile battery will need a total re-write for Cylc 8, there is an issue for that here #38, however, this is a relatively large job and one for which we don't have time at the moment so I suggest manually running some of the old scaling tests to give us an idea of how scaling has changed and how Cylc 8 compares againt Cylc 7.

Quick overview of the main scaling dimensions of Cylc:

Tasks
Edges
Recurrences (e.g. T00, T01, T02, etc, raises CPU load)
Churn / throughput (number of task events per second)

These dimensions are targeted by suites which were located in etc/dev-suites in the Cylc 7 source code.

For MO people some (rather dated) results from the old automated profile-battery can be found here: https://www-nwp/~osanders/profiling-results/2016/

To test scaling you will need to run the same experiment with different template variables.

Notes:

I suggest ramping up the scaling factors slowly, you can easily take down your machine with profiling experiments.

The chicken switch is killall python!

If you keep adding parallel tasks (without an internal Cylc queue), then you will eventually hit your machines fork limit which will cause task failures (and a very unhappy box).

To profile them I suggest using /usr/bin/time as we have a good level of understanding of this command and results will be comparable to prior tests.

Notes:

time and /usr/bin/time may differ in your shell.

Always use verbose mode.

For Darwin install GNU time.

$ /usr/bin/time -o <output-file> -v cylc play <workflow> -s <option> ... --no-detach

In the output we are interested in:

Wallclock time.
User + System time (i.e. CPU usage)
RSS memory usage.

For fair tests you need to run all experiments on the same hardware and to ensure the machine is idle. Running on a cluster may be a good idea but you may need to claim the whole node to meet these conditions (with the obvious resource wastage implications).

We don't have any up-to-date results for Cylc 7 so you will need to profile that too, however, you can use the automated profile battery there if you like. I think you run it like so:

$ cylc profile-battery -e complex -v 7.x.x

Maybe use cylc.github.io instead of cylc.github.io/cylc ?

If we move the gh-pages off from the Cylc main repository, to a different repository cylc/cylc.github.io, that would be the organisation default site. Serving the URL https://cylc.github.io.

It may have a positive impact on the site's SEO, but I think the main advantage would be that it's easier to have one word less. The other site from gh-pages could be left there with a redirect to the new site.

Cylc commands, packages and versions

We will soon have a Conda "meta" package for installing Cylc, this presents some new challenges we will need to address pre-Cylc8 release:

We want to be able to install only certain parts of Cylc Flow on job hosts:
- Message functionality (for tcp messaging).
- Flow sub-commands which interact with running workflows (e.g. for broadcast).
- Some other stuff I've not thought of.
We have multiple Python packages which provide Cylc commands:
- Cylc Flow (e.g. cylc run).
- The minimal Flow installation for job hosts (e.g. cylc message).
- Cylc UIS (e.g. cylc hub)
- Future Cylc Plugins (e.g. cylc report-timings)
cylc --version is incompatible with the "meta" package:
- The cylc command belongs to Cylc Flow so cylc --version is really cylc flow --version
- This becomes a problem with the "meta" package, where cylc --version should be the "meta" package version.
Sites will likely need multiple Cylc installations in multiple environments:
- Users need an easy way to work out which version they are using.
- In Cylc7 with the site script:
  - Users change versions like this export CYLC_VERSION=7.8.4...
  - They can check the version by doing this cylc version.

How do we resolve this issues? What solutions are available?

release: 8.0rc3

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
Test cylc-doc (run a test build, perform any required fixes).
Run cylc-flow functional tests against locally available platforms.
List the milestones for release below (delete entries as appropriate).

Complete and close milestones for release:

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.

~~metomi-isodatetime~~
cylc-flow (bump metomi-isodatetime if required)
cylc-ui
cylc-uiserver (update the ui version before releasing)
metomi-rose (bump metomi-isodatetime if required)
cylc-rose

Forge (check dependencies match):

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If not, create a new branch, change the version, reset the build number and
update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump intersphinx versions if required (cylc-doc/src/conf.py)
- review deployment instructions
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
metomi-rose
- build & deploy documentation - metomi/rose#2595
discourse post

Metadata:

Update project versions to the next milestone
AND pin downstream components to the next cylc-flow dev release.

cylc-flow - cylc/cylc-flow#4893
cylc-uiserver (pin to latest cylc-flow) - cylc/cylc-uiserver#358
cylc-rose (pin to latest cylc-flow) - cylc/cylc-rose#143
metomi-rose - metomi/rose#2596

Finally:

close this issue 🚀

release: 8.2

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
All bugfix branches should be merged into master.
Ensure major changes are listed in cylc-doc (reference/changes).
List the milestones for release below (delete entries as appropriate).

Testing:

Some testing is not fully automated and must be actioned by hand.

Run cylc-flow functional tests against locally available platforms.
cylc-doc (run a test build).
cylc-rose (run the "tests" action).
cylc-uiserver (run the "test" action).

Milestones for release:

The release actions close the milestones for you automatically.

cylc-flow:
cylc-ui:
cylc-uiserver:
rose:
cylc-rose:
cylc-doc:

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.
(logical release order)
R1 = """
   cylc_flow & metomi_rose => cylc_rose
   cylc_flow & cylc_ui => cylc_uis
"""

Info on version pinning

Cylc plugins (i.e. cylc-rose and cylc-uiserver) are "pinned" to the minor version of cylc-flow. E.G. if the cylc-flow version is 8.1.2 the plugins should be pinned to 8.1.

More Information

Forge (check dependencies match):

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If the PR doesn't get opened automatically

Create a new branch, change the version, reset the build number and update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump intersphinx versions if required (cylc-doc/src/conf.py) cylc/cylc-doc#630
- review deployment instructions
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
metomi-rose
- build & deploy documentation (manual process ATM) metomi/rose#2712
discourse post

Metadata:

GH Actions should automatically open PRs that bump the dev version of the projects. Check and merge them (can push alterations to PR branch if needed).

Update cylc-admin with the new branches / meta-release (8.3):

https://github.com/cylc/cylc-admin/blob/master/docs/status/branches.json

Pin downstream components to the next cylc-flow dev release:

cylc-uiserver (pin cylc-flow to next upcoming version)
cylc-rose (pin cylc-flow to next upcoming version)

Pin components in GH Actions tests:

cylc-doc (update versions in .github/workflows/test.yml "install libs to document" step(s) as appropriate)

Finally:

close this issue 🚀

Inter-Version Compatibility Testing

[as discussed at Exeter meetup June 2019]

Follow on from #33

Write a small set of integration tests designed to test the compatible version range between
different Cylc components.

For example:

Restart compatibility between different versions of Cylc Flow
Compatibility between the UI Server and different versions of Cylc Flow

This should give us a list of expected compatibility ranges which will need updating as breaking changes are made.

Automatically upload Conda packages to a personal channel in Conda Forge

During the 8.0a2 release, we had several issues that required re-building the packages locally. Besides the inconvenience of having to create environments, and build packages, it looks like conda install --use-local may have issues resolving transitive dependencies.

Instead of publishing multiple builds to test, we could have a GitHub action somewhere, manually triggered, that builds and publishes anaconda packages from branches in repositories, to a personal channel.

It would have to build all the packages, choosing the right branch in each repository (it could be a branch of a pending PR)

conda-forge/cylc-flow
conda-forge/metomi-isodatetime
conda-forge/cylc-uiserver
conda-forge/cylc-ui
conda-forge/cylc

And run anaconda upload ... for each package to upload to a channel (e.g. cylc-test)

This way, we could validate releases with a few commands

conda create -n cylc-env
conda activate cylc-env
conda install cylc --channel cylc-test

release: 8.0rc2

Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
Test cylc-doc (run a test build, perform any required fixes). https://github.com/cylc/cylc-doc/actions/runs/2023367714
Run cylc-flow functional tests against locally available platforms.
List the milestones for release below (delete entries as appropriate).

Non-bumpable PRs

Milestones for release:

cylc-flow:
cylc-ui:
cylc-uiserver:
metomi/rose:
cylc-rose:
cylc-doc:

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.

metomi-isodatetime
cylc-flow (bump metomi-isodatetime if required)
cylc-ui
cylc-uiserver (update the ui version before releasing)
metomi-rose (bump metomi-isodatetime if required)
cylc-rose

Forge (check dependencies match):

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If not, create a new branch, change the version, reset the build number and
update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump instersphinx versions if required
- review installation instructions
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
metomi-rose
- build & deploy documentation (manual process ATM)
discourse post

Metadata:

Update project versions to the next milestone
AND pin downstream components to the next cylc-flow dev release.

cylc-flow
cylc-uiserver (pin to latest cylc-flow)
cylc-rose (pin to latest cylc-flow)

Finally:

close this issue 🚀

Investigate Observability Options

Cylc comprises of a distribution of systems and, as such, if there is a bottleneck anywhere, then this can be difficult to pinpoint. Also, one of the key objectives of observability is to, not only see there is a problem, but to facilitate the discovery of where the problem has occurred.

Observability offers a detailed view of the internals of a software system - and Open Telemetry offers a standardised way of looking at traces.

By using a standard that is not tied to any language or platform, we can easily send traces from all parts of the system e.g. seeing the flow from cylc-flow to the ui-server, through to the ui itself.

This would be independent of our current logging. We could look at Open Logging and Open Metrics in the future when these standards are finalised also.

Using Open Telemetry and not a proprietary logging method, the users are free to send all telemetry to tracing aggregating tools of their choice as those increasingly support Open Telemetry framework; for example Zipkin and Jaeger.

So, for example, we may be able to set up spans such that, for example, for a request, we can display a detailed view of how time is spent on each process - a Gantt chart that you could drill down into to spot any bottlenecks.

Although not a current priority, this may be worth some investigation once things settle.

8.0.0 Release Progress

Issue to track the coordinated release of multiple Cylc components.

Required for all minor releases of cylc-flow.

See the release docs for first time instructions and more info.

Prep:

The release lead should be assigned to this issue.
Ensure all milestones complete.
Test cylc-doc (run a test build, perform any required fixes).
Run cylc-flow functional tests against locally available platforms.
List the milestones for release below (delete entries as appropriate).

Milestones for release:

The release actions close the milestones for you automatically.

cylc-flow:
cylc-ui:
cylc-uiserver:
metomi/rose:
cylc-rose:
cylc-doc:

PyPi / GitHub releases:

Ensure all Cylc components are pinned to the correct version of cylc-flow.

Trigger releases via GitHub actions.
(logical release order)
R1 = """
   cylc_flow & metomi_rose => cylc_rose
   cylc_flow & cylc_ui => cylc_uis
"""

Info on version pinning

Cylc plugins (i.e. cylc-rose and cylc-uiserver) are "pinned" to the minor version of cylc-flow. E.G. if the cylc-flow version is 8.1.2 the plugins should be pinned to 8.1.

More Information

Forge (check dependencies match):

Pull requests will be automatically opened on the conda-forge feedstocks
after the pypi releases.

If the PR doesn't get opened automatically

Create a new branch, change the version, reset the build number and update the hash from the PyPi website.
Finally trigger a rerender in a comment.

Ensure dependencies are up to date and follow instructions on the PR. Some
repos may maintain a list of conda dependencies locally.

It make take a couple of hours for a release to become available.
Use conda search <package> to determine when it's ready.

Misc (after the above has been completed):

cylc-doc
- bump intersphinx versions if required (cylc-doc/src/conf.py)
- review deployment instructions
- deploy (run the "deploy" workflow on GitHub Actions) (can be re-deployed later if necessary)
metomi-rose
- build & deploy documentation (manual process ATM)
discourse post

Metadata:

Update project versions to the next milestone
AND pin downstream components to the next cylc-flow dev release.

cylc-flow
cylc-uiserver (pin to latest cylc-flow)
cylc-rose (pin to latest cylc-flow)
metomi-rose

Finally:

close this issue 🚀