Synnefo

Η απάντηση του Κωνσταντίνου στο #541 μου έλυσε και αυτήν την απορία, ευχαριστώ.

Κάνοντας διάφορα εδώ έχω συναντήσει το παρακάτω θέμα.

Η αρχική μου ιδέα ήταν να κάνω διαρκώς GET networks/detail και να ενημερώνω τη λίστα όπως και στα machines. Ωστόσο λείπουν πληροφορίες που της έχει μόνο στο GET servers/detail. Η αλήθεια είναι ότι η δεύτερη κλήση θα πρέπει να γίνεται συνεχώς ούτως ή άλλως ώστε να ενημερώνεται το ui για τυχόν αλλαγές στην κατάσταση των μηχανημάτων, πχ delete, stop κλπ. Η μόνη πληροφορία που δεν έχει το servers/detail ακι την έχει μόνο η networks/detail είναι τα ονόματα των ιδιωτικών δικτύων.

Για τον παραπάνω λόγο θα χρειαστεί να κάνω δύο επαναλαμβανόμενα calls ένα GET networks/detail και ένα GET servers/detail. Εάν αυτό δεν σας προκαλεί θέμα λόγω αύξησης του load να συνεχίσω έτσι. Διαφορετικά η μόνη λύση που βλέπω είναι να αλλάξει το api έτσι ώστε η μία από τις δύο κλήσεις, πιθανότατα η servers/detail, να επιστρέφει όλα τα δεδομένα που πρέπει να απεικονιστούν στο networks section.

Έχεις δίκιο. Η βασική κλήση είναι η GET /servers/detail. Από εκεί μπορείς να έχεις ποια μηχανήματα υπάρχουν, σε ποια δίκτυα είναι συνδεδεμένα, IPs / MACs για κάθε σύνδεση. Οπότε, όταν μια τέτοια κλήση επιστρέψει νέα δεδομένα (όχι HTTP 304 NOT MODIFIED), μπορείς να ανανεώνεις το view. Η δεύτερη κλήση, GET /networks/detail χρειάζεται για τα ονόματα των ιδιωτικών δικτύων, τα οποία αν καταλαβαίνω καλά δεν επιστρέφει η /servers/detail, αν κάνω λάθος ο [verigak] με διορθώνει.

Οπότε, ναι, περιοδικά θα γίνονται δύο κλήσεις όταν είναι στο networks tab, μία για /servers/detail [όλη η πληροφορία που ουσιαστικά παρουσιάζεται], μία για /networks/detail [τα ονόματα των δικτύων].

Να προσθέσω άλλα δύο θέματα εδώ:

1. Όταν σβήσω ένα ιδιωτικό δίκτυο που περιέχει κάποιον server, τότε η server details μου λέει ότι το status του server είναι unknown και σαν συνέπεια στη λίστα των μηχανημάτων φαίνονται πλέον ώς ανενεργά.

2. Δεν υπάρχει κάποιο state στα δίκτυα που να μου επιτρέπει να καταλάβω εάν έχουν σβηστεί ή όχι. Οπότε την επόμενη φορά που το δίκτυο θα πάρει κάποιο change δε θα ξέρω εάν είναι νέο ή σβησμένο.

Συνεχίζοντας εδώ,

1. Όταν ένα μηχάνημα είναι σταματημένο, τότε θεωρούμε ότι έχει ips, public και private? Θα πρέπει να εμφναίζεται στα αντίστοιχα δίκτυα;
2. Υπάρχουν κάποια δημόσια ip που δεν θεωρούνται έγκυρα, πχ 0.0.0.0 (v4), και αν ναι ποια; Σε αυτήν την περίπτωση θα πρέπει να μπαίνουν μόνο στα ιδιωτικά δίκτυα οι συγκεκριμένοι σέρβερ;
3. Αυτό που δεν μπορώ να δοκιμάσω από την δική μας πλευρά είναι το τί γίνεται εάν ένας χρήστης συνδεθεί, πχ με ssh, σε κάποιο μηχάνημα και αλλάξει από κει την public ip του. Για να προχωρήσω θα το κάνω χωρίς να το έχω δοκιμάσει.

