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

Create endpoint for fetching the flux namespace #1465

Closed
jpellizzari opened this issue Feb 17, 2022 · 0 comments
Closed

Create endpoint for fetching the flux namespace #1465

jpellizzari opened this issue Feb 17, 2022 · 0 comments
Assignees

Comments

@jpellizzari
Copy link
Contributor

jpellizzari commented Feb 17, 2022

I think we should avoid making assumptions about flux namespace (https://github.com/weaveworks/weave-gitops/pull/1451/files#diff-35acf2adc3a7b1021fb41d3473b47e030d3708ba2e8ff7a4b76c13ee80b4076cR42) and grab it by using something like: https://github.com/weaveworks/weave-gitops/blob/v2/pkg/kube/kubehttp.go#L496

I'm not sure we want to keep that interface but the actual method is useful.

Originally posted by @luizbafilho in #1451 (comment)

Acceptance Criteria:

  • Make an endpoint that works like the one linked above, so that the UI can figure out which namespace(s) to query
@yitsushi yitsushi self-assigned this Feb 22, 2022
yitsushi added a commit to yitsushi/weave-gitops that referenced this issue Feb 23, 2022
Add new endpoint to query flux namespace. For simplicity, no arguments
on the request and returns only the name of the namespace. That fulfills
the original request so we can remove the constant[^1] from the UI.

== Considered solutions

1. Create a general endpoint

The consumer could query namespaces and filter them with provided
filters.

Dropped this solution, because it could open up some weird surfaces
where the client can query arbitrary filters.

2. Create a general endpoint with strict filtering options

The consumer could query namespaces with a set of filter options and if
they are not specified, throw back an error.

Dropped this solution, because changing the filtering rules would
require code change. The final solution in this change-set has the same
issue, but less complex. If we don't get extra value out of the
complexity, it's not worth it.

== Follow-up

If/when we need a complex endpoint to query all namespaces with filter
options, then we can add one with a plan like:

* Who/what will use it?
* What is the desired input and output?
* How to achieve this?
* What limitations do we want to implement?
* How much freedom do we want to give to the consumer?

== Other changes

* `make proto` updated a lot of auto-generated files.
* In `tools/dependencies.toml`, removed the system-wide installation of
  a tool, because the last thing I want from a project to download a
  binary and place it somewhere with root permission. I'm not giving
  root permissions just to install dependencies.
* Use `tools/bin/tilt` in `Makefile` (see previous entry).
* Replaced the logic behind `getMatchingLabels`. Using the `with option`
  pattern, we can build up more complex labeling queries, and the
  codebase will remain clean.

```go
match := matchLabel(
  withPartOfLabel(appName),
  withInstanceLabel(appInstance),
  withManagedByLabel(appManager),
)
```

[^1]: https://github.com/weaveworks/weave-gitops/pull/1451/files#diff-35acf2adc3a7b1021fb41d3473b47e030d3708ba2e8ff7a4b76c13ee80b4076cR42

Fixes weaveworks#1465
yitsushi added a commit that referenced this issue Feb 25, 2022
Add new endpoint to query flux namespace. For simplicity, no arguments
on the request and returns only the name of the namespace. That fulfills
the original request so we can remove the constant[^1] from the UI.

== Considered solutions

1. Create a general endpoint

The consumer could query namespaces and filter them with provided
filters.

Dropped this solution, because it could open up some weird surfaces
where the client can query arbitrary filters.

2. Create a general endpoint with strict filtering options

The consumer could query namespaces with a set of filter options and if
they are not specified, throw back an error.

Dropped this solution, because changing the filtering rules would
require code change. The final solution in this change-set has the same
issue, but less complex. If we don't get extra value out of the
complexity, it's not worth it.

== Follow-up

If/when we need a complex endpoint to query all namespaces with filter
options, then we can add one with a plan like:

* Who/what will use it?
* What is the desired input and output?
* How to achieve this?
* What limitations do we want to implement?
* How much freedom do we want to give to the consumer?

== Other changes

* `make proto` updated a lot of auto-generated files.
* In `tools/dependencies.toml`, removed the system-wide installation of
  a tool, because the last thing I want from a project to download a
  binary and place it somewhere with root permission. I'm not giving
  root permissions just to install dependencies.
* Use `tools/bin/tilt` in `Makefile` (see previous entry).
* Replaced the logic behind `getMatchingLabels`. Using the `with option`
  pattern, we can build up more complex labeling queries, and the
  codebase will remain clean.

```go
match := matchLabel(
  withPartOfLabel(appName),
  withInstanceLabel(appInstance),
  withManagedByLabel(appManager),
)
```

[^1]: https://github.com/weaveworks/weave-gitops/pull/1451/files#diff-35acf2adc3a7b1021fb41d3473b47e030d3708ba2e8ff7a4b76c13ee80b4076cR42

Fixes #1465
jpellizzari pushed a commit that referenced this issue Feb 25, 2022
Add new endpoint to query flux namespace. For simplicity, no arguments
on the request and returns only the name of the namespace. That fulfills
the original request so we can remove the constant[^1] from the UI.

== Considered solutions

1. Create a general endpoint

The consumer could query namespaces and filter them with provided
filters.

Dropped this solution, because it could open up some weird surfaces
where the client can query arbitrary filters.

2. Create a general endpoint with strict filtering options

The consumer could query namespaces with a set of filter options and if
they are not specified, throw back an error.

Dropped this solution, because changing the filtering rules would
require code change. The final solution in this change-set has the same
issue, but less complex. If we don't get extra value out of the
complexity, it's not worth it.

== Follow-up

If/when we need a complex endpoint to query all namespaces with filter
options, then we can add one with a plan like:

* Who/what will use it?
* What is the desired input and output?
* How to achieve this?
* What limitations do we want to implement?
* How much freedom do we want to give to the consumer?

== Other changes

* `make proto` updated a lot of auto-generated files.
* In `tools/dependencies.toml`, removed the system-wide installation of
  a tool, because the last thing I want from a project to download a
  binary and place it somewhere with root permission. I'm not giving
  root permissions just to install dependencies.
* Use `tools/bin/tilt` in `Makefile` (see previous entry).
* Replaced the logic behind `getMatchingLabels`. Using the `with option`
  pattern, we can build up more complex labeling queries, and the
  codebase will remain clean.

```go
match := matchLabel(
  withPartOfLabel(appName),
  withInstanceLabel(appInstance),
  withManagedByLabel(appManager),
)
```

[^1]: https://github.com/weaveworks/weave-gitops/pull/1451/files#diff-35acf2adc3a7b1021fb41d3473b47e030d3708ba2e8ff7a4b76c13ee80b4076cR42

Fixes #1465
jpellizzari pushed a commit that referenced this issue Mar 3, 2022
Add new endpoint to query flux namespace. For simplicity, no arguments
on the request and returns only the name of the namespace. That fulfills
the original request so we can remove the constant[^1] from the UI.

== Considered solutions

1. Create a general endpoint

The consumer could query namespaces and filter them with provided
filters.

Dropped this solution, because it could open up some weird surfaces
where the client can query arbitrary filters.

2. Create a general endpoint with strict filtering options

The consumer could query namespaces with a set of filter options and if
they are not specified, throw back an error.

Dropped this solution, because changing the filtering rules would
require code change. The final solution in this change-set has the same
issue, but less complex. If we don't get extra value out of the
complexity, it's not worth it.

== Follow-up

If/when we need a complex endpoint to query all namespaces with filter
options, then we can add one with a plan like:

* Who/what will use it?
* What is the desired input and output?
* How to achieve this?
* What limitations do we want to implement?
* How much freedom do we want to give to the consumer?

== Other changes

* `make proto` updated a lot of auto-generated files.
* In `tools/dependencies.toml`, removed the system-wide installation of
  a tool, because the last thing I want from a project to download a
  binary and place it somewhere with root permission. I'm not giving
  root permissions just to install dependencies.
* Use `tools/bin/tilt` in `Makefile` (see previous entry).
* Replaced the logic behind `getMatchingLabels`. Using the `with option`
  pattern, we can build up more complex labeling queries, and the
  codebase will remain clean.

```go
match := matchLabel(
  withPartOfLabel(appName),
  withInstanceLabel(appInstance),
  withManagedByLabel(appManager),
)
```

[^1]: https://github.com/weaveworks/weave-gitops/pull/1451/files#diff-35acf2adc3a7b1021fb41d3473b47e030d3708ba2e8ff7a4b76c13ee80b4076cR42

Fixes #1465
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants