>>> result = clnt.api.delete_container('TORs', child['containerList'][0]['key'], 'DC-1', parent['containerList'][0]['key'])
>>>
## Notes for API Class Usage
### Containers
With the API the containers are added for all cases. If you add the
container to the original root container 'Tenant' then you have to do a
refresh from the GUI to see the container after it is added or deleted.
If the root container has been renamed or the parent container is not
the root container then an add or delete will update the GUI without
requiring a manual refresh.
## Testing
The cvprac module provides system tests. To run the system tests, you
will need to update the `cvp_nodes.yaml` file found in test/fixtures.
Requirements for running the system tests:
- Need one CVP node for test with a test user account. Create the same
account on the switch used for testing. The user account information
follows:
username: CvpRacTest
password: AristaInnovates
If switch does not have correct username and/or password then the tests that
execute tasks will fail with the following error:
AssertionError: Execution for task id 220 failed and in the test log is the error:
Failure response received from the netElement : ' Unauthorized User '
- Test has dedicated access to the CVP node.
- CVP node contains at least one device in a container.
- Container or device has at least one configlet applied.
To run the system tests:
- run `make tests` from the root of the cvprac source folder.
## Contact or Questions
Cvprac is developed by Arista EOS+ CS and supported by the Arista EOS+
community. Support for the code is provided on a best effort basis by
the Arista EOS+ CS team and the community. You can contact the team that
develops these modules by sending an email to <eosplus-dev@arista.com>.
For customers that are looking for a premium level of support, please
contact your local account team or email <eosplus@arista.com> for help.
## Contributing
Contributing pull requests are gladly welcomed for this repository. Not only contributing to the code but also we encourage the users to contribute in the form of examples, docs, tutorials, and user guides.
Please note that all contributions that modify the library behavior
require corresponding test cases otherwise the pull request will be
rejected.
### Working With Git
It is recommended to fork the project and then start development on the forked repository's **develop** branch. This can achieved with the below steps:
- [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) the repo then clone your fork,
and configure the remotes:
# Clone your fork of the repo into the current directory
feature to tidy up your commits before making them public.
- Locally merge (or rebase) the upstream development branch into your topic branch every time before pushing it to your fork:
# Here the <dev-branch> is develop
git pull [--rebase] upstream <dev-branch>
- Push your topic branch up to your fork:
git push origin <topic-branch-name>
- [Open a Pull Request](https://github.com/aristanetworks/cvprac/pulls)
with a clear title, description and explain how to test the feature.
### Submitting Pull Requests
- It is recommended to open an issue before starting work on a pull request to make sure if the same issue is not reported previously and someone is already working on that. When suggesting a new feature, also make sure it won't conflict with any work that's already in progress.
- Once the issue is opened either self-assign the issue or ask the maintainer to assign it for you. This will make sure no others are working on the same issue.
- All new functionality must include relevant tests where applicable.
- When submitting a pull request, please be sure to work off of the **develop** branch and not from other branches. The **develop** branch is used for ongoing development, while the **master** will hold the last stable version.
- To automate release-notes creation and make filtering process easier, it is strongly recommended to use [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/#summary) syntax at least for Pull Request (PR) title.
- All code submissions must follow the below criteria:
- The issue/PR title should follow the semantic as described [here](#pull-request-semantics)
- All the tests are updated and are passed successfully
- Python syntax is valid
### Pull Request Semantics
The Pull Request title should start with one of the below to easily segregate if its a feature add or a bug or something related documentation etc.
It is strongly recommended to use one from the below:
- ```Feat```: Create a capability e.g. feature, test, dependency
- ```Fix```: Fix an issue e.g. bug, typo, accident, misstatement
- ```Doc```: Refactor of documentation, e.g. help files
- ```Example```: Add a new example or modify an [existing one](docs/labs/)
- ```Test```: Add or refactor anything regarding test, e.g add a new testCases or missing testCases
- ```Refactor```: A code change that MUST be just a refactoring
- ```Bump```: Increase the version of something e.g. dependency
- ```Revert```: Change back to the previous commit
- ```Optimize```: Refactor of performance, e.g. speed up code
- ```CI```: Update CI components, e.g. molecule files or Github Actions
- ```Cut```: Remove a capability e.g. feature, test, dependency