Επίσης να θυμίσω λίγο και το σημείο 10 παραπάνω, μάλλον παράπεσε ανάμεσα στα υπόλοιπα.

Christos Psaltis wrote:

Συνεχίζοντας εδώ,

Με διορθώνει ο [verigak] αν κάτι ξεφύγει.

1. Όταν ένα μηχάνημα είναι σταματημένο, τότε θεωρούμε ότι έχει ips, public και private? Θα πρέπει να εμφναίζεται στα αντίστοιχα δίκτυα;

Δεν παίζει ρόλο αν το μηχάνημα είναι σταματημένο. Αν είναι συνδεδεμένο με κάποιο δίκτυο, αυτό θα εμφανίζεται στην απάντηση /servers/detail.
Το μηχάνημα θα πρέπει να εμφανίζεται κανονικά, σβησμένο ή αναμμένο, στα δίκτυα στα οποία το GET /servers/detail το εμφανίζει συνδεδεμένο.
Εδώ βολεύει να υπάρχει κάποια οργάνωση Model-View-Controller στο UI: το UI κρατάει κάπου την κατάσταση των servers και των δικτύων (Model), η Javascript με ?changes-since τα ανανεώνει περιοδικά (Controller) και φτιάχνει από αυτά Views (HTML5, DOM) για να τα δείχνει.

2. Υπάρχουν κάποια δημόσια ip που δεν θεωρούνται έγκυρα, πχ 0.0.0.0 (v4), και αν ναι ποια; Σε αυτήν την περίπτωση θα πρέπει να μπαίνουν μόνο στα ιδιωτικά δίκτυα οι συγκεκριμένοι σέρβερ;

Το UI εμφανίζει ακριβώς ότι του επιστρέφει το API. Άμα το API του πει ότι ένα μηχάνημα έχει IPv4 0.0.0.0 σε ένα δίκτυο, θα γράφει 0.0.0.0.
Αν κάποιο attribute δεν υπάρχει, ας το εμφανίζει κενό.

3. Αυτό που δεν μπορώ να δοκιμάσω από την δική μας πλευρά είναι το τί γίνεται εάν ένας χρήστης συνδεθεί, πχ με ssh, σε κάποιο μηχάνημα και αλλάξει από κει την public ip του. Για να προχωρήσω θα το κάνω χωρίς να το έχω δοκιμάσει.

Δεν γίνεται τίποτε. Οι χρήστες δεν έχουν δικαίωμα να αλλάζουν IPs μέσα στο μηχάνημα. Αν το κάνουν δεν θα έχουν δίκτυο.
Υπάρχει ένας ολόκληρος μηχανισμός από πίσω, δεν είναι μόνο ό,τι βλέπετε στο API. Ο μηχανισμός αυτός ξέρει τι IPs έχουν ανατεθεί, τις απαντάει με DHCP, και αν κάποιος καρφώσει άσχετη IP με το χέρι, δεν μπορεί να δρομολογήσει πακέτα προς το δίκτυο. Οπότε δεν υπάρχει λόγος να σας απασχολεί αυτό.

Επίσης να θυμίσω λίγο και το σημείο 10 παραπάνω, μάλλον παράπεσε ανάμεσα στα υπόλοιπα.

Αν λες το σημείο (1), έχω ανοίξει το #571 για το UI (χειρισμός κατάστασης "UNKNOWN") και προσπαθώ να δω γιατί συμβαίνει έτσι κι αλλιώς αυτό στο API, αν έχετε reproducible τρόπο στείλτε.

οκ με όσα λες.

Δεν αναφερόμουν στο 11, που άνοιξαν τα tickets, αλλά στο σημείο 10. Εκεί ρωτάω τί γίνεται με το action disconnect στους servers των δημοσίων δικτύων και το action details στους servers και των δύο τύπων δικτύων.

