Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI - add kmip engine #6936

Merged
merged 59 commits into from
Jun 21, 2019
Merged

UI - add kmip engine #6936

merged 59 commits into from
Jun 21, 2019

Conversation

meirish
Copy link
Contributor

@meirish meirish commented Jun 20, 2019

This adds the ability to create Scopes, Roles, and Credentials using the Vault Enterprise KMIP Secrets Engine, as well as enabling and configuring it.

Currently you can't delete any of these items - that and tests will come in a follow up PR.

@meirish meirish added this to the 1.2 milestone Jun 20, 2019
@meirish meirish requested review from a team June 20, 2019 17:47
category: 'generic',
};

export const MOUNTABLE_SECRET_ENGINES = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty sure we don't need to export this const anymore since we're only using the KMIP const elsewhere

*
* @example
* ```js
* <FieldGroupShow @param1={param1} @param2={param2} />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should update these docs (and eventually in another PR add to Storybook). 😬

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah there's lots to add to storybook because we moved a bunch over to core.

{{#each fields as |attr|}}
<InfoTableRow
@alwaysRender={{showAllFields}}
@label={{capitalize (or attr.options.label (humanize (dasherize attr.name)))}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may no longer need to do both humanize and dasherize since openApi gives us displayNames now, but we could also leave this in here just in case there are new fields that don't have them. 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the fallback here - that's what the or is doing - so I think it's worth keeping. attr.options.label gets populated from Open API's display name struct.

Copy link

@johncowen johncowen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed a couple of tiny things, one of which is just a question for me.

Overall I noticed there seems to be a move away from conventional ember practices (there are a lot of things here like transition-to and set-flash-message helpers, that would usually be done out of a template). Me personally, I prefer everything just being a well defined component and/or a helper (basically a JS function), makes everything far easier to work with.

P.S. I only didn't approve as you have @noelledaley here already.

import ApplicationAdapater from '../application';
import { encodePath } from 'vault/utils/path-encoding-helpers';

export default ApplicationAdapater.extend({

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo 👮 ! Adapater > Adapter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol nice catch - I do that particular one way too often. At least they match so it's not broken 😛 - I'll get that fixed though!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hehehe nice, yeah I've done the matching typo thing waaaaay too many times

{{#link-to "role" @scope @role}}
Details
{{/link-to}}
{{/link-to}}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have time, could you walk me through what is happening here? (re: the nested link-tos)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is a sad thing we do because we were trying to use as much of bulma's CSS as we could initially. We'll get rid of this when we have our own tabs component.

But what's it's doing is constructing <li><a/></li> for the tab - tagName on the outer one is the important thing here. If I'm remembering correctly we needed to do this because bulma styles active tabs on the li, so we're using link-to's ability to get the active class when the route matches.

@meirish
Copy link
Contributor Author

meirish commented Jun 21, 2019

Hey @johncowen thanks for looking at this!

Overall I noticed there seems to be a move away from conventional ember practices (there are a lot of things here like transition-to and set-flash-message helpers, that would usually be done out of a template). Me personally, I prefer everything just being a well defined component and/or a helper (basically a JS function), makes everything far easier to work with.

Yeah I think closure actions opened up a lot of possibilities here and gives the flexibility of passing in things from above (from a component or controller) or via a helper that uses a service (which is what both transition-to and set-flash-message do). I've found I'm looking for helpers more as we're building out more reusable components because it feels like things compose more easily.

@johncowen
Copy link

Cool thanks for the extra info @meirish. +1 to the helpers thing, I definitely find myself reaching for helpers more (when I can) instead of Controller/computedProperties

madalynrose
madalynrose previously approved these changes Jun 21, 2019
return `/v1/${path}/config?help=1`;
},

listenAddrs: attr({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't need this with the new OpenAPI changes

@meirish meirish merged commit 7e9c016 into master Jun 21, 2019
@meirish meirish deleted the ui-add-kmip-engine branch June 21, 2019 21:05
catsby added a commit that referenced this pull request Jun 24, 2019
* master: (47 commits)
  Add the ability to use a dev Consul node for dev storage (#6965)
  Update CHANGELOG.md
  Correct API docs examples (#6963)
  Fix test
  changelog++
  Allow turning on client auth in test clusters (#6958)
  Update vendoring
  Update SDK version
  Make CA certificate optional in ClientTLSConfig
  Update vendor
  Combined Database backend: remove create/delete support (#6951)
  Bump sdk
  Move tls config creation to tlsutil (#6956)
  Update JWT tips (#6955)
  raft join tls (#6932)
  changelog++
  UI - add kmip engine (#6936)
  Pass context to Cassandra queries (#6954)
  Minor clean up JWT provider docs (#6952)
  update azure instructions (#6858)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants