NSX REST API - Python

Wszystko o rozwiązaniach Software-defined networking (SDN), OpenFlow, APIC-EM, ACI, REST API i pokrewnych

Moderatorzy: mikrobi, aron, garfield, gangrena, Seba

Wiadomość
Autor
horac
wannabe
wannabe
Posty: 72
Rejestracja: 18 kwie 2016, 21:04
Lokalizacja: CCIE

NSX REST API - Python

#1

#1 Post autor: horac » 25 paź 2016, 11:57

Hej, ostatnio spedzam troche czasu nad REST API i postanowilem skrobnac
przyklad w pythonie. Co ciekawe NSX pozwala na deployment logical switchy
z ta sama nazwa (odroznia je tylko VNI). Postanowilem zmierzyc sie z tym problemem
i za pomoca REST API uniemozliwic tworzenie logical switchy z ta sama nazwa

https://www.linkedin.com/pulse/why-you- ... =prof-post

Oczywiscie przedstawiam core funkcjonalnosc, natomiast w jaki frontend sie to ubierze to juz bez znaczenia czy to bedzie
web app, czy konsola czy jakies gui

P.S Kodze bloga, niedlugo skoncze to bede wiecej wrzucal na niego kolejne kody, zamiast na linkedin

Awatar użytkownika
awo
CCIE
CCIE
Posty: 354
Rejestracja: 05 wrz 2004, 16:25
Lokalizacja: waw@pl
Kontakt:

Re: NSX REST API - Python

#2

#2 Post autor: awo » 25 paź 2016, 16:52

Popraw sobie osadzenie obrazka....

freel4ncer
wannabe
wannabe
Posty: 530
Rejestracja: 27 wrz 2007, 01:13

Re: NSX REST API - Python

#3

#3 Post autor: freel4ncer » 25 paź 2016, 21:29

powinienes uzywac try except by lapac problemy z request a nie if
do tego warto by bylo sie trzymac substytucji wszedzie w kodzie niz na przemiennie z konkatynacja

Docstringi pisze sie w funkcji / klasie do ktorej naleza nie nad nia

Radze stosowac sie do pep8 tu masz output z linta na twoim kodzie (zwlaszcza gdy publikujesz cos na linkedin)

Kod: Zaznacz cały

Check results
=============

E302:8:1:expected 2 blank lines, found 1
E231:8:24:missing whitespace after ':'
E501:8:80:line too long (81 > 79 characters)
E113:9:5:unexpected indentation
E251:11:68:unexpected spaces around keyword / parameter equals
E251:11:70:unexpected spaces around keyword / parameter equals
E501:11:80:line too long (93 > 79 characters)
E711:17:19:comparison to None should be 'if cond is not None:'
E265:19:17:block comment should start with '# '
E231:22:20:missing whitespace after ','
E302:28:1:expected 2 blank lines, found 1
E501:30:80:line too long (80 > 79 characters)
E501:32:80:line too long (92 > 79 characters)
E711:38:27:comparison to None should be 'if cond is not None:'
E302:47:1:expected 2 blank lines, found 1
E231:63:21:missing whitespace after ','
E112:67:13:expected an indented block
E501:68:80:line too long (117 > 79 characters)
E231:68:97:missing whitespace after ','
E225:70:33:missing whitespace around operator
E501:71:80:line too long (111 > 79 characters)
E501:72:80:line too long (125 > 79 characters)
E501:76:80:line too long (116 > 79 characters)
E231:76:95:missing whitespace after ','
E501:78:80:line too long (91 > 79 characters)
E501:82:80:line too long (86 > 79 characters)
E231:83:31:missing whitespace after ':'
E711:91:15:comparison to None should be 'if cond is not None:'
E501:92:80:line too long (82 > 79 characters)
E711:97:14:comparison to None should be 'if cond is not None:'
E501:101:80:line too long (97 > 79 characters)
E231:101:88:missing whitespace after ','
E231:102:32:missing whitespace after ','
E231:102:40:missing whitespace after ','
E231:102:47:missing whitespace after ','
W292:102:56:no newline at end of file
Ostatnio zmieniony 25 paź 2016, 23:14 przez freel4ncer, łącznie zmieniany 4 razy.

