FAQ

How can I contact Leafcloud support?

For support using your Leafcloud account or questions regarding availability, you can contact Leafcloud by email at hello@leaf.cloud

Additionally, you can call +31(0)202443794 during business hours (GMT+1)

Also, please ask us to invite you to our slack channel.

‍

How can I reset my password?

If you’ve lost your password, you can reset your password here.

‍

What type of GPUs does Leafcloud offer?

Leafcloud offers the following GPUs:

NVIDIA V100
NVIDIA A30 (latest generation!), available now on request

How long do my free credits last?

You receive €100 in free credits upon creating your Leafcloud account. Any of these credits that remain unspent last for 15 days.

Can I use my free credits for Leafcloud GPUs?

The €100 in free credits you receive upon creation of your account cannot be used for Leafcloud GPUs

‍

How long does my free trial period last?

Your free trial period lasts for 15 days after you have created your account, or once your €100 in free credit has been spent.

What happens after my free trial period expires?

After your free trial period has expired, you will be billed for the use of Leafcloud services in accordance with our pricing model. For more information about the various costs of our services, visit our Pricing page

Will I need to fill in my credit card details to create an account?

Yes, to create a Leafcloud account, you must fill in your credit card details as requested in the sign-up form. Leafcloud will not bill you until your free credits have been used up or have expired. For more information about the various costs of our services, visit our Pricing page.

Are all listed prices for Leafcloud services excluding VAT?

Yes, all prices listed on our website exclude VAT. For VAT-included pricing, please get in touch with us directly.

info@leaf.cloud

Why cannot I send mail from my server? Port 25 is blocked

At Leafcloud we do our best to make sure your cloud environment is safe and secure. For this reason, we block all outgoing SMTP (E-mail) originating from customers by default. This helps us fight people sending SPAM from our network, and prevents your e-mails from being blocked by blacklists.

What does this mean for you?

For most customers, this has no effect. But if you have a service configured to automatically send e-mail, for example, to reset a password from your site, or send notifications you may see that these e-mails are not delivered.

What if you need to send e-mail from your server?

If you have a need to send an e-mail from your server you typically don't need to send e-mail directly to the recipient. Services such as SendGrid and Mailjet offer relay services with authentication on open port numbers that offer a solution for this problem. They have free tiers that typically suffice for such use-cases.

If you prefer direct e-mail delivery we can also make an exception for you in our firewall. Please get in touch through support, and we'll be happy to set that up for you.

hello@leaf.cloud

How do I see information about my next bill

To get a forecast of your next monthly bill you can check your ‘rating’ on the Leafcloud cloud control panel. Prices listed are in Euro’s and before any discounts.

‍

Are my quotas upgradeable?

Yes, upgraded or expanded quotas are available on request. If you need your quota expanded, you can contact us at hello@leaf.cloud.

Can I extend the disk space of an instance that is already running?

Yes, you can extend the disk space of an instance that is already running.

The safest and most flexible way to do this requires multiple Volumes and a bit of planning.

Follow the steps below. You can find step-by-step guides to various sections here, in our documentation.

Step 1: Create an instance.
Step 2: Create an extra Volume and attach it to your new instance.
Step 3: Create an LVM Volume group on the new disk:

vgcreate /dev/MyVG01 /dev/vdb

Step 4: Create a Logical Volume on the new Volume group:

lvcreate -L +9G --name test MyVG01

Step 5: Create an extra partition in the new Logical Volume:

mkfs -t ext4 /dev/MyVG01/test

Step 6: Mount it:

mkdir /mnt/test; mount -rw /dev/MyVG01/test /mnt/test

Step 7: Make a new Volume and attach it to the instance. Then, extend the Volume group:

vgextend /dev/MyVG01 /dev/vdc

Step 8: Extend the Logical Volume:

lvextend -L +11G /dev/MyVG01/test

Step 9: Resize the partition to its maximum size:

resize2fs /dev/MyVG01/test

Alternatively, you can use a quicker and riskier approach. It is possible to apply something akin to:

