Ecosyste.ms: Timeline

Browse the timeline of events for every public repo on GitHub. Data updated hourly from GH Archive.

gruyaume

gruyaume pushed 1 commit to dev-tuto2 ellanetworks/core

View on GitHub

gruyaume pushed 1 commit to dev-tuto2 ellanetworks/core

View on GitHub

gruyaume pushed 1 commit to dev-tuto2 ellanetworks/core

View on GitHub

gruyaume pushed 1 commit to dev-tuto2 ellanetworks/core

View on GitHub

gruyaume pushed 2 commits to dev-tuto2 ellanetworks/core
  • chore: bump ruff from 0.9.2 to 0.9.3 (#391) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: depe... 1b07093
  • Merge branch 'main' into dev-tuto2 e4301ad

View on GitHub

gruyaume pushed 1 commit to dev-tuto2 ellanetworks/core

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
Please explain why it is discouraged and the fact that not setting this parameter will mean that the private key will be automatically managed by the library.

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
Again, this "provided by the charm" wording is confusing I find - the lib is part of the charm.

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
Is that true? If the key is not valid, we raise (which is the right thing to do in my opinion) and we do not generate a new one

View on GitHub

gruyaume created a review on a pull request on canonical/tls-certificates-interface

View on GitHub

gruyaume pushed 2 commits to dev-upfperf2 canonical/charmed-aether-sd-core

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
We could probably raise earlier. If the user provided private key is not valid, no need to go any further.

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
I'm not sure about the phrasing "managed by the charm". I would prefer "provided through the private_key parameter" or something like that

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
```suggestion def _user_provided_private_key(self, private_key: Optional[PrivateKey]) -> bool: ```

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
Some docstring would be useful to understand what this function does

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
I don't think we should log in such a helper method, the warning should be decided by whatever method calling this one.

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
I'm not sure about the phrasing "managed by the charm". I would prefer "provided through the private_key parameter" or something like that

View on GitHub

gruyaume created a review on a pull request on canonical/tls-certificates-interface

View on GitHub

gruyaume pushed 1 commit to main canonical/tls-certificates-interface
  • fix: writing secret content bug from ops (#305) 3dd33c1

View on GitHub

gruyaume closed a pull request on canonical/tls-certificates-interface
fix: writing secret content bug from ops
# Description Hello team, When trying to rotate the certificates by setting the private key manually in the etcd charm, I noticed a bug in the ops framework that caused the TLS lib to fail to...
gruyaume created a review on a pull request on canonical/tls-certificates-interface

View on GitHub

gruyaume created a review on a pull request on canonical/tls-certificates-interface

View on GitHub

gruyaume created a comment on a pull request on canonical/charmed-aether-sd-core
> I think it would be better for me to test with the same hardware with `AF_PACKET` mode to have a basis for comparison. Removing the hardware use and putting those results next to each other makes...

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
I didn't know either! This feature should also allow us leverage Dependabot to bump our lib, assuming all we need is to change the string with the version number.

View on GitHub

gruyaume created a review on a pull request on canonical/tls-certificates-interface

View on GitHub

gruyaume opened a pull request on canonical/charmed-aether-sd-core
docs: add af_packet performance results
# Description Here I re-structure the Performance reference so that results are at the top as those are likely what users will care the most about. I removed the details about the hardware as...
gruyaume created a branch on canonical/charmed-aether-sd-core

dev-upfperf2 - Charmed Aether SD-Core is a secure, reliable and observable open source 5G private mobile network.

gruyaume opened an issue on canonical/tls-certificates-interface
Explicitly state minimal pydantic version
### Enhancement Proposal ## Description The TLS library v4 requires pydantic >= 2 to function, but this fact is not stated anywhere in the lib or in the Charmhub documentation. We should explic...
gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
Can you please improve the PR description? Having the reference is fine but the source of truth for the code is here in GitHub - Please explain what is the issue, root cause and how this fix addres...

View on GitHub

gruyaume created a review comment on a pull request on canonical/tls-certificates-interface
Can you please write a unit test for this behavior?

View on GitHub

Load more