Awatar użytkownika
peper
CCIE / Site Admin
CCIE / Site Admin
Posty: 4872
Rejestracja: 13 sie 2004, 12:19
Lokalizacja: Warsaw, PL
Kontakt:

Re: NSX REST API - Python

#4

#4 Post autor: peper » 25 paź 2016, 22:47

To ja się boje swoje perlowe rzeczy publikować :P
Facebook: https://www.facebook.com/Piotr.Wojciechowski.CCIE
LinkedIn: http://www.linkedin.com/in/peper
Twitter: http://www.twitter.com/PiotrW_CCIE
Blog: http://blog.it-playground.eu

"Zapomniałem że od kilku lat wszyscy giną jakby nigdy ich nie miało być
w stu tysiącach jednakowych miast giną jak psy"

freel4ncer
wannabe
wannabe
Posty: 530
Rejestracja: 27 wrz 2007, 01:13

Re: NSX REST API - Python

#5

#5 Post autor: freel4ncer » 25 paź 2016, 23:08

peper pisze:To ja się boje swoje perlowe rzeczy publikować :P
Ja sie boje czytac i modyfikowac swoje perlowe wypociny ;) Tzn nie przypominam sobie bym cos napisal w Perlu od 3-4 lat ale napewno niechcialbym byc zmuszony zagladac do tego kodu ;)

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2344
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: NSX REST API - Python

#6

#6 Post autor: gangrena » 25 paź 2016, 23:14

horac pisze:Co ciekawe NSX pozwala na deployment logical switchy
z ta sama nazwa (odroznia je tylko VNI).
To objectId jest unikalnym identyfikatorem obiektu virtualwire, czyli logicznego switcha (LS). Ani nazwa, ani VNI takimi identyfikatorami nie są. Zatem logiczne switche nie odróżniają się tylko poprzez VNI w Twoim przypadku. Posiadanie możliwości nadawania tych samych nazw logicznym przełącznikom jest przydatne zwłaszcza w środowiskach multitenant z vCloud Director. Klienci mogą wówczas tworzyć swoje nazwy i nie ma problemu, by się powtarzały z nazwami obiektów u innych klientów. Jeżeli zarządzacie tworzeniem LS dla klientów, to wystarczy dodawać identyfikator lub nazwę klienta do nazw obiektów.

Awatar użytkownika
peper
CCIE / Site Admin
CCIE / Site Admin
Posty: 4872
Rejestracja: 13 sie 2004, 12:19
Lokalizacja: Warsaw, PL
Kontakt:

Re: NSX REST API - Python

#7

#7 Post autor: peper » 26 paź 2016, 00:12

freel4ncer pisze:
peper pisze:To ja się boje swoje perlowe rzeczy publikować :P
Ja sie boje czytac i modyfikowac swoje perlowe wypociny ;) Tzn nie przypominam sobie bym cos napisal w Perlu od 3-4 lat ale napewno niechcialbym byc zmuszony zagladac do tego kodu ;)
Ja generalnie programowania się nie dotykałem od prawie 10 lat bawiąc się Java, C i C++ wcześniej przez około 10 lat. Perla mało dotykałem ale dotykałem więc do REST API wydal mi się najbardziej naturalnym rozwiązaniem szczególnie na to co testuję i opisuję. Podejścia do programowania się nie zapomina, co najwyżej składni języków i best practice :)
Facebook: https://www.facebook.com/Piotr.Wojciechowski.CCIE
LinkedIn: http://www.linkedin.com/in/peper
Twitter: http://www.twitter.com/PiotrW_CCIE
Blog: http://blog.it-playground.eu

