microLXC Public Test

Neoon

@fadedmaple said:

@Neoon said:

@Neoon said:

@Neoon said:
Inactivity Policy update

As of right now, logging in every 60 days, is sufficient to keep everything active.
However, despite that, it seems like we still have too many idle containers.

In about a week, a different policy is gonna be in affect
Which also is gonna require at least 1GB of traffic (inbound + outbound) per month, per container.

For testing reasons, the limit is set as low as possible.
If only one of the requirements in meet, the container will not be extended.

The way the plan was to implement it has changed.
Basically, its gonna applied over the cost factor instead.

For example, as of right now, you can spend the 1GB allocation as you want.
However, if you deploy more than 2 containers on a single node, the second container is costing you double.

There is an exception if its a bigger node, that rule doesn't apply for the second container but for the third.

The idea here is, to do it the same way.
If your container has less than 100MB used traffic (inbound + outbound) in the last 15 days, starting when your bandwidth counter resets.

Which is different from each container, depending on when you created your container.
The cost of this container will simply put, double.

To incentivise you to either put it to good use or terminate it.
I have coded it already, its way easier to implement, including email notifications.

The plan was to roll this out tomorrow, there will be no stop or terminate actions taken at this point.
I am open for feedback, if you have some lemme know.

The 100MB is subject to change, but as of right now, ,its set as low as possible.

Any Feedback?

Just curious—if someone keep exceeding the usage limit and ignore it, will there be any penalty?

Nothing right now, I look into the stats in about 2 weeks and have a look how many people keep exceeding their usage limit.

igctt

e32b-2a5c-3d10-55ef

igctt

@Neoon said:

@Neoon said:

@Neoon said:
Inactivity Policy update

As of right now, logging in every 60 days, is sufficient to keep everything active.
However, despite that, it seems like we still have too many idle containers.

In about a week, a different policy is gonna be in affect
Which also is gonna require at least 1GB of traffic (inbound + outbound) per month, per container.

For testing reasons, the limit is set as low as possible.
If only one of the requirements in meet, the container will not be extended.

The way the plan was to implement it has changed.
Basically, its gonna applied over the cost factor instead.

For example, as of right now, you can spend the 1GB allocation as you want.
However, if you deploy more than 2 containers on a single node, the second container is costing you double.

There is an exception if its a bigger node, that rule doesn't apply for the second container but for the third.

The idea here is, to do it the same way.
If your container has less than 100MB used traffic (inbound + outbound) in the last 15 days, starting when your bandwidth counter resets.

Which is different from each container, depending on when you created your container.
The cost of this container will simply put, double.

To incentivise you to either put it to good use or terminate it.
I have coded it already, its way easier to implement, including email notifications.

The plan was to roll this out tomorrow, there will be no stop or terminate actions taken at this point.
I am open for feedback, if you have some lemme know.

The 100MB is subject to change, but as of right now, ,its set as low as possible.

Any Feedback?

100MB is too low, if you use it normally, even if setting up a monitoring program, it would exceed 100MB easily.

salakis

d687-426c-6d9c-b938

lol_fire

6ecc-2bb2-deb8-0e1d

Ganonk

i'm not using it at the moment,

but

Neoon

@Ganonk said:
i'm not using it at the moment,

but

Not using, could still still be some peace of software causing the CPU spikes.
Has your CPU usage been low? you checked it?

david

I got an email today.

Your container lxc99a7ef97 used less than 100MB of bandwidth in the last 15 days.
Due to this, the system doubled the cost of this container.

For example, if you have a 64MB container, it will now be counted as a 128MB container, due to inactivity.
If you do not have any use for this container, please consider terminating it.

I just created that one about an hour ago, and received the email just after reinstalling it. Maybe the algorithm needs adjusting? I guess I can try terminating it and adding it again.

Neoon

@david said:
I got an email today.

Your container lxc99a7ef97 used less than 100MB of bandwidth in the last 15 days.
Due to this, the system doubled the cost of this container.

For example, if you have a 64MB container, it will now be counted as a 128MB container, due to inactivity.
If you do not have any use for this container, please consider terminating it.

I just created that one about an hour ago, and received the email just after reinstalling it. Maybe the algorithm needs adjusting? I guess I can try terminating it and adding it again.

I am going to try to reproduce it.

I looked at the code, however, mostly a network stats issue, when you create a new container, the network stats don't exist yet, they have to be created, including the date when the bandwidth usage is going to reset, which is used for the low bandwidth cost adjustment, my guess the bug is there.

david

@Neoon said: I am going to try to reproduce it.

I looked at the code, however, mostly a network stats issue, when you create a new container, the network stats don't exist yet, they have to be created, including the date when the bandwidth usage is going to reset, which is used for the low bandwidth cost adjustment, my guess the bug is there.

Thanks. I did terminate it and deployed a new one. I still received the email again within the first hour.

Neoon

@david said:

@Neoon said: I am going to try to reproduce it.

I looked at the code, however, mostly a network stats issue, when you create a new container, the network stats don't exist yet, they have to be created, including the date when the bandwidth usage is going to reset, which is used for the low bandwidth cost adjustment, my guess the bug is there.

Thanks. I did terminate it and deployed a new one. I still received the email again within the first hour.

I tired it on 2 containers, could not reproduce it.
However, Looking at it, its better to change the logic anyway, unlucky me my CI/CD right now doesn't want to work, have to fix that first before I can push the patch.

Neoon

@Neoon said:

@david said:

@Neoon said: I am going to try to reproduce it.

I looked at the code, however, mostly a network stats issue, when you create a new container, the network stats don't exist yet, they have to be created, including the date when the bandwidth usage is going to reset, which is used for the low bandwidth cost adjustment, my guess the bug is there.

