-
Notifications
You must be signed in to change notification settings - Fork 59
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
Various updates, will squash with more meaningful message later #577
Conversation
Now that we have PLAN/DEPLOY settings , can we auto-enable related jobs from plugin init as suggested in nautobot/nautobot#4398 (comment) (only if already enabled through settings) ? |
I personally found it confusing it was scoped to just the create. Fail early, fail often... what do you guys think? |
If you disable generate then there will be nothing to deploy. Having the ability to enable deploy without generate would not work and cause confusion. Maybe combine them into one setting or throw a warning when they disable generate but not deploy? |
Following use cases are valid :
|
I will stay in a position , where Job should be automatically enabled by the plugin's ORM if settings are set to "ENABLE". This will improve user experience and decrease complexity |
This is if generate is enabled and deploy is disabled. I did not speak on this use case and it is still valid.
The |
Only thing to me that is now confusing with these warnings, is that we don't warn for an identical scenario for the other "featuers" that GC has. We don't warn that backup jobs, intended, etc. are not enabled. I know the scope is slightly different because some of these are hidden. But just curious what others think on this note. |
…nal, set status instead
Co-authored-by: Jeff Kala <[email protected]>
nautobot_golden_config/jobs.py
Outdated
|
||
def receive_job_button(self, obj): | ||
"""Run config plan deployment process.""" | ||
self.log_debug("Starting config plan deployment job.") | ||
data = {"debug": False, "config_plan": ConfigPlan.objects.filter(id=obj.id)} | ||
config_deployment(self, data, commit=True) | ||
if not self.failed: | ||
obj.delete() | ||
obj.update(status=Status.objects.get(slug="completed")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to update the config_deployment
nornir play to now fail if any of the plans are Completed. We don't want to deploy the same config plan twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think You could gracefully skip implemented tasks. In the longer-run , we could discuss how to present archive config plans (maybe second List View ?)
In this implementation , you can have three stages :
- start (status planned)
- inprogress (status in-implementation)
- finish (status implemented / errored)
Ideally, You can only start tasks in a certain status : planned or failed.
Tasks in progress (during implementation) should also change status to in-progress
for the duration of the actual job
Tasks finalised: either deployed (implemented), either "errored"
STATE_MACHINE = {
"start": {
"provision": ["Planned", "Failed", "Decommissioned"],
"deprovision": ["Active", "Failed"],
},
"inprogress": {
"provision": "Provisioning",
"deprovision": "Deprovisioning",
},
"finish": {
"provision": "Active",
"deprovision": "Decommissioned",
},
}
* revert to develop migrations files and create new one for changes
Co-authored-by: Ken Celenza <[email protected]>
"graphql", | ||
"relationships", | ||
"webhooks", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason we had only graphql
was the GoldenConfigSetting
model :
@extras_features(
"graphql",
)
class GoldenConfigSetting(PrimaryModel): # pylint: disable=too-many-ancestors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I think that was an oversight as well. Will fix in 2.0
* Adds URL validation to Config Plan creation form * Update nautobot_golden_config/templates/nautobot_golden_config/configplan_create.html --------- Co-authored-by: Jeff Kala <[email protected]>
…d documentation(#589) * some flake8 fixes * fix broken flake8 and pylint configs and actual issues, and update run_job.js * add ADRs * add documetnation
null=False, | ||
blank=False, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still not sure about this change.
We decided to generate config plans with job-helper, however we ended-up:
- disabling CSV imports of config plans
- disabling API creation of config plans
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was saying , that the ConfigPlan model makes the jobID
mandatory - you cannot have ConfigPlan without having a Job first.
The only one point I am making today is that we can possibly have more ways of populating this in the future - CSVs , APIs etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
nautobot_golden_config/views.py
Outdated
Job.objects.get(module_name="nautobot_golden_config.jobs", job_class_name="GenerateConfigPlans"), | ||
request, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to use string-ified imported elements here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about the request or the benefits, do you mind explaining further?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking we could avoid re-typing class names, possibly making it harder to make mistake in the future.
…lden-config into wg-kc-update
* implement plan_result and deploy_result * change cascade to protect * Update nautobot_golden_config/nornir_plays/config_deployment.py Co-authored-by: Joe Wesch <[email protected]> * fix filter and typo --------- Co-authored-by: Joe Wesch <[email protected]>
No description provided.