"Zapomniałem że od kilku lat wszyscy giną jakby nigdy ich nie miało być
w stu tysiącach jednakowych miast giną jak psy"

horac
wannabe
wannabe
Posty: 72
Rejestracja: 18 kwie 2016, 21:04
Lokalizacja: CCIE

Re: NSX REST API - Python

#8

#8 Post autor: horac » 26 paź 2016, 11:08

freel4ncer pisze:powinienes uzywac try except by lapac problemy z request a nie if
do tego warto by bylo sie trzymac substytucji wszedzie w kodzie niz na przemiennie z konkatynacja

Docstringi pisze sie w funkcji / klasie do ktorej naleza nie nad nia

Radze stosowac sie do pep8 tu masz output z linta na twoim kodzie (zwlaszcza gdy publikujesz cos na linkedin)
Wiem, tylko zeby robic try except trzeba wiedziec co sie lapie bo robienie Except exception as error moze czasem
przyniesc wiecej problemow. To nie kod produkcyjny ;] brakuje unit testow itp.
W kazdym badz razie GET jak nie zwroci 200 to jest problem, a w przypadku POST 201.

Pisane na kolanie to w godzine, chodzi o koncepcje - zeby nasze srodowisko nie balo sie programowac
bo nie jestesmy gorsi.
peper pisze:To ja się boje swoje perlowe rzeczy publikować :P
Nie ma czego sie bac, konstruktywna krytyka zawsze ci pomoze a nie zaszkodzi w razie czego. Dla przykladu Gynvael Coldwind
wydal ksiazke, i juz klika errat robil, ludzie mu krytyczne bledy w kodzie zglaszali w przykladach ktore opublikowal ( w tym ja mu dzial sieciowy pomagalem poprawiac)
a ma ponad 2x lat doswiadczenia z kodem. Nawet w produkcji kod nie jest wolny od bledow, dlatego wychodza patche/latki i kolejne edycje. Takze publikuj

Staram sie przeciwstawic powszechnej opinni, ze Sieciowcy to zajeli sie sieciami bo nie potrafili/nie chcieli/nie umieli programowac.

gangrena pisze:
horac pisze:Co ciekawe NSX pozwala na deployment logical switchy
z ta sama nazwa (odroznia je tylko VNI).
To objectId jest unikalnym identyfikatorem obiektu virtualwire, czyli logicznego switcha (LS). Ani nazwa, ani VNI takimi identyfikatorami nie są. Zatem logiczne switche nie odróżniają się tylko poprzez VNI w Twoim przypadku. Posiadanie możliwości nadawania tych samych nazw logicznym przełącznikom jest przydatne zwłaszcza w środowiskach multitenant z vCloud Director. Klienci mogą wówczas tworzyć swoje nazwy i nie ma problemu, by się powtarzały z nazwami obiektów u innych klientów. Jeżeli zarządzacie tworzeniem LS dla klientów, to wystarczy dodawać identyfikator lub nazwę klienta do nazw obiektów.
Masz racje, ale zauwaz ze jak dodajesz nazwe klienta pod obiekt LSa to juz on staje sie unikalny, nie widze sensu np dla jednego klienta posiadania zduplikowanych nazw LSow. Dlatego napisalem maly skrypt ktory nie zezwala na stworzenie wiecej niz jednego switcha o takiej samej nazwie. Klient zazwyczaj jak ma srodowisko dev/test/prod to sobie nazwie www-tier-klient-test, www-tier-klient-dev, www-tier-klient-prod. Raczej by nie chcial dwoch www-tier-klient-prod i omylkowo pomylil gdzie podlacza workloady.
Ostatnio zmieniony 26 paź 2016, 11:17 przez horac, łącznie zmieniany 2 razy.

freel4ncer
wannabe
wannabe
Posty: 530
Rejestracja: 27 wrz 2007, 01:13

Re: NSX REST API - Python

#9