Thanks. I did terminate it and deployed a new one. I still received the email again within the first hour.

I tired it on 2 containers, could not reproduce it.
However, Looking at it, its better to change the logic anyway, unlucky me my CI/CD right now doesn't want to work, have to fix that first before I can push the patch.

I pushed the patch, you can try again.

david

@Neoon said: I pushed the patch, you can try again.

I deployed a container in Valdivia, and it's been over an hour without any email warnings, so hopefully that fixed it. Thanks!

Fubukibox

Hello, im not sure if this is still active but i did reg on microlxc for running a private AmneziaWG/Wireguard server for personal use and a private proxy server between my VDS server (under 2ms) since it's in the NL. 10GB should be plenty enough just to run those two. i will also run hetrixtools agent on the server too

my token is: 4f4d-1b2a-4e0c-2a1d

thanks

Fritz

Hey,

Your container lxcxxxxxxx used less than 100MB of bandwidth in the last 15 days.
Due to this, the system doubled the cost of this container.

For example, if you have a 64MB container, it will now be counted as a 128MB container, due to inactivity.
If you do not have any use for this container, please consider terminating it.

Any questions? You can mail us at: [email protected]

microLXC

Neoon

@Fritz said:
Hey,

Your container lxcxxxxxxx used less than 100MB of bandwidth in the last 15 days.
Due to this, the system doubled the cost of this container.

For example, if you have a 64MB container, it will now be counted as a 128MB container, due to inactivity.
If you do not have any use for this container, please consider terminating it.

Any questions? You can mail us at: [email protected]

microLXC

Context?!

Neoon

Maintenance announcement
Gonna upgrade the backend to a new debian release, on Sunday, at around 22:00 CET, the panel will be unavailable for about 30 minutes, tops.

Neoon

@Neoon said:
Maintenance announcement
Gonna upgrade the backend to a new debian release, on Sunday, at around 22:00 CET, the panel will be unavailable for about 30 minutes, tops.

After the Maintenance I checked a few things, I noticed that Console / Shell was partially broken on some nodes.
I pinned the issue down, however still working on a fix, no ETA currently, probably, some breaking change to hypervisor, despite its LTS.

Neoon

@Neoon said:

@Neoon said:
Maintenance announcement
Gonna upgrade the backend to a new debian release, on Sunday, at around 22:00 CET, the panel will be unavailable for about 30 minutes, tops.

After the Maintenance I checked a few things, I noticed that Console / Shell was partially broken on some nodes.
I pinned the issue down, however still working on a fix, no ETA currently, probably, some breaking change to hypervisor, despite its LTS.

A security issue has been fixed with this update, which has not been published yet.
As precaution, I also disabled Console / Shell for LXD nodes, probably it also affects LXD which hasn't been patched yet.

I have theoretically a fix, to make it work again, gimme some time to implement it though.
I just learned a few hours ago, what the actually cause is.

Neoon

@Neoon said:

@Neoon said:

@Neoon said:
Maintenance announcement
Gonna upgrade the backend to a new debian release, on Sunday, at around 22:00 CET, the panel will be unavailable for about 30 minutes, tops.

After the Maintenance I checked a few things, I noticed that Console / Shell was partially broken on some nodes.
I pinned the issue down, however still working on a fix, no ETA currently, probably, some breaking change to hypervisor, despite its LTS.

A security issue has been fixed with this update, which has not been published yet.
As precaution, I also disabled Console / Shell for LXD nodes, probably it also affects LXD which hasn't been patched yet.

I have theoretically a fix, to make it work again, gimme some time to implement it though.
I just learned a few hours ago, what the actually cause is.

Console / Shell is available again on LXD nodes.
Incus will follow.

supple

@Fritz said:

Your container lxcxxxxxxx used less than 100MB of bandwidth in the last 15 days.
Due to this, the system doubled the cost of this container.

For example, if you have a 64MB container, it will now be counted as a 128MB container, due to inactivity.

underuse is punished?

will excessive users be flogged?

Neoon

@supple said:

@Fritz said:

Your container lxcxxxxxxx used less than 100MB of bandwidth in the last 15 days.
Due to this, the system doubled the cost of this container.

For example, if you have a 64MB container, it will now be counted as a 128MB container, due to inactivity.

underuse is punished?

will excessive users be flogged?

You are not using it, either use it or terminate it.
No, currently there is no flagging, nobody gets exciled.

Neoon

@Neoon said:

@Neoon said:

@Neoon said:
Maintenance announcement
Gonna upgrade the backend to a new debian release, on Sunday, at around 22:00 CET, the panel will be unavailable for about 30 minutes, tops.

After the Maintenance I checked a few things, I noticed that Console / Shell was partially broken on some nodes.
I pinned the issue down, however still working on a fix, no ETA currently, probably, some breaking change to hypervisor, despite its LTS.

A security issue has been fixed with this update, which has not been published yet.
As precaution, I also disabled Console / Shell for LXD nodes, probably it also affects LXD which hasn't been patched yet.

I have theoretically a fix, to make it work again, gimme some time to implement it though.
I just learned a few hours ago, what the actually cause is.

Fixed, lemme know if you have any issues still.

yyds

Not enough thanks to qualify

bbass

6c4a-7550-6a66-f0cd

bbass

0MB
0MB
Quota at zero

If you applied over Lowendtalk, you have to send me a DM, to get your Quota raised.
If you think this is a bug, you should also contact me over the Forum you applied initially.

I have this on my dashboard @Neoon

fadedmaple

feedback: The icon on the launch button depicts a missile striking a target, I think 🚀 looks more like a launch.

minitor

6271-773d-c846-d314

stxsh

4310-7ff8-2b9b-cd00

Starnberg

42a0-0868-5b79-5ee9

Looking forward to a small presence in Vilnius, thanks!