This commit tries to make the development experience of working on our OIDC support a little more realistic, essentially by creating our own OIDC provider in our application (only during development builds). You can still provide a real OIDC provider to work with via our dev time environment/cookie variables as before, just now we default to the behaviour in this commit. Overall this makes it much easier to verify our OIDC support in the UI, and also opens up avenues for us to be able to test more scenarios that we couldn't before (for example not only successful logins, but also erroneous, potentially with multiple error reasons).
To make it more clear which methods are necessary for each scenario. This can
also prevent problems which force all DCs to use the same Vault instance, which
is currently a problem.
This function is only run when the CAManager is a primary. Extracting this function
makes it clear which parts of UpdateConfiguration are run only in the primary and
also makes the cleanup logic simpler. Instead of both a defer and a local var we
can call the cleanup function in two places.
This commit renames functions to use a consistent pattern for identifying the functions that
can only be called when the Manager is run as the primary or secondary.
This is a step toward eventually creating separate types and moving these methods off of CAManager.
* Start new page
* reset
* Consul on Kubernetes - Features List Section (#11078)
* Fix conflicts
* Start adding and placing content
* Add a lot of styling and background image
* Looking like design. Before adding more global styles
* Work on editing styles
* Move imports and switch to flex
* Add more styles and bottom left background image
* Fix conflicts
* Fix styles on mobile
* Change images path in public
* Updates from code review - Move data and update styles
* Convert to tsx and add types
* Change button props to get desired styling without using css
* Remove margin on mobile
* Consul On Kubernetes - Hero (#11089)
* Start hero section
* Increase max sizes for container
* Minor Edits
* Use g-grid-container
* Edit video styles and test
* Rename component
* Start moving global styles over
* Move hero styles to locl
* Remove composes g-hero
* Fix flex basis on media
* Add display flex to media
* Clean up some styles
* Consul On Kubernetes - Block List (#11114)
* Start block list
* Enter data and start styles
* Get all images in and update styles
* Move data and convert to ts
* Add comment in page
* Consul On Kubernetes - Side by Side Section (#11122)
* Start block list
* Enter data and start styles
* Get all images in and update styles
* Start side by side
* Add content and more styles
* Some more styles
* Add styles for text and titles
* Edit styles and clean
* Fix spacing between button and text in overview
* Delete public folder
* Fix images in block on page
* remove extra file
* Fix classnames import
* Use fragment
* Consul On Kubernetes - Docs List Component (#11150)
* Add docs list component
* Add docs list content
* Change type declaration
* Remove unecessary style
* Use fragment
* Change icons
* Consul On Kubernetes - Card List & Get Started Section (#11168)
* Start card list component
* Begin adding content
* Start wrapper styles
* Add more styles for card
* Fix style
* Edit styles
* Use next Link
* Add minor formatting
* Make entire card a link
* Add transition
* Change import
* Use svg instead of button and make target blank
* Move wrapper div to component and add classname prop, use color variable for border
* Change min of card in grid
* Less pxels for min
* Update copy
* Consul on Kubernetes Content (#11179)
* Add content so far
* Add hero content and switch video to embed - needs editing
* Add overview and docs links
* Use iframe in hero and style
* Remove = null on prop
* Add learn tutorials content so far
* Change learn tutorials content
* Change placeholder learn content
* Add requested copy updates
* Align numbers
* Consul on Kubernetes Content & Design Updates (#11217)
* Update docs icons
* Update learn cards
* Update challenges icon
* Video poster pending
* New image
* Add split up background images
* Looking pretty good
* Fix up background image
* Add more styles
* Add meta description and new feature images
* Revert img change
* Fix up images and replace poster
* Switch to grid
* Move images
* Clean up styles
* Change hero button text
* Update styles for hero video
* Update youtube url
* Use gray variable
* Consul on Kubernetes Metadata (#11219)
* Add meta data for sharing
* Test
* Test 2
* Add meta title
* Update share image
* CHange name
* Test
* Test again
* Use relative url
* Swap urls for hero ctas
* Update tutorial card to be uniform
* Change overview button text
* Resolve conflicts and fix dependencies
* Add `is` and `test` helpers in a similar vein to `can`
Adds 2 new helpers in a similar vein to ember-cans can:
- `is` allows you to use vocab/phrases such as (is "something model") which calls isSomething() on the models ability.
- `test` allows you to use vocab/phrases such as (test "is something model") or (test "can something model")which calls isSomething() / canSomething() on the models ability. Mostly using the is helper and the can helper. It's basically the is/can helper combined.
* Adds TextInput component + related modifiers/helpers/machines/services (#11189)
Adds a few new components/modifiers/helpers to aid building forms.
- state-chart helper, used in lieu of a more generic approach for requiring our statecharts.
- A few modifications to our existing disabled modifier.
- A new 'validation' modifier, a super small form validation approach built to make use of state charts (optionally). Eventually we should be able to replace our current validation approach (ember-changeset-validations + extra deps) with this.
- A new TextInput component, which is the first of our new components specifically to make it easy to build forms with validations. This is still a WIP, I left some comments in pointing out where this one would be progressed, but as we don't need the planned functionality yet, I left it where it was. All of this will be fleshed out more at a later date.
Documentation is included for all of ^
* ui: Adds initial CRUD for partitions (#11190)
Adds basic CRUD support for partitions. Engineering-wise probably the biggest takeaway here is that we needed to write very little javascript code to add this entire feature, and the little javascript we did need to write was very straightforwards. Everything is pretty much just HTML. Another note to make is that both ember-changeset and ember-data (model layer things) are now completely abstracted away from the view layer of the application.
New components:
- Consul::Partition::Form
- Consul::Partition::List
- Consul::Partition::Notifications
- Consul::Partition::SearchBar
- Consul::Partition::Selector
See additional documentation here for more details
New Route templates:
- index.hbs partition listing/searching/filtering
- edit.hbs partition editing and creation
Additionally:
There is some additional debug work here for better observability and to prevent any errors regarding our href-to usage when a dc is not available in our documentation site.
Our softDelete functionality has been DRYed out a little to be used across two repos.
isLinkable was removed from our ListCollection component for lists like upstream and service listing, and instead use our new is helper from within the ListCollection, meaning we've added a few more lighterweight templateOnly components.
* ui: Exclude all debug-like files from the build (#11211)
This PR adds **/*-debug.* to our test/prod excluded files (realised I needed to add test-support.js also so added that here as its more or less the same thing). Conditionally juggling ES6 static imports (specifically debug ones) for this was also getting a little hairy, so I moved it all to use the same approach as our conditional routes. All in all it brings the vendor build back down to ~430kb gzipped.
Some updates to the UI specific issue template.
The previous 'Old UI or New UI' question is no longer relevant and considering the amount of visual change we've had, this leads to folks answering things like 'Consul 1.10.0+ent with new, new UI'. Now it's just "The Consul UI".
I mainly took the rest from the current Consul Core issue template but made it relevant to the UI both for issues/bugfixes and for suggestions/improvements.
From an engineers perspective, whenever specifying colors from now on we should use the form:
```
color: rgb(var(--tone-red-500));
```
Please note:
- Use rgb. This lets us do this like rgb(var(--tone-red-500) / 10%) so we can use a 10% opacity red-500 if we ever need to whilst still making use of our color tokens.
- Use --tone-colorName-000 (so the prefix tone). Previously we could use a mix of --gray-500: $gray-500 (note the left hand CSS prop and right hand SASS var) for the things we need to theme currently. As we no longer use SASS we can't do --gray-500: --gray-500, so we now do --tone-gray-500: --gray-500.
Just for clarity after that, whenever specifying a color anywhere, use rgb and --tone. There is only one reason where you might not use tone, and that is if you never want a color to be affected by a theme (for example a background shadow probably always should use --black)
There are a 2 or 3 left for the code editor, plus our custom-query values
> In the future, this should all be moved to each individual repository now, which will mean we can finally get rid of this service.
This PR moves reconciliation to 'each individual repository'. I stopped short of getting rid of the service, but its so small now we pretty much don't need it. I'd rather wait until I look at the equivalent DataSink service and see if we can get rid of both equivalent services together (this also currently dependant on work soon to be merged)
Reconciliation of models (basically doing the extra work to clean up the ember-data store and bring our frontend 'truth' into line with the actual backend truth) when blocking/long-polling on different views/filters of data is slightly more complicated due to figuring out what should be cleaned up and what should be left in the store. This is especially apparent for KVs.
I built in a such a way to hopefully make sure it will all make sense for the future. I also checked that this all worked nicely with all our models, even KV which has never supported blocking queries. I left all that work in so that if we want to enable blocking queries/live updates for KV it now just involves deleting a couple of lines of code.
There is a tonne of old stuff that we can clean up here now (our 'fake headers' that we pass around) and I've added that to my list of thing for a 'Big Cleanup PR' that will remove lots of code that we no longer require.
trujillo-adam