#9 Post autor: freel4ncer » 26 paź 2016, 11:13

Kod: Zaznacz cały

except requests.exceptions.RequestException 

Kod: Zaznacz cały

except requests.exceptions.HTTPError
Zeby byla jasnosc ja nie hejtuje tylko staram sie radzic wedlug mojej skromnej wiedzy ;)
Generalnie +1 za propagowanie automatyzacji :)
Ostatnio zmieniony 26 paź 2016, 14:45 przez freel4ncer, łącznie zmieniany 1 raz.

horac
wannabe
wannabe
Posty: 72
Rejestracja: 18 kwie 2016, 21:04
Lokalizacja: CCIE

Re: NSX REST API - Python

#10

#10 Post autor: horac » 26 paź 2016, 11:19

freel4ncer pisze: Zeby byla jasnosc ja nie hejtuje tylko staram sie radzic wedlog mojej skromnej wiedzy ;)
Generalnie +1 za propagowanie automatyzacji :)
No i dzieki, o to chodzi. Co do automatyzacji, dokladnie to jest wlasciwy kierunek ktory obralem juz jakis czas temu.

p.s popraw na "wedlug"

Awatar użytkownika
peper
CCIE / Site Admin
CCIE / Site Admin
Posty: 4872
Rejestracja: 13 sie 2004, 12:19
Lokalizacja: Warsaw, PL
Kontakt:

Re: NSX REST API - Python

#11

#11 Post autor: peper » 26 paź 2016, 12:01

@horac - to był sarkazm z mojej strony.
Facebook: https://www.facebook.com/Piotr.Wojciechowski.CCIE
LinkedIn: http://www.linkedin.com/in/peper
Twitter: http://www.twitter.com/PiotrW_CCIE
Blog: http://blog.it-playground.eu

"Zapomniałem że od kilku lat wszyscy giną jakby nigdy ich nie miało być
w stu tysiącach jednakowych miast giną jak psy"

freel4ncer
wannabe
wannabe
Posty: 530
Rejestracja: 27 wrz 2007, 01:13

Re: NSX REST API - Python

#12

#12 Post autor: freel4ncer » 26 paź 2016, 14:53

horac pisze:
freel4ncer pisze: Zeby byla jasnosc ja nie hejtuje tylko staram sie radzic wedlog mojej skromnej wiedzy ;)
Generalnie +1 za propagowanie automatyzacji :)
No i dzieki, o to chodzi. Co do automatyzacji, dokladnie to jest wlasciwy kierunek ktory obralem juz jakis czas temu.

p.s popraw na "wedlug"
Poprawione :D bardzo malo pisze/czytam po Polsku od przeszlo 10 lat i juz nie ogarniam ortorgrafii ;)

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2344
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: NSX REST API - Python

#13

#13 Post autor: gangrena » 27 paź 2016, 00:14

horac pisze:Masz racje, ale zauwaz ze jak dodajesz nazwe klienta pod obiekt LSa to juz on staje sie unikalny, nie widze sensu np dla jednego klienta posiadania zduplikowanych nazw LSow. Dlatego napisalem maly skrypt ktory nie zezwala na stworzenie wiecej niz jednego switcha o takiej samej nazwie. Klient zazwyczaj jak ma srodowisko dev/test/prod to sobie nazwie www-tier-klient-test, www-tier-klient-dev, www-tier-klient-prod. Raczej by nie chcial dwoch www-tier-klient-prod i omylkowo pomylil gdzie podlacza workloady.
Nakładka vCloud Director umożliwia wygodniejszy podział jednego DC na kilka wirtualnych. Pod spodem działa sobie jeden NSX. Wówczas klienci nie widzą swoich obiektów. Nazwy mogą się powtarzać i nikt nie musi uzgadniać nazwy z kimś innym. W Waszym przypadku nie jest to potrzebne, gdyż jeden NSX to jeden klient.

ODPOWIEDZ