Beiträge von [netcup eos] Thorsten L.

Hallo!

Vielen Dank für die Rückmeldung. Die API-Doku werden wir zum späteren Zeitpunkt natürlich entsprechend nachziehen.

Viele Grüße,
Thorsten

gunnarh Vielen Dank für die Infos!

Die Dokumentation erwähnt nun, dass eine Vergrößerung der root Parition automatisch von statten geht.

Mit einen normalen Debian 13 Image (kein cloud-init) haben wir folgendes gemacht um dein gewünschtes Verhalten zu erzielen:

root@debian13:~# fdisk --list /dev/sda
Disk /dev/sda: 9.31 GiB, 10000000000 bytes, 19531250 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: BC10FD36-4B98-4C07-BA7B-0A789A02EEA2
Device      Start      End  Sectors  Size Type
/dev/sda1    2048   206847   204800  100M EFI System
/dev/sda2  206848 19531216 19324369  9.2G Linux filesystem

# Check der installierten incus units:
root@debian13:~# systemctl list-units --all | egrep -i "incus|grow"
 dev-disk-by\x2did-scsi\x2d0QEMU_QEMU_HARDDISK_incus_root.device                                                                           loaded    active   plugged   QEMU_HARDDISK
 dev-disk-by\x2did-scsi\x2d0QEMU_QEMU_HARDDISK_incus_root\x2dpart1.device                                                                  loaded    active   plugged   QEMU_HARDDISK UEFI
 dev-disk-by\x2did-scsi\x2d0QEMU_QEMU_HARDDISK_incus_root\x2dpart2.device                                                                  loaded    active   plugged   QEMU_HARDDISK rootfs
 dev-virtio\x2dports-org.linuxcontainers.incus.device                                                                                      loaded    active   plugged   /dev/virtio-ports/org.linuxcontainers.incus
 run-incus_agent.mount                                                                                                                     loaded    active   mounted   /run/incus_agent
 incus-agent.service                                                                                                                       loaded    active   running   Incus - agent
 incus-growpart.service                                                                                                                    loaded    inactive dead      Incus - grow root partition

# Disable des growpart service:
root@debian13:~# systemctl disable incus-growpart.service
Removed '/etc/systemd/system/default.target.wants/incus-growpart.service'.

# Sicherstellen dass kein cloud-init installiert ist:
root@debian13:~# dpkg -l | grep cloud-init

root_volume in der UI vergrößert und wie folgt eine neu partition angelegt

# Neue parition anlegen
root@debian13:~# fdisk /dev/sda
Welcome to fdisk (util-linux 2.41.5).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

Command (m for help): n
Partition number (3-128, default 3): 
First sector (19531217-29296841, default 19531776): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (19531776-29296841, default 29296639):
Created a new partition 3 of type 'Linux filesystem' and of size 4.7 GiB.
Command (m for help): w
The partition table has been altered.
Syncing disks.
# check
root@debian13:~# fdisk --list /dev/sda
Disk /dev/sda: 13.97 GiB, 15000000000 bytes, 29296875 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: BC10FD36-4B98-4C07-BA7B-0A789A02EEA2
Device        Start      End  Sectors  Size Type
/dev/sda1      2048   206847   204800  100M EFI System
/dev/sda2    206848 19531216 19324369  9.2G Linux filesystem
/dev/sda3  19531776 29296639  9764864  4.7G Linux filesystem

Je nach Image kann es natürlich sein, dass man sowohl incus-growpart.service deaktivieren und auch die von dir erwähnte cloud-init.cfg anpassen muss.

Hast du das Ubuntu image mit oder ohne cloud init verwendet ?


Danke für die Rückmeldung,
Thorsten

Hallo!

Stop der VM läuft nun auch ohne agent über ACPI.
Bitte um kurze Rückmeldung ob es bei euren VMs auch funktioniert.

Viele Grüße,
Thorsten

Hallo!

Vielen Dank für das Feedback und die ausführliche Darstellung des Anwendungsfalls.

Bei root_volumes ist die aktuelle Implementierung bewusst so vorgesehen, dass bei einer Vergrößerung des Volumes auch die vorhandene Partition und das Dateisystem entsprechend erweitert werden. Dieses Verhalten ist insbesondere für die üblichen Anwendungsfälle gewünscht und orientiert sich an den Anforderungen der Mehrheit unserer Kunden.

Für Szenarien, in denen die zusätzliche Kapazität beispielsweise für eine oder mehrere separate Partitionen oder für LVM verwendet werden soll, sind weitere Volumes die vorgesehene Möglichkeit, dies entsprechend flexibel abzubilden. LVM sowie individuelle Partitionierungen und deren anschließende Vergrößerung lassen sich damit umsetzen, ohne dass das Verhalten von root_volumes dafür angepasst werden muss.

Falls bei einem root_volume die automatische Erweiterung der Partition und des Dateisystems nicht gewünscht ist, kann das automatische Wachstum auch gezielt deaktiviert werden. Dazu kann vor der Vergrößerung des Volumes der incus-growpart.service deaktiviert werden. Dadurch bleibt der zusätzlich bereitgestellte Speicher zunächst unpartitioniert und kann anschließend entsprechend der individuellen Anforderungen, beispielsweise für LVM oder zusätzliche Partitionen, verwendet werden.