Christos Psaltis wrote:

Δύο ερωτήματα σχετικά με τις ενέργειες σε μηχανήματα στο networks:

1. Όταν ένας server γίνεται disconnected από το public network τί θα πρέπει να γίνεται με τις ip του; Από ότι βλέπω δεν υπάρχει κάποια κλήση που μπορεί να τροποποιήσει public ips, ούτε στο openstack api ούτε στο δικό μας implementation. Μου διαφεύγει κάτι;

Όχι, δεν μπορεί να γίνει disconnected από το public δίκτυο, ούτε υπάρχει κλήση που να τροποποιεί public IPs, τα πάντα στο δημόσιο δίκτυο θεωρούμε ότι αποφασίζονται από το API.

Αν κάποιος δεν θέλει υποστήριξη για δημόσιο δίκτυο, υπάρχουν firewall profiles, αύριο θα είναι διαθέσιμη τεκμηρίωση για τη χρήση τους από τον [verigak].

2. Tο action details σε servers στο public network ή σε κάποιο private τί θα πρέπει να επιστρέφει; Το GET server details; Και αν ναι πώς θα πρέπει να φαίνεται αυτό;

Θα απαντήσει ο Κωνσταντίνος σε αυτό.

To details θα πρέπει να τον πετάει στο αντίστοιχο single view του συγκεκριμένου machine

Ακόμα μία ερώτηση εδώ.

Το edit action στα ιδιωτικά δίκτυα κάνει:
α) rename το δίκτυο;
β) τίποτα, αλλά πρέπει να μείνει;
γ) τίποτα και πρέπει να φύγει;
δ) κάτι άλλο

τίποτα και πρέπει να φύγει. Το rename γίνεται με μολυβάκι ακριβώς όπως και στο machines

Αυτό θα το αλλάξουμε, θα είναι id="public" για το δημόσιο δίκτυο, id=κάτι-άλλο-μοναδικό για τα ιδιωτικά δίκτυα.

Και στα docs του openstack αυτό είναι πολύ θολό: δεν φαίνεται υποχρεωτικό να υπάρχει καν id="public", το id είναι απλώς ένα id.
Από την άλλη πλευρά, στην τρέχουσα έκδοση του API τους δεν έχουν και τη δυνατότητα να δημιουργήσει ο χρήστης δικά του δίκτυα. Οπότε τους αρκούσε ένα σταθερό id="public" κι ένα id="private", προδιαγεγραμμένα.

Δοκιμάζω τώρα το αποτέλεσμα του merge, θα ανοίξω ότι tickets προκύψουν.

Εδώ έγιναν τα θ2, θ3

Ναι, τα θ2, θ3 φαίνεται πως είναι ΟΚ τώρα.

Υπάρχουν ακόμη κάποια θέματα, π.χ. τώρα έχω φτιάξει ιδιωτικό δίκτυο, το βλέπω με cloud lsnet, δεν εμφανίζεται καθόλου στο UI. [API και UI που τρέχει στο 62.217.120.67:8000].

Οπότε, για να κλείσουμε το ζήτημα του merge, παρακαλώ κάντε μια περιήγηση στο networks tab κι επιβεβαιώσετε ότι γενικότερα δουλεύει σωστά, ώστε να το δω μια και καλή.

πράγματα, τα δίκτυα έοχυν εμφανίσει προβλήματα που δεν έβλεπα πριν (φαντάζομαι μετά τo merge με το api-current). Μόλις διορθωθούν, θα το γυρίσω σε feedback για να γίνει συνολικός έλεγχος πριν κλείσει.

Εντάξει και το θ1 στο commit:9bb263c1, εδώ έχουμε πάλι μια εμφάνιση του #317. Η λύση είναι προσωρινή καθώς δεν επιτρέπει σωστό error reporting και θα πρέπει στο 0.5 να βρούμε κάποιον τρόπο να το λύσουμε μια και καλή αυτό.

Δεν έχει κλείσει εντελώς το ticket αυτό, θα ενημερώσω σε λίγο.

Επίσης σχετικά με το πρόβλημα που αναφέρεται στο σημείο 26 πιο πάνω, δεν κατάφερα να το αναπαράγω τοπικά και το 62.217.120.67:8000 μου δίνει 502.

Christos Psaltis wrote:

Επίσης σχετικά με το πρόβλημα που αναφέρεται στο σημείο 26 πιο πάνω, δεν κατάφερα να το αναπαράγω τοπικά και το 62.217.120.67:8000 μου δίνει 502.

Το έχω τώρα να τρέχει, συνδέσου.
Υπάρχουν δύο ιδιωτικά δίκτυα, το "new1" και το "aa1".
Όταν πρωτομπαίνω στο network tab, μου βγάζει μόνο το public δίκτυο "Internet".

Τώρα βλέπω ότι αν το αφήσω ~5 δευτερόλεπτα βγάζει και τα υπόλοιπα από κάτω. Αλλά θα περίμενε κανείς αυτά να βγαίνουν όλα μαζί, στην αρχή.

Κι ένα τελευταίο: το public δίκτυο έχει id="public", το API έχει ανανεωθεί ώστε να το κάνει σωστά αυτό.
Τα ονόματα είναι user-manageable πράγματα (το attribute "name") ας μην βασίζεται το UI σε αυτό.

Νομίζω ότι με το commit:4667a575 έχει λυθεί αυτό. Μπορείτε να κάνετε ένα pull και να το δω ξανά;

Έγινε pull, δες το γιατί δεν παίζει καθόλου

Επίσης, το networks tab δεν ανανεώνεται σωστά. Και πάλι καθυστερεί σημαντικά να ανανεωθεί, απλώς βγάζει το spinner στο ενδιάμεσο.

Έχε υπόψη ότι το κάθε πότε κάνει poll τελικά θα είναι configurable και θα αλλάξει αρκετές φορές από τους διαχειριστές μέχρι το τελικό deployment. Αυτό, γιατί είναι trade-off ανάμεσα στην αποκρισιμότητα του interface (πόσο γρήγορα τσιμπάει τις αλλαγές) και τον φόρτο στην υπηρεσία.

Οπότε, θα μπορούσε να είναι και 20sec. Απ'ό,τι καταλαβαίνω, τώρα πρέπει να περιμένει κανείς κάποιους κύκλους για να δείξει όλα τα δεδομένα, χωρίς να υπάρχει λόγος. Τα δεδομένα πρέπει την πρώτη φορά να έρχονται σωστά, με τη μία, και μετά να ξεκινάει το refresh. Όπως θα έπρεπε [είχα την εντύπωση ότι έτσι συνέβαινε] να γίνεται και με τους servers.

Σε ποιο instance το δοκιμάζεις, γιατί τοπικά δεν μου προκαλείται ούτε με το tool ούτε με το ui. Την προσθήκη την κάνεις από το UI?

Christos Psaltis wrote:

Σε ποιο instance το δοκιμάζεις, γιατί τοπικά δεν μου προκαλείται ούτε με το tool ούτε με το ui. Την προσθήκη την κάνεις από το UI?

Δοκιμάζω στο 62.217.120.67:8000, με Opera.
Αν κάνεις tools/cloud ls θα δεις ότι ο ένας server που υπάρχει έχει κάρτα δικτύου στο ίδιο ιδιωτικό δίκτυο 4-5 φορές, μία για κάθε POST που έγινε.

Το φαντάστηκα ότι ήταν αυτό από το id του server και έκανα διάφορες δοκιμές χωρίς να καταφέρω να το αναπαράγω. Η κονσόλα του opera έδειχνε μόνο μία κλήση σε όλες τις δοκιμές που έκανα.

Μερικές σημειώσεις εδώ:

