@imacg feel free to contribute anything you like to the nix stuff!

Unfortunately I don't really use it myself and I'm unsure who else is using it, but it's certainly a nice thing to have.

Added a feature request template to the issues templates

rustls has started spamming the logs with:

[2020-09-29T13:12:26Z WARN  rustls::server::hs] Resumption ignored, DHE_KE not offered

I'm not sure what's causing this or exactly what it means (PSK is Pre-shared Key, DHE_KE is I think Diffie Helman Key Exchange).

Addressed error message in #176

• Should now get an internal error if server can't write to FS
• Shouldn't have tonic status in route.rs, but it's there...

Yes, I think so. But either is fine as long as it's easy to change.

• Should now get an internal error if server can't write to FS
• Shouldn't have tonic status in route.rs, but it's there...

Ah, I think I see it.

I think you've been bit by a breaking change between 0.2 and 0.3. The error is actually occurring when Trow tries to write to the filesystem and it's hitting an error. It's being caused by these lines in your config:

      securityContext:             
        runAsUser: 999
        runAsGroup: 999
        fsGroup: 999

We changed the Trow user from 999 to 333333 as minor security improvement. You're using the 0.3 image which includes this change, but the kubernetes config still has the old values.

Could you check the server logs (should be something like `kubectl logs -n trow-test trow-pod) and share those? Hopefully there is a clearer error message there.

To fix the problem you'll need to:

• update your k8s configs to use 333333 as the user everywhere
• run chown -R 333333 /data on your data directory

The "manifest invalid" error message isn't accurate, so I'll change that, but I don't want to give away details of what's happening on the server end, so it will probably just be "server error" or something.

Wish I knew why this was needed, but tests are flaky otherwise.

Wish I knew why this was needed, but tests are flaky otherwise.

• Update Mozilla nix overlay to current master
• Synchronize Rust nightly date with docker/Dockerfile.*
• Pass path of protoc to trow-protobuf build script via PROTOC envvar

Wow. This is awesome, thanks. I was actually going to delete default.nix as I didn't think anyone used it anymore (@moredhel wrote it originally).

Let me figure out why this test is failing and I'll merge (I don't see how the test can have anything to do with your change so it's a bit weird).

Thanks.

For the sake of the thread - the OP is experiencing issues uploading any image, not a given image.

Regarding the problem with the 0.3.0 tagged image, it sounds like an issue with how you are running Trow - could you share the YAML you used to deploy Trow?

Also, could you post the config for metallb, I have a feeling that might actually be the problem.

BTW Trow and several other images are "multi-arch", which means the version you get is dependant on the architecture of the machine you pull them on. So if you pull an image on your workstation, please be careful that you get the same architecture as the server. In most cases this won't be a problem as both will probably be x86_64 Linux, but it's possible you will find some images (not Trow) with windows OS builds that won't work on your cluster.

Sure, as long as there's nothing sensitive. I'm not sure if there's a file limit though.

Could you give me a copy of the image to test with?

You might need to use docker save and upload it somewhere or send it to my e-mail (adrian.mouat at container-solutions.com)

You can install from the Helm chart without providing username/pass? It didn't look possible to me - maybe it's just a docs issue.

I can't recreate this problem. It should work - you're not doing anything unusual at the Trow level and I tried to recreate as much as I could (I haven't tried the nginx proxy).

The 401 error for http://clientlogin-yy http://clienttest.client.com.xx/v2/_catalog is correct - you'd need to authenticate and pass the token in the header for this to work.

I think the problem is either with nginx or some networking issue. You don't need any further networking changes.

We missed the code of conduct when adding the Contributor guidelines. Please take a look and make sure you're happy with this one.

We're missing an example for PodPreset.

It should be possible to use an example from the Kubernetes docs.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

We're missing an example for PriorityClass.

It should be possible to use an example from the Kubernetes docs.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

We're missing an example for PodDisruptionBudget.

It should be possible to use an example from the Kubernetes docs.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

Add examples for ValidatingAdmissionWebhook and MutatingAdmissionWebhook.

It should be possible to use examples from the Kubernetes docs, but please make sure they work standalone.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

We're missing an example for HorizontalPodAutoscalar.

It should be possible to use an example from the Kubernetes docs.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

Added #17 and #18

We're missing an example for PersistentVolumeClaim, but we do have one for PersistentVolumes. This example should probably go in the same directory.

It should be possible to use an example from the Kubernetes docs, but please make sure it works either standalone or with the existing PersistentVolume example.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

We're missing an example for EndpointSlices, but we do have one for Endpoints. This example could go in the same directory or a new one.

It should be possible to use the example from here: https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

Ok, I went through everything except Cluster API stuff.

There are some things that we cover in other directories that you might want to cross link e.g. IngressClass and the various Pod/ReplicaSet/Container things.

Anyway, as best as I can tell, the following is missing:

• EndpointSlice
• CSIDriver, CSINode, VolumeAttachment (I can't find much resources on these, I assume they're for setting up cluster specific volume types? https://kubernetes-csi.github.io/docs/csi-driver-object.html)
• PersistentVolumeClaim (we do have PVs, but nothing about PVCs that I saw, could add to PV dir)
• ControllerRevision & ControllerRevisionList (not sure what this is about or if it can be created by users)
• CustomResourceDefinition
• Event (I think this is created internally only and should be ignored)
• HorizontalPodAutoscalar
• ValidatingAdmissionWebhook
• MutatingAdmissionWebhook
• PodDisruptionBudget
• PriorityClass
• PodPreset

Above you mention creating empty folders for these. I'd actually recommend against that idea, as I think it will make it trickier to see what exists and what doesn't.

If it's ok with you, I'd like to take several of these resources and create independent issues for them, which can labelled good first issue and hacktoberfest.

Replace Adrian's e-mail with Ian's - Ian please check this is what you want, you can always leave it as is.

This PR is based on the Trow repo, modified for Kubernetes Examples.

We need this in place if we want to take advantage of hacktoberfest.

If you want to work on any of these, please discuss here and then we can open a new issue for the specific platform.

#126

• [x] Disk

• [x] Number of requests?

  • [x] Blobs
  • [x] Manifests

• [ ] Number stored:

  • [ ] Manifests
  • [ ] Blobs
  • [ ] Tags

Should be compatible with prometheus.

Report on things like:

• disk space
• number of blobs, manifests, tags stored
• number of requests served

The Helm chart currently asks for a user and password, but it should also be possible to configure with no user/password set at all.

The current build & distribution is created by Travis. This currently has some problems, not least requiring uploading a personal access token to Travis CI.

It would be better and easier to move to GitHub actions. The build part should be trivial and creating distribution binaries shouldn't be much harder. At the same time the docker builds could be fixed and moved to ghcr.

Sorry, there's a problem with Cargo.lock that needs fixed now. I think you just need to rebase and maybe run cargo update

Hi @amouat ,

Hopefully an easy question but I couldnt find it in the docs; I was able to setup trow with basic username/password protection and we are able to push images to the registry. However, when I try to deploy them with kubectl, I get an unauthorized, which makes sense. I've tried to setup a secret for docker setup, which seem to work but I still fail to connect.

Is there any standard to make this work? greetz, Remco

Thanks.

I'm going to close this issue for the minute, but I'll take a note of the issue for improving our docs.

If you hit any problems, please open a new issue for that.

Good luck!

Adrian.

and this one

and this one

Could you delete the asserts where you check something isn't a number, then verify it is a different number? They're just duplicating work - if something is 8, it can't be 0 by definition :)

No problem.

Would you like to set-up a quick call to discuss some of this? Just drop an e-mail if so - you should be able to find my address on my profile.

Using persistent storage should be pretty simple and it's what we do in the standard install by default. Depending on your cluster, you should be able to do something like this: https://github.com/ContainerSolutions/trow/blob/master/install/base/stateful-set.yaml#L46-L53 which matches this https://github.com/ContainerSolutions/trow/blob/master/install/base/stateful-set.yaml#L29-L31

To be honest, I think you'd be better served by moving to the standard install and modifying it so that it works for your use case.

You should be able to just follow the standard instructions: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

Did you remember to set imagePullSecrets on the pod? https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret

We use this method internally, so it should definitely work. If you still have problems, could you post the YAML you're using?

Great. I did see the same thing and wonder, apologies for not posting it earlier. I'll get the chart updated.

Thanks a lot for the report.

Thanks for the report.

From looking at your output it doesn't seem than the ingress is forwarding to the pod correctly. I think there may be a mistake in the chart somewhere. I'll try to recreate this.

The current install docs are a bit all over the place:

• The kustomize install instructions are under the install directory but the Helm instructions are under docs. I guess the best solution is to move the kustomize instructions but leave a placeholder in install pointing to the docs guide.
• The Helm instructions could do with a bit more context and explanation, especially on TLS ingress and domain names. But some of this is already in the Kustomize instructions, so there might be a way to merge the two.

Yes, that's the plan. Unfortunately it's taking a bit longer than I hoped. Trow is a working registry now, but still needs a couple of basic features before I want to move on tackling the ImageWolf stuff (which I normally refer to as "advanced distribution").

I'm considering archiving this repo.

Hi @luisdavim - apologies, I never saw this comment until now!

That's an interesting idea. It's not something I'd thought about before. I guess you're effectively changing a push webhook into a polling pull?

Dear community

The coming prometheus release, Prometheus 2.20, contains native support for Docker Swarm.

Please try it and provide us with your feedback. This is highly appreciated.

https://prometheus.io/docs/prometheus/2.20/configuration/configuration/#dockerswarm_sd_config

Thanks @roidelapluie. I'm archiving this project now and closing this issue. I'm a bit sad we never maintained it properly :(

Looks like we've got 631MB, and that's very big and should be fairly easy to reduce. Just reporting i it here for the record, it's not critical at this stage.

This was closed by #8

@prologic I'm sorry, I have no idea and the author of this repository left Container Solutions. You might have more luck on the prometheus slack or GitHub repo.

Hi @jhoglin . I work at Container Solutions and I'm currently going through all our open source projects.

I'd like to apologise that you never got a reply for this PR. This definitely isn't the experience we're aiming for with our projects :(

I'm about to archive this project as it's unmaintained and there is now native support in prometheus, but I'll merge your PR anyway. Thanks for your work!

During explicit discovery mode only collect ports specified in label. This is helpful if your container expose some ports not serving metrics.

Explicit discovery already ignores all containers not labelled prometheus.scan=true, with this change you also need to explicitly label containers with the port to collect. prometheus.port=8080.

Fixes #2

I closed this via #8.

Again, apologies that there was no communication.

Hi @ymatsiuk . I work at Container Solutions and I'm currently going through all our open source projects.

I'd like to apologise that you never got a reply. This definitely isn't the experience we're aiming for with our projects.

I'm about to archive this project as it's unmaintained and there is now native support, but I'll merge your PR. Thanks for your work!

Use docker multi-stage build feature to reduce image size.

According to #1, the task labels should be used in the target discovery, but the Task object does not have directly a Labels attribute.

Hi @mion00 . I'm currently going through all Container Solution's open source projects.

I'd like to apologise that you never got a reply. This definitely isn't the experience we're aiming for with our projects.

I'm about to archive this project as it's unmaintained and there is now native support, but I'll merge your PR. Thanks for your work!

Thanks, that would be appreciated.