-
Notifications
You must be signed in to change notification settings - Fork 1
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
multi nf support #47
multi nf support #47
Conversation
It's quite hard to review this without looking at example output of a build, and it strikes me that in our tests we might want example output, like vnfdgen used to have. I couldn't quickly test myself, for want of an input file pointing to real NFs. Interested in your thoughts here. I cannot easily see (without having some example output), how you have solved the problem of different NFs having conflicting deploy Parameters. I think what you've done is put them each in their own section of the config group schema, and then in the config mappings, you reference that particular NF. Better docstrings on many of the functions would help review here. As would example output. |
development.md says:
(Sorry I thought I had documented this before) |
This checklist is used to make sure that common guidelines for a pull request are followed.
Related command
General Guidelines
azdev style <YOUR_EXT>
locally? (pip install azdev
required)python scripts/ci/test_index.py -q
locally?For new extensions:
About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update
src/index.json
automatically.You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify
src/index.json
.