OS_VOLUME_API_VERSION=3.42 cinder extend <volume_id><SIZE_IN GB>see: https://docs.leaf.cloud/en/latest/volumes/Extending-a-bootable-volume.html

However, this solution runs the risk of causing data loss and is not recommended.

‍

Can I use Let's Encrypt with a Kubernetes load balancer?

Yes, you can use Let's Encrypt with a Kubernetes load balancer by using ingress-nginex in combination with certbot certmanager as described below.

First, run:

~~~
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.45.0/deploy/static/provider/cloud/deploy.yaml
~~~

This will create a new namespace called ingress-nginex, inside which the nginex controller is deployed.

Next, run:

~~~
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: <your-project>-ingress
namespace: <your-project>
annotations:
cert-manager.io/issuer: "letsencrypt-prod"
kubernetes.io/ingress.class: "nginx"
spec:
tls:
- hosts:
- join.leaf.cloud
secretName: <your-project>-ingress-tls
rules:
- host: join.leaf.cloud
http:
paths:
- path: /
pathType: Prefix
backend:
serviceName: <your-project>-entrypoint
servicePort: 8000
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
namespace: <your-project>
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: my@email.com
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx
~~~

How do I gain access to my Kubernetes cluster?

First, enter the following:

~~~
openstack coe cluster config my-k8s-cluster
export KUBECONFIG=/home/<username>/config
~~~

Now, kubectl should have access to your Kubernetes cluster. To validate this, enter:

~~~
kubectl get nodes -o wide
~~~

This should list the pods that your Kubernetes cluster is running.

Check [here](https://docs.leaf.cloud/en/latest/kubernetes/creating-a-kubernetes-cluster.html#create-a-cluster) for more information.

‍

Can I schedule the backups of my PostgreSQL database?

###

Yes, you can do this by configuring Leafcloud S3 compatible Object Storage in pgo.yml. To do this, follow the steps below:

**Step 1: create credentials for the ec2 compatible Leafcloud API**

First, you need to create credentials for the ec2 compatible Leafcloud API:

~~~
openstack ec2 credentials create
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| default_project_id | 17e5a06a7ce34sjfu5b6e0eejt00663c |
| domain_id | default |
| enabled | True |
| id | d407b0kckdu3994j5jjg8403c0973cf9 |
| name | myuser |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
~~~

~~~
Cluster:
BackrestS3Bucket: my-postgresql-backups-example
BackrestS3Endpoint: leafcloud.store
BackrestS3Region: europe-nl-ams1
BackrestS3URIStyle: host
BackrestS3VerifyTLS: true
~~~

Click [here ](https://access.crunchydata.com/documentation/postgres-operator/4.7.2/architecture/disaster-recovery/#using-s3)for more information.

**Step 2: Schedule your backups**

Second, schedule your backups as follows:

~~~
pgo create schedule hacluster --schedule="0 1 * * *" \
--schedule-type=pgbackrest --pgbackrest-backup-type=full

pgo create schedule hacluster --schedule="0 */3 * * *" \
--schedule-type=pgbackrest --pgbackrest-backup-type=incr
~~~

Click [here](https://access.crunchydata.com/documentation/postgres-operator/4.7.2/pgo-client/common-tasks/#disaster-recovery-backups-restores) for more information.

Why does the autohealer kick in when I didn't intend it to?

The autohealer will replace instances that become unreactive, for example, because they run out of memory.

you can disable it by entering the following:

~~~
kubectl -n kube-system patch daemonset magnum-auto-healer -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
~~~

How do I disable the cluster-autoscaler?

You can disable your cluster autoscaler as follows:

~~~
kubectl -n kube-system scale deployment cluster-autoscaler --replicas=0
~~~

I set a key-pair for the cluster, but I cannot ssh to the instances with that key-pair.
Also, they are not visible in the dashboard for instances, why is this?

the user that you would probably need is:

~~~
core
~~~

To get it, enter the following command:

~~~
ssh -I ~/.ssh/id_rsa core@45.135.56.227
~~~