1. Το instance στην :8000 δεν είναι στην τελευταία έκδοση. Δε νομίζω ότι παίζει κάποιο ρόλο αυτό όμως.
2. Πώς κατάφερες να προσθέσεις μηχανές στο ιδιωτικό δίκτυο. Στο δικό μου instance δεν μπορώ να το κάνω ούτε με το tool, ούτε με το ui. Έχεις κάποια άλλη έκδοση με uncommited αλλαγές; Ίσως εκεί να έχουμε κάποιο θέμα.
3. Γιατί το api σου επιτρέπει να κάνεις πολλαπλά post με τον ίδιο server στο ίδιο δίκτυο; Υπάρχει κάποιος λόγος ή είναι κάτι που θα αλλάξει στο μέλλον;

Christos Psaltis wrote:

Το φαντάστηκα ότι ήταν αυτό από το id του server και έκανα διάφορες δοκιμές χωρίς να καταφέρω να το αναπαράγω. Η κονσόλα του opera έδειχνε μόνο μία κλήση σε όλες τις δοκιμές που έκανα.

Μερικές σημειώσεις εδώ:

1. Το instance στην :8000 δεν είναι στην τελευταία έκδοση. Δε νομίζω ότι παίζει κάποιο ρόλο αυτό όμως.

Σίγουρα; έκανα git pull και δεν έφερε κάτι, βασικά είναι στο commit:1c298d4d.

2. Πώς κατάφερες να προσθέσεις μηχανές στο ιδιωτικό δίκτυο. Στο δικό μου instance δεν μπορώ να το κάνω ούτε με το tool, ούτε με το ui. Έχεις κάποια άλλη έκδοση με uncommited αλλαγές; Ίσως εκεί να έχουμε κάποιο θέμα.

Όχι, τρέχω το τελευταίο ui-0.4, στο οποίο προηγούμενα είχα κάνει merge/push το τελευταίο api-current.
Δοκίμασε με ένα εντελώς νέο instance σου, γιατί μπορεί να έχει παίξει θέμα με το network configuration αυτού που έχεις τώρα, να είναι στραμπουληγμένο στο ganeti λόγω bugs προηγουμένων εκδόσεων. Επίσης, μπορείς να δοκιμάσεις να σβήσεις όλα τα ιδιωτικά σου δίκτυα, αν δεν τα χρειάζεσαι.

3. Γιατί το api σου επιτρέπει να κάνεις πολλαπλά post με τον ίδιο server στο ίδιο δίκτυο; Υπάρχει κάποιος λόγος ή είναι κάτι που θα αλλάξει στο μέλλον;

Γενικά το API είναι τελείως ασύγχρονο, δεν ξέρει ότι έχεις ζητήσει να μπει μια νέα σύνδεση όταν του ζητάς τη δεύτερη. Λέει ότι έχεις συνδεθεί, όταν το Ganeti [αργότερα] του το αναφέρει, και μπει στη ΒΔ.

Επίσης, δεν αποκλείεται πράγματι κάποιος να θέλει δύο κάρτες δικτύου στο ίδιο ιδιωτικό δίκτυο, π.χ. για δοκιμές.

Τέλος, για την προσθήκη μηχανήματος σε ιδιωτικό δίκτυο, γενικά μου παίζει αυτό:

devel@store67:~/synnefo [ui-0.4]$ tools/cloud createnet kalhmera
       created: 2011-06-01T18:53:34.779572+00:00
            id: 22
          name: kalhmera
       servers:
        status: ACTIVE
       updated: 2011-06-01T18:53:34.779602+00:00

devel@store67:~/synnefo [ui-0.4]$ tools/cloud connect 79 22

devel@store67:~/synnefo [ui-0.4]$ tools/cloud ls -l

