Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Implement Support for Multiple Different Devices #18

Open
lykinsbd opened this issue Sep 16, 2020 · 5 comments
Open

RFC: Implement Support for Multiple Different Devices #18

lykinsbd opened this issue Sep 16, 2020 · 5 comments
Labels
question Further information is requested
Milestone

Comments

@lykinsbd
Copy link
Collaborator

lykinsbd commented Sep 16, 2020

Today, there is only one device available in the transcripts, and there is no ability to select a different device.

We need to decide how to start implementing support for different device types, and how to manage/instantiate them.

This will require some thought/planning around the best way to specify a scenario like the following (as an example):

  • I want 10 fake Cisco ASAs
  • I want 10 fake Cisco ISRs
  • I want 100 fake Juniper MXes

Perhaps the initial configuration simply round-robins through all the devices in transcript_map.yaml and deploys the one of each up to the threshold of maximum listeners?

Is a configuration file specifying the desired topology needed?

@tbotnz and @wrgeorge1983 thoughts?

@lykinsbd lykinsbd added the question Further information is requested label Sep 16, 2020
@tbotnz
Copy link
Owner

tbotnz commented Sep 17, 2020

@lykinsbd what are your thoughts on the actual end use cases for this?

    1. Do you envision more use cases where this would emulate complex topologies of multiple platforms running different transcript maps eg. 10X Juniper SMX with different transcripts per device?
    1. OR do you envision more use cases where its just a bulk amount of the device running the same transcripts per platform?
    1. OR is it both?

The use cases driven by the netpalm project would lean towards more option 2 and in this case some kind of round robin-ing or number of instances per platform would be sufficient?

Ultimately we need to keep it simple for the end developers whilst catering to the core use cases / direction of the project

@lykinsbd
Copy link
Collaborator Author

I was leaning more towards use case two, at least initially. Many types of devices but uniform transcripts among devices of a given type.

@tbotnz
Copy link
Owner

tbotnz commented Sep 21, 2020

Sounds 👍

@lykinsbd
Copy link
Collaborator Author

lykinsbd commented Jan 6, 2021

The end of 2020 was crazy, par for 2020 itself, but I have more time now in the evenings to devote to this project now.

I will have a PR soon with changes to the configuration management and argument parsing to set us up for managing multiple device types, etc.

@lykinsbd lykinsbd added this to the v1.0.0 milestone Jan 6, 2021
@brobare
Copy link

brobare commented Mar 6, 2022

Put anymore thought into this, @lykinsbd? Have something (Accedian) that would be pretty neat to be able to use this for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants