* Inventory updates that are canceled and are dependencies of jobs
result in the dependent job being canceled. This code adds a better
description to job_explanation so that a job marked as canceled can be
traced back to the inventory update that triggered this case.
This is a special license that is triggered in the presence of two
directories:
- /opt/rh/cfme-appliance
- /opt/rh/cfme-gemset
and the rpms
- cfme
- cfme-appliance
- cfme-gemset
All of which I'm assured are responsible for validating that this is
indeed an enterprise cloudforms environment.
When these are present then a license is used that is near perpetual,
allows for a stupid large number of instances, and turns on all features
* We should not modify the original env because it's what is going to be
passed to the Ansible process. This will contain all of the passwords,
unobscured. The safe env is what will get saved into the model.
* Support "name" if given, else use a more reasonable file name for
the playbook file
* Fix an issue where we wouldn't populate the playbooks correctly in
the database
* Force downloading the playbooks every time since we can't tell when
the file might change
* Extend scm credential type to support username and password for
redhat portal accounts
* Update project update playbook to work with remote insights server
1. If the setting isn't in the database, then the specified default is
returned.
2. If the setting IS in the database, then the 'value' field, from the
database, is returned; Unless, the value is null in the database, then
the defined default is returned.
* Take case 1. If the default=None then an AttributeError is raised
* Thus, by setting default='', in case 1. We don't get an AttributeError
because '' will be returned.
* Also note that we don't allow_null=True because then the database
entry could be None. Accessing the setting would raise an AttributeError
in this case. Further, since we set default='' it doesn't matter if null
is in the database.
TL;DR set default=<something_other_than_None>
There's a race between our `ws_connect` and `ws_receive` methods;
it's possible to fall into a scenario where we're handling a legitimate
message *before* django-channels is able to persist the `user_id` into
the channel session. This results in a scenario where a user can open
a browser tab and never receive new websocket messages. In this
scenario, we should just toss the message back into the queue and try
again later (up to a reasonable limit of retries).