79 ll
     addresses: public/public aa:00:00:59:4e:ef [192.168.32.7]
                18/lkl aa:00:00:98:bc:2a
                18/lkl aa:00:00:61:92:a6
                18/lkl aa:00:00:37:af:a8
                20/lllkk aa:00:00:ea:a2:f1
                21/xristos aa:00:00:ab:57:d7
                22/kalhmera aa:00:00:50:29:8e
       created: 2011-06-01T15:52:26+00:00
     flavorRef: 1
      imageRef: 4
      metadata: OS="redhat" 
      progress: 100
        status: ACTIVE
       updated: 2011-06-01T18:53:46+00:00

Να συμπληρώσω εδώ ότι για να λειτουργήσει η προσθήκη server σε δίκτυο, στο τοπικό μας instance, σβήστηκαν όλα τα μηχανήματα και τα δίκτυα που υπήρχαν ήδη και τέλος σβήστηκε και ξαναφτιάχτηκε η βάση.

Επίσης, μέχρι τώρα εργαστήκαμε στη λογική ότι δε θα επιτρέπεται η πολλαπλή προσθήκη ενός server στο ίδιο ιδιωτικό δίκτυο. Για να αλλάξει αυτό χρειάζονται εκτεταμένες επεμβάσεις σε διάφορα σημεία. Εάν θέλετε να το υποστηρίξουμε στο ui θα ήταν καλύτερο να ανοίξει σε νέο ticket σε επόμενο milestone.

Mike Muzurakis wrote:

Σε μας είναι οκ τώρα τα δίκτυα. Έκανα push τις τελευταίες αλλαγές.

ΟΚ, θα το δοκιμάσω αργότερα μέσα στη μέσα.

Γενικότερα, όχι μόνο για τώρα, χρειάζεται τεκμηρίωση της υλοποίησης.
Οπότε, ας γράφεται για κάθε πρόβλημα μια σύντομη περιγραφή της αιτίας του και στα tickets, ώστε η τελική τεκμηρίωση του κώδικα να είναι ευκολότερη.

Τι έφταιγε και συνέβαιναν πολλαπλά POST;

Παρατηρήσαμε ένα μικρό glitch όμως: Ενώ κάνουμε ένα POST για να προσθέσουμε σέρβερ σε ένα ιδιωτικό δίκτυο, μερικές φορές (μάλλον είναι θέμα timimg με το scheduled GET ή με το πόσο γρήγορα απαντάει το API?) παίρνουμε 2x2 200άρια GETs, ενώ θα έπρεπε να παίρνουμε 2x1 (ένα για το servers και ένα για το networks). Όταν παίρνουμε 2 servers/detail, το 1ο επιστρέφει μεν τον server που κάναμε add, αλλά χωρίς να τον έχει στο δίκτυο, ενώ το επόμενο GET 200 που έρχεται στο επόμενο refresh έχει το server μέσα στο δίκτυο. Δεν είναι critical, γιατί τελικά ο σέρβερ ζωγραφίζεται, απλά όταν συμβαίνει αυτό, αργεί να ζωγραφιστεί.

Γιατί αργεί να ζωγραφιστεί;
πράγματι, ο server γυρίζει γιατί κάποιο μέρος του API πειράζει την αντίστοιχη γραμμή στη ΒΔ. Να τεκμηριωθεί γιατί αυτό είναι πρόβλημα για το UI;

Το ερώτημα είναι, γιατί την 1η φορά το API μας απαντάει 200, και μας στέλνει το server όπως ήταν και πριν (χωρίς να τον έχει βάλει στο δίκτυο);

Κατά τα άλλα πρέπει να διορθώθηκαν τα προβλήματα.

Με ένα γρήγορο brainstorming να συμπληρώσω τα css id του κάθε server. Τώρα φτιάχνονται ως net-network.id-server-server.id. Εάν αλλάξει αυτό θα πρέπει να αλλάξει σε όλες τις κλήσεις ο τρόπος που εξάγεται το networkID ή το serverID. Φαντάζομαι ότι υπάρχουν και άλλα σημεία που επηρεάζονται και δεν είναι τόσο προφανή.