ui: TProxy Service Mesh Viz Beta Changes

[kaxcode]

Demo Link

✨ Created warning banner for permissive intentions (wildcard-intentions) and default-allow intentions

✨ Created topology-metrics/source-type component (label). Used in each Card.

✨ Created consul/transparent-proxy component (label). Used in service instance show page.

✨ Created warning banner for not explicitly defining an upstream intention

✨ Created a dashed line with a warning icon for card with upstream intention not explicitly defined

✨ Created a *(All Services) card as a placeholder for all the services our main service can talk to because of permissive intentions

🤡 Updated service-topology mock data with new attributes: TransparentProxy, Source, and DefaultAllow
🤡 Updated connect mock data with new attribute: Mode
♻️ Refactored the topology-metrics/card component to be in its own folder structure

[kaxcode]

This is only in the down-lines because only downstreams would have "not defined upstreams explicitly."

[kaxcode]

I purposely left out 'specific-intention' because only downstreams would have "upstreams not explicitly defined."

[kaxcode]

@johncowen this file is getting really big now. 😬

[johncowen]

Yeah ideally the translations for components needs to be split up to live in the components folders with all the rest of the component code. There are other things we can do to split it up also, is that something you can look at?

[kaxcode]

I tried splitting things into folder translation/components/transparent-proxy but it didn't work. Do I have to add the new files in settings?

[johncowen]

Oh sorry, we'd have to do some broccoli magic to make the component folder thing work, there are other ways to split it up though, take a look at the docs there's some guidance there.

[kaxcode]

I had to leave this Intention block or else it creates a Deny icon.

[kaxcode]

I had to make some height adjustments. I'll probably have to rework on this again for the GA dropdown.

[johncowen]

Thanks for the notes! I left a few more, I think there are 4 main things this could do with before merging:

1. undefined is a bit of a weird name to use in javascript with it being so important in javascript, I can imagine various ways bugs could slip in here if something is accidentally undefined and that gets cast to a string. I think we should change this to something else so it doesn't end up getting stuck in here.
2. It would be good to try and avoid the multiple single use components for the notices here if possible.
3. Add enough mocks so you can see all different types by default (and add the mode to the proxy endpoints if thats where they go)
4. Choose a solution for specifying paragraphs in the translations.

I think the rest could be done here, or at any point moving forwards.

Nice work!

[johncowen]

We need to think about how we encode/describe paragraphs in the translations, if this text required two paragraphs it'd be a bit nasty to do something like:

<p>
      {{t "components.consul.topology-metrics.notice.default-allow.body.p0"}}
</p>
<p>
      {{t "components.consul.topology-metrics.notice.default-allow.body.p1"}}
</p>

I'd like to use a very simple markdown helper to do that (means we can encode other inline HTML also). Unless you want to take a look at that, I think in the meantime we can put very minimal HTML in the translations file, so we just end up with:

<notice.Body>
      {{t "components.consul.topology-metrics.notice.default-allow.body"}}
</notice.Body>

[kaxcode]

Wait, that looks the same as what I have 🤔 Did you mean using the p0 p1 ?

[johncowen]

We need to be able to define paragraphs of text in the translations file, not in the template (in these cases). Ideally we'd use markdown in the translations file, but I guess we should add something later. So for now I'd put the <p> tags here in the translations file.

I know this seems wrong (putting HTML in the translations file), but it would make more sense once it's markdown. To try help, imagine if we had a piece of text that has 2 paragraphs, you wouldn't want to specify each paragraph as a different translation key, which means we have to somehow specify simple formatting in the translations file. Let me know if that doesn't make sense and we can go over in a bit more detail.

[kaxcode]

In this scenario I just have 1 <p>. Use still want to use default-allow.body.p0?

[johncowen]

It'd also be nice to put these URLs in the translations file if you are doing 'translations everywhere'. Ideally we need to keep the root as an env var and the rest in the YAML file.

Also theres an Action component with an @external attribute that we can use for all these links now:

<Action @href={{t "identifier" root=(env 'CONSUL_DOCS_URL')}} @external={{true}}>
  {{t "identifer"}}
</Action>

[kaxcode]

The root=(env 'CONSUL_DOCS_URL') didn't work. Maybe we could go over this together.

[johncowen]

Yeah ideally the translations for components needs to be split up to live in the components folders with all the rest of the component code. There are other things we can do to split it up also, is that something you can look at?

[johncowen]

This jumps out as strange to me? I don't think we use this for any other badge type things?

[kaxcode]

Yea, this is the first bad we have in the sandwiched between text. It needed a bit more spacing in the bottom and sides.

[johncowen]

Wondering if inline-block works for what you want to do here?

[kaxcode]

@johncowen all tests have passed and I've moved this PR out of draft. Ready for last ✅

[johncowen]

Nice, I know you are waiting on backend for this but 👍 from me!

[hashicorp-ci]

🍒 If backport labels were added before merging, cherry-picking will start automatically.

To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/351744.