Synnefo

το μοντελο Image προστέθηκε. τα πεδία του είναι τα εξής:

• name (char)
• updated (date)
• created (date, παίρνει αυτόματα)
• state (παίρνει μια απο το tuple STATES)
• description (text)
• serverid (char)

• primary key: αυτό που παίρνει απο το django αυτόματα

Σχετικά με τα images, γράφω εδώ για να συνεχίσουμε τη συζήτηση που είχε ξεκινήσει στην τελευταία συνάντηση:

τα images ζουν ανεξάρτητα από servers. Ο χρήστης μπορεί αργότερα να ανεβάζει δικά του images.
Κάποια images έχουν προκύψει από servers, τους οποίους ο χρήστης έκανε snapshot.

Το API έχει ένα πεδίο serverId όταν επιστρέφει πληροφορίες ενός image.
Η τρέχουσα υλοποίηση του GUI συμπεραίνει από αυτό το πεδίο αν το image είναι standard/public ή custom.
Αν έχει serverId, τότε είναι custom, αλλιώς είναι standard.
Αυτό είναι σύμφωνο με το παράδειγμα της σελ. 42 v.1.1 του RS API.

Οπότε το ερώτημα είναι: πώς θα απαντάει το API ότι ένα image είναι standard, custom [από συγκεκριμένο server],
ή custom [ανεβασμένο από το χρήστη]; Θα μπορούσε να χρησιμοποιεί το serverId όπως τώρα:

Τι τύπου θα είναι το serverId στη βάση; θα είναι foreign key στα VMs;

• το serverId είναι του ίδιου τύπου με τα id που δίνει το Django, παίρνει τιμή από το id του VM από το οποίο φτιάχτηκε.
• δεν είναι foreign key, γιατί το vm μπορεί να φύγει, το serverId πρέπει να μένει, για να δείχνει ότι το image είναι custom.
• το API απαντάει με την τιμή του serverId. Αν το image είναι ανεβασμένο, έχει serverId = 0.

• Ένα πεδίο description που θα περιγράφει σε human readable μορφή το image

• Metadata: Οι servers έχουν metadata. Ένα από αυτά θα είναι το "distro", το οποίο θα χρησιμοποιεί το GUI για να αποφασίζει τι είδους εικονίδιο να εμφανίζει, π.χ. Το θέμα είναι ότι και τα images πρέπει να έχουν ανάλογα metadata. Κάποιες τιμές του server προκύπτουν από το image, π.χ. το distro είναι ίδιο με του image από το οποίο φτιάχτηκε.

Ας μπουν κατ'ελάχιστο το description και τα metadata για να παίζει η έκδοση 1.0 και μετά βλέπουμε πώς προχωράμε.

Αν αρχίσουμε να αντιγράφουμε δεδομένα από τα VMs στα Images, τότε μάλλον έχουμε πρόβλημα. Αρχικά συζητούσαμε για το serverId μόνο, αλλά αν θέλουμε και το distro και πιθανώς και άλλο, ανοίγουμε την πόρτα σε inconsistencies.

Αν συνεπώς πραγματικά αυτά τα δύο μοιράζονται δεδομένα, και όχι μόνο ένα κλειδί, τότε τα κοινά δεδομένα τα βγάζουμε από τα VMs σε έναν άλλο πίνακα, π.χ. VMConfiguration. Ο πίνακας VMs έχει foreign key στο VMConfiguration, όπως και το Images. Αν ένα VM παύει να υπάρχει, δεν σημαίνει ότι χάνουμε το configuration, αφού αυτό αποθηκεύεται στο VMConfiguration. Επιπλέον, αν τα configurations επαναλαμβάνονται μεταξύ VMs (πολύ πιθανό, πολλά VMs έχουν το ίδιο configuration) θα γλυτώσουμε πολύ χώρο.

Όχι Πάνο, νομίζω δεν ισχύει αυτό.

Τα VMs και τα Images δεν μοιράζονται δεδομένα.
Κάποια από τα metadata του ενός είναι λογικό να αρχικοποιούνται από metadata του άλλου, αλλά αυτό αφορά μόνο την αρχικοποίηση, λόγω του τρόπου που κατασκευάζονται. Ως αντικείμενα ζουν ανεξάρτητα κι έχουν δυνητικά εντελώς διαφορετική πορεία:

