While it's true that there is substantial activity on Zulip, I think the
fact that we have a decent amount of community engagement on Slack in spite
of the fact that Zulip is currently the official platform linked to on the
site means that people probably do prefer Slack.
Personally I do not have
Looking a bit more into the PR, I think it is primarily about avoiding an
STS call rather than about "raw" credentials.
I think the STS requirement can, indeed, be a blocker for some custom S3
implementations.
If we want to support those, we could allow the admin user to configure a
separate set
(note: I did not review the PR)
On-prem systems usually have different security perimeters than cloud
systems.
While vending long-term credentials by default is too risky, I agree, why
would Polaris restrict that in controlled environments where the admin user
explicitly wants to enable that (e.g
Agree, that was argument one, the second argument is that we need to
move forward on cool features in the meantime ;)
On Mon, Dec 9, 2024 at 3:10 PM Robert Stupp wrote:
>
> All in for good functionality!
>
> I think, you wanted to express that overall Polaris must really be "rock
> solid" (secure
All in for good functionality!
I think, you wanted to express that overall Polaris must really be "rock
solid" (secure, stable, performant) - aka: it would "just" be annoying,
if a certain functionality/feature isn't working properly. But it would
be a hard no-go if the system isn't stable, or
Hi folks,
Sorry to have been almost quiet last week, I was travelling.
Following some discussion threads we got on the mailing list, I
propose to populate a public roadmap using the following process:
- we create GH Issues with the "proposal" tag
- we can attach a document to this GH issue (and e
