Git Product home page Git Product logo

cnaas-front's People

Contributors

dependabot[bot] avatar indy-independence avatar katsel avatar krihal avatar lunkwill42 avatar njons avatar wouter1975 avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cnaas-front's Issues

"Firmware" tab should be optional

Is your feature request related to a problem? Please describe.

Currently, the "Firmware" tab shows up at the top of the page regardless if cnaas-nms supports firmware updates for the current vendor or not.
It seems like firmware updates are currently mostly an Arista thing but do not work for Juniper -- so for us, this tab is not useful right now.
Making the tab optional would be a way to make the frontend more vendor-independent.

Describe the solution you'd like

I'd suggest the tab to be optional and only show up when the CNAAS_FIRMWARE_URL environment variable is set and non-empty.
If CNAAS_FIRMWARE_URL is set: Show the tab.
Otherwise: Tab is not visible.

Describe alternatives you've considered

Ignoring it? ;) Still every new person I tell about the frontend needs to be told "sorry, we currently can't use this!"

Additional context

It's a really small niggle, I admit that. Still I'd like seeing this fixed.

Unsafe handling of 3rd party python dependencies

In various docker-files, you install 3rd party python libraries like this:

$ pip install dependency1 dependency2 ..

Sooner or later, these dependencies will need different versions of a sub-dependency, and then pip will fail because of a version conflict.

I recommend that you put these dependencies in requirements-files with version numbers and install them like this:

$ pip install -r requirements-for-subsystem-1.txt

You can generate a requirements file with pip freeze or better: pip-compile from piptools.

By using the same requirements-files everywhere you can make reproducible deploys, and also test on the actual versions that will be deployed. Much recommended!

Don't stack trace when a device is unreachable

Describe the bug
When doing a dry-run to a group of switches and one of them is unreachable you get a long python stack trace in the NMS GUI.

Steps to reproduce the behavior:

  • Make one switch unreachable
  • Perform a dry-run

Expected behavior:

  • Instead of getting 50 lines of stack trace It would be preferable if it was handled with some kind of message saying the device could not be reached or something like that.

Environment:
CNaaS-NMS version: 1.2.1

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.