• Από ένα image μπορώ να κατασκευάσω ένα VM. Άπαξ και το κατασκεύασα, έχει δική του πορεία.
• Από ένα VM μπορώ να κατασκευάσω ένα image ως snapshot του [αργότερα, όχι στην 1.0, αλλά πρέπει να μπορώ]. Άπαξ και φτιαχτεί έχει τη δική του πορεία.

Είναι λογικό και τα δύο να έχουν ένα μεταδεδομένο του τύπου "distro" ή καλύτερα "os", ώστε να ξέρουμε τι έχουν μέσα [images] ή τι λειτουργικό τρέχουν [VM]. Και στις δύο περιπτώσεις, η τιμή του δεδομένου θα αρχικοποιείται στην τιμή αυτού απ'όπου αντιγράφηκε:

• Ένα VM που φτιάχτηκε από Image με os="Windows" τρέχει Windows και θα εμφανίζεται με εικονίδιο Windows. Τώρα αν ο χρήστης το διαλύσει, δεν πειράζει, μπορεί να αλλάξει με κλήση του API την τιμή του μεταδεδομένου. Καθ'όλη αυτή τη διαδικασία το Image δεν επηρεάζεται, ούτε τα δεδομένα ούτε τα metadata του αλλάζουν.

• Ένα Image που φτιάχνεται από VM που έχει os="Windows" πρέπει να εμφανίζεται με εικονίδιο Windows, γιατί είναι ένα snapshot μιας εγκατάστασης Windows.

Οπότε δεν μοιράζονται data ή metadata. Έχει η κάθε οντότητα τα δικά της, που μεταβάλλονται χωριστά.
Το μόνο, ίσως μπορούμε να έχουμε ένα πεδίο να δείχνει από το ένα αντικείμενο στο άλλο, δηλαδή ένα VM έχει imageId για να ξέρουμε από ποιο image προήλθε κι αντίστοιχα ένα imageId έχει serverId για να ξέρουμε από ποιον server προήλθε, αλλά η προέλευση μπορεί να σβηστεί ανά πάσα στιγμή κι αυτό δεν επηρεάζει τη ζωή του αντικειμένου: αν σβήσω το VM απ'όπου είχα φτιάξει ένα image δεν τρέχει τίποτε, αυτό το image υπάρχει κι είναι αυτόνομο, είναι το backup μου. Αντίστοιχα, αν σβήσω το image απ'όπου έφτιαξα ένα VM, δεν τρέχει τίποτε, γιατί το VM είναι εδώ, ζει και τρέχει.

Οπότε, τα πεδία VM.imageId και Image.serverId δεν έχει νόημα να είναι καν foreign keys.

ΟΚ λογικό. Οι χρήστες μόνο θα πρέπει να κατανοήσουν πως το ότι το όνομα ενός VM αναφέρεται από ένα Image δεν σημαίνει ότι το VM αυτό υπάρχει, ή ότι μπορούν με οποιονδήποτε τρόπο να το ανακτήσουν, σε περίπτωση που δεν υπάρχει πια. Για να γλυτώσουμε επαφές με το helpdesk του τύπου: "θέλω αυτό το VM από όπου ήρθε αυτό το Image, τι μου λέτε ότι δεν υπάρχει, αφού εδώ το βλέπω το όνομά του, δεν μπορείτε να μου το φέρετε πίσω;".

Panagiotis Louridas wrote:

ΟΚ λογικό. Οι χρήστες μόνο θα πρέπει να κατανοήσουν πως το ότι το όνομα ενός VM αναφέρεται από ένα Image δεν σημαίνει ότι το VM αυτό υπάρχει

Έχεις απόλυτο δίκιο. Βασικά, θα μπορούν να βλέπουν την προέλευσή του μόνο αν υπάρχει το συγκεκριμένο αντικείμενο, γιατί δεν θα αποθηκεύουμε όνομα, μόνο το Id. Αν δεν υπάρχει το αντικείμενο αυτού του Id, το join δεν θα βγάζει τπτ. Το μήνυμα πρέπει να είναι του στυλ
"Image: Source Machine: myserver-1"
και
"Image: Source Machine: does not exist anymore."

Πρόσθεσα το πεδίο size στο Image που δείχνει το μέγεθος του Image σε MBs.
Πρέπει να φύγει το πεδίο vm_id και η μέθοδος get_vmid από τη στιγμή που υπάρχει το πεδίο @sourcevm στο Image model.