Do we want to have komodo build the image or do we want to leverage the CI/CD on gitea and have the images be built and stored to the gitea internal focker image server so that komodo only pulls the images?
Anything missing from the checklist?
Current project velocity confirms the release date to happen this week. This is kind of urgent to discuss.
As we approach 1.0 release time, we also approach the time where this application needs to be deployed to the outernet (with disabled registrations).
Key points:
- [x] Registrations need to be disabled
- [x] All endpoint tests need to be passing (minus the anonymous access ones)
- [x] Database data on docker-dev should be moved to Komodo
- [x] Thumbnail Cache should be preserved and transfered to Komodo
- Possibly on NVME storage
- [x] Preview Data should be preserved and transfered to Komodo
- This needs to be on HDDs
- [x] Higher resolution preview data shoudl be calculated on job (while the transfered one works as a fallback)
- [x] Caddy needs to be updated with a 3rd level domain name pointing to the container
- [x] Configuration file should be set up to have the service working in komodo
Follow up questions for @Fastwind:
- Do we want to have komodo build the image or do we want to leverage the CI/CD on gitea and have the images be built and stored to the gitea internal focker image server so that komodo only pulls the images?
- Anything missing from the checklist?
Current project velocity confirms the release date to happen this week. This is kind of urgent to discuss.
REDCODE
added this to the v1.0 - Initial Release milestone 2026-07-16 14:07:46 +00:00
For debugging and rollback policies, we need to be able to retrieve the same image used by the server.
The best course of action would be to build production images of both services (lactose and milkystream) and upload them on the Gitea image server.
While the production server should be handled by Komodo for the configurations, the compose should be updated manually or through other automated systems so that it follows the pinned version instead of the latest. @ale183 could help with that
Should the data move, or is it better to recreate it to test a complete deployment from zero? @REDCODE
For debugging and rollback policies, we need to be able to retrieve the same image used by the server.
The best course of action would be to build production images of both services (lactose and milkystream) and upload them on the Gitea image server.
While the production server should be handled by Komodo for the configurations, the compose should be updated manually or through other automated systems so that it follows the pinned version instead of the latest. @ale183 could help with that
Should the data move, or is it better to recreate it to test a complete deployment from zero? @REDCODE
Should the data move, or is it better to recreate it to test a complete deployment from zero? @REDCODE
Wit no data movement we are looking at 48+ hrs of jobs running to regenerate thumbs and previews which make the service unusable. Moving thumbs and previews we get a workable service + I can upgrade previews overtime while the service runs. I'd prefer keeping the data for that simple reason.
> Should the data move, or is it better to recreate it to test a complete deployment from zero? @REDCODE
Wit no data movement we are looking at 48+ hrs of jobs running to regenerate thumbs and previews which make the service unusable. Moving thumbs and previews we get a workable service + I can upgrade previews overtime while the service runs. I'd prefer keeping the data for that simple reason.
Is a configuration to disable registration present?
Yes, has been a toggle in settings since a month or so.
Is the first registration already handled?
admin - admin user gets created, but if we migrate the db we do not need to do any of that. And that is necessary to reuse thumbs and previews (assets would get a different guid otherwise)
How much do you trust your anti-spam for login tentatives?
Because we both know someone will scraper the server and try until they found one password
I plan to generate the accounts for the people and give them randomized strong passwords. Not planning to give untrusted people any power above user either. So the damage would be limited.
Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in #105, we could do partial implementation here for 1.0 on auth endpoints
> Is a configuration to disable registration present?
Yes, has been a toggle in settings since a month or so.
> Is the first registration already handled?
admin - admin user gets created, but if we migrate the db we do not need to do any of that. And that is necessary to reuse thumbs and previews (assets would get a different guid otherwise)
> How much do you trust your anti-spam for login tentatives?
> Because we both know someone will scraper the server and try until they found one password
I plan to generate the accounts for the people and give them randomized strong passwords. Not planning to give untrusted people any power above user either. So the damage would be limited.
Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in #105, we could do partial implementation here for 1.0 on auth endpoints
I plan to generate the accounts for the people and give them randomized strong passwords
Admins considered too?
Not planning to give untrusted people any power above user either. So the damage would be limited.
so most of the asset will be shared internally, not to anons
Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in #105, we could do partial implementation here for 1.0 on auth endpoints
It could be not enough
Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
> I plan to generate the accounts for the people and give them randomized strong passwords
Admins considered too?
> Not planning to give untrusted people any power above user either. So the damage would be limited.
so most of the asset will be shared internally, not to anons
> Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in [#105](https://git.r3d.codes/MilkyShots/MilkyShots/issues/105), we could do partial implementation here for 1.0 on auth endpoints
It could be not enough
Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
I plan to generate the accounts for the people and give them randomized strong passwords
Admins considered too?
Can I trust that you use a damn strong password as you use a password manager like me?
Not planning to give untrusted people any power above user either. So the damage would be limited.
so most of the asset will be shared internally, not to anons
not most, all of them, no public assets for the v1.0 are planned.
Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in #105, we could do partial implementation here for 1.0 on auth endpoints
It could be not enough
Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
You drink now?
> > I plan to generate the accounts for the people and give them randomized strong passwords
>
> Admins considered too?
Can I trust that you use a damn strong password as you use a password manager like me?
>
> > Not planning to give untrusted people any power above user either. So the damage would be limited.
>
> so most of the asset will be shared internally, not to anons
not most, all of them, no public assets for the v1.0 are planned.
> > Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in [#105](https://git.r3d.codes/MilkyShots/MilkyShots/issues/105), we could do partial implementation here for 1.0 on auth endpoints
>
> It could be not enough
>
> Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
>
>
You drink now?
I plan to generate the accounts for the people and give them randomized strong passwords
Admins considered too?
Can I trust that you use a damn strong password as you use a password manager like me?
It is/was a development testing server, so the password wasn't required to be strong. Also, admin doesn't have a strong password either, so it is required to generate stronger password for it. at this point do it for all the accounts
Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in #105, we could do partial implementation here for 1.0 on auth endpoints
It could be not enough
Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
You drink now?
It's this project (and the heat) that makes me want to do it, but non-alcohol only.
> > > I plan to generate the accounts for the people and give them randomized strong passwords
> >
> > Admins considered too?
>
> Can I trust that you use a damn strong password as you use a password manager like me?
It is/was a development testing server, so the password wasn't required to be strong. Also, admin doesn't have a strong password either, so it is required to generate stronger password for it. at this point do it for all the accounts
> > > Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in [#105](https://git.r3d.codes/MilkyShots/MilkyShots/issues/105), we could do partial implementation here for 1.0 on auth endpoints
> >
> > It could be not enough
> >
> > Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
> >
> >
>
> You drink now?
It's this project (and the heat) that makes me want to do it, but non-alcohol only.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
As we approach 1.0 release time, we also approach the time where this application needs to be deployed to the outernet (with disabled registrations).
Key points:
Follow up questions for @Fastwind:
Current project velocity confirms the release date to happen this week. This is kind of urgent to discuss.
For debugging and rollback policies, we need to be able to retrieve the same image used by the server.
The best course of action would be to build production images of both services (lactose and milkystream) and upload them on the Gitea image server.
While the production server should be handled by Komodo for the configurations, the compose should be updated manually or through other automated systems so that it follows the pinned version instead of the latest. @ale183 could help with that
Should the data move, or is it better to recreate it to test a complete deployment from zero? @REDCODE
Wit no data movement we are looking at 48+ hrs of jobs running to regenerate thumbs and previews which make the service unusable. Moving thumbs and previews we get a workable service + I can upgrade previews overtime while the service runs. I'd prefer keeping the data for that simple reason.
How much do you trust your anti-spam for login tentatives?
Because we both know someone will scraper the server and try until they found one password
Yes, has been a toggle in settings since a month or so.
admin - admin user gets created, but if we migrate the db we do not need to do any of that. And that is necessary to reuse thumbs and previews (assets would get a different guid otherwise)
I plan to generate the accounts for the people and give them randomized strong passwords. Not planning to give untrusted people any power above user either. So the damage would be limited.
Also we currently do not have an anti-spam. But rate limiting by ip on a single auth endpoint could be quickly introduced. Rate limiting is planned in #105, we could do partial implementation here for 1.0 on auth endpoints
Admins considered too?
so most of the asset will be shared internally, not to anons
It could be not enough
Hold my beer for a moment. I'm going to take a look on how long it would take to implement rate limiting now
Can I trust that you use a damn strong password as you use a password manager like me?
not most, all of them, no public assets for the v1.0 are planned.
You drink now?
It is/was a development testing server, so the password wasn't required to be strong. Also, admin doesn't have a strong password either, so it is required to generate stronger password for it. at this point do it for all the accounts
It's this project (and the heat) that makes me want to do it, but non-alcohol only.
Deploy is done.