CUE Town Hall

[mpvl]

Hi everyone,

We are excited to confirm Thu 21 October at 1500 UTC as the date for the first CUE community town hall!

The session will start with a project update, a high level review of the roadmap, upcoming releases, and major proposals. We will also dedicate a good portion of time to questions/topics the wider community would like to see addressed. So please reply to this discussion with anything that you would like to see covered.

It is very likely that we will have too much material to cover in the one hour we have scheduled, but fear not! We want these sessions to become a regular point of contact.

This first town hall will be a live stream broadcast to YouTube, with a recording made available afterwards. We have tried to cater for as many time zones as possible, but recognize the timing is not ideal. Future town halls will likely alternate between two times, accommodating, as much as possible, friendlier hours for the two extremes either side of CET.

We look forward to seeing you there and we'll confirm the livestream link shortly!

[jpluscplusm]

Hurrah! Hugely looking forward to this :-D

[cedricgc]

CUE szn incoming
Some strategic things I would like to see discussed:

• Long term plans around CUE foundation work and developing a healthy contributor base (core + ecosystem)
• Building out relationships and tooling to integrate CUE with other tools/products, which is especially important for a configuration language

[talentedmrjones]

• Strategies for a single CUE code base written for multiple tools. i.e: how could things like dagger, stax. and polly work together? Looking beyond just different package names. What other CUE features would be useful? Attributes? Something else?
• Status of Proposal: core built in extensions

[b4nst]

• Status of tools around CUE, especially Proposal: package management #851 and lsp: Language Server Protocol Support #142
• Best way for us to help the CUE effort

[atcol]

Great idea!

Would love to know more about:

• the general roadmap and particularly how things like OpenAPI might have full support in the language
• the possibility of Rust bindings so Cuelang can be read/written by Rust ala dhall-rust

[verdverm]

I'd be interested to hear your thoughts on #1286 (CUE proposals in a repository) as opposed to having them only in issue descriptions.

[eonpatapon]

I'd like to know what is/will be the new process and tools for submitting contributions

[jlongtine]

@mpvl + @myitcv:

I'm interested in understanding the current state of #804 (Roadmap: Performance enhancements), as I am fairly confident that they are blockers to the use of CUE in medium to large configurations. I’ve definitely experienced difficulties with them in cfn-cue, and I believe that dagger has had similar issues, as well. I suspect this could cut down on evaluation times enormously for sufficiently large configurations (especially with definitions and disjunctions), and increase adoption.

I also think that an language server could be a powerful addition to the toolbox. Any new thoughts around that?

Something I’ve noticed a few times is differences in how people evaluate CUE code (all of the code in a folder, ./… and it’s many build instances, and more). I’d be interested in guidance about best practices around this. In part because I think that understanding design patterns will be good for the community, but also because the evaluation context (included files, etc) will be pretty important to clarify for a language server.

Finally, I’ll echo many of the people above with curiosity about how the community can and should contribute to CUE, CUE tooling, etc.

[jpluscplusm]

I'm most interested in how the project can increase its appeal to Ops folks. Those who would be incredibly well served by being shown a route out of YaML-templating/etc land, but who can be forgiven for looking at CUE and seeing a lot of Go and code-integration/-generation rhetoric & examples & discussions.

These folks (I count myself in their number, tribe-wise!) are /primed/ to want to take the first step away from YaML-land, but the seeming intent of the project is to meet significantly loftier goals that -- at best -- don't add anything to these folks escaping their current crappy predicament; and -- at worst -- can seem to represent a "if you're not aiming for these code-driven, sunny uplands, then don't even bother STARTING on this journey with CUE" barrier.

I suppose my questions are these: does the team see this putative Ops person -- who wants to stop templating YaML but doesn't have a great handle on what their first half-dozen steps would look like -- as a desirable audience for CUE evangelism? And if so, does it recognise the problem of evangelising a "it's /not/ a 'better jq', but is instead a nicer way of thinking about config!" mindset when the community discourse seems SO much further along the journey than the Ops/YaML-jockey can imagine themselves? And, finally, what can we do about that?

[jpluscplusm]

Ideas I've had around this over the past few months:

• move the code-integration commands (eg cue get) into a different tool, leaving the cue binary as a more sharply-focussed tool.
• have more "how to get there from here" intermediate-levels docs that aren't focussed on Go integration or k8s, but step much further beyond the current 101-level/primer use cases.
• have more docs around the current state and uses and pitfalls of packages.
• have stronger/more-opinionated guidance on the use of Instances vs "render all the config in this directory and its child directories". I.e. make it clearer which model will get folks on the better, more sustainable path: leaf-nodes as overlapping configs which are simply never evaluated simultaneously with other leaf nodes; vs a from-the-top-level-directory, globally-evaluate-able aggregation of CUE where everything has to fit together.

[myitcv]

We are about to go live at https://www.youtube.com/watch?v=GMTQcm3AwOU!

[sdboyer]

i've made some roadmap alignment issues for various different bits that Grafana Labs is interested in. I opted to split them up into issues that are specific to the particular project.

• CUE Roadmap Alignment grafana/thema#1
• CUE Roadmap Alignment grafana/cuetsy#37

(There'll be another one coming for Grafana itself more generally, which is necessarily a superset of the above two, as well)