Uns ist bewusst, dass es darüber hinaus weitere Anwendungsfälle gibt. Die aktuelle Implementierung deckt bewusst die häufigsten Szenarien ab. Für darüber hinausgehende Anforderungen besteht die Möglichkeit, diese über die entsprechenden Volume-Konfigurationen bzw. eine andere Aufteilung der Volumes umzusetzen.

Vielen Dank nochmals für das Feedback!

Viele Grüße,
Thorsten

Hallo!

Mittlerweile sollte die API stats nur noch einmal in den _actions zurückliefern. Außerdem implementiert die neueste Version von eosctl die bislang fehlenden Commands.

Ein Beispiel hierfür ist:

eosctl compute vm stats <vm-id>

Bitte um eine kurze Rückmeldung, ob damit alles wie erwartet funktioniert.

Viele Grüße
Thorsten

Hallo,

die neueste Version von eosctl behebt dieses Problem und sorgt für eine höhere Konsistenz.

Ich freue mich über eine kurze Rückmeldung, ob das Problem damit behoben ist.

Viele Grüße
Thorsten

Hallo!

Vielen Dank für eine Rückmeldung.
Wir nehmen deinen Vorschlag in die interne Diskussion und Planung auf.

Viele Grüße,
Thorsten

Hallo!

Danke für den Report.
Wir werden uns das genauer ansehen und hier Rückmeldung zu dem Thema geben.

Viele Grüße,
Thorsten

Hallo!

Vielen Dank für den Report.
Wir werden es uns ansehen und zeitnah eine Lösung dafür bereitstellen.

Viele Grüße,
Thorsten

Hallo!

Das Thema mit den mehrfachen Verzeichnissen sollte in den neuesten Versionen erledigt sein.

terence Bitte um kurze Rückmeldung obs das bei dir nun auch funktioniert.

Viele Grüße,
Thorsten

Hallo!

Vielen Dank für den Hinweis. Wir werden noch terraform-provider-eoscloud und eoscloud-mcp nachbessern und dann enstprechend die Dokumentation anpassen.

Viele Grüße,
Thorsten

Hallo!

Die neue version von eosctl schiebt die configurationen in nur ein Verzeichnis: $XDG_CONFIG_HOME/eosctl
Beim erneuten verwenden wird $HOME/.eosctl in $HOME/.eosctl.old umbenannt und kann dann gelöscht werden.

Viele Grüße,
Thorsten

Hallo!

Mit der neuesten Version von eosctl sollte dies nun behoben sein.

Viele Grüße,
Thorsten

Hallo,

wir werden das Thema intern in unsere Priorisierung aufnehmen und prüfen, wie wir die Darstellung künftig weiter verbessern können.

Viele Grüße
Thorsten

Hallo!

Vielen Dank für deine Rückmeldung.

Könntest du mir bitte noch weitere Informationen dazu zur Verfügung stellen? Insbesondere würde mich interessieren, welche EOS_*-Umgebungsvariablen du gesetzt hast und mit welchen Werten.

Der Standardpfad für alle eoctl-Daten ist normalerweise $HOME/.eosctl.

Vielen Dank vorab!

Viele Grüße
Thorsten

Hallo!

Wenn du in den entsprechenden Bereich scrollst sollte man links im Menü mit Farbe hinterlegt sehen um welche Methode es sich handelt:
image.png


Die Möglichkeit es explizit darstellen werden wir intern diskutieren und halten euch hier auf dem laufenden.

Viele Grüße,
Thorsten

Hallo!

Vielen Dank für den Vorschlag und den Hinweis. Wir werden diesen bei der Weiterentwicklung berücksichtigen und prüfen, ob sich die gewünschte Funktion in zukünftigen Produktversionen sinnvoll umsetzen lässt.

Vielen Dank für das konstruktive Feedback und viele Grüße,

Thorsten

Hallo!

Vielen Dank für die Rückmeldung.

Wir werden die API-Dokumentation in Compute entsprechend anpassen.

Viele Grüße,
Thorsten

Hallo!

Vielen Dank für deine Rückmeldung. Wir werden diese bei zukünftigen Produktentscheidungen entsprechend berücksichtigen.

Voraussichtlich werden künftig noch weitere Produkte folgen. Welche Produkte dies konkret sein werden und in welcher Reihenfolge sie eingeführt werden, steht zum aktuellen Zeitpunkt jedoch noch nicht fest.

Viele Grüße,
Thorsten

Hallo zusammen!

Vielen Dank für eure Rückmeldungen.

Die Möglichkeit, nach einem bereits vergebenen Beschreibungstext/Label zu suchen, halte ich für sehr sinnvoll. Auch die von euch vorgeschlagene Darstellung gefällt mir gut.

Wir werden intern die Priorisierung sowie mögliche Umsetzungsoptionen besprechen und euch anschließend über das weitere Vorgehen auf dem Laufenden halten.

Viele Grüße