I was thinking the same thing. @dalley also had the suggestion to store
reserved resources in Redis and have ReservedResource be the historical
model.
David
On Thu, Jul 11, 2019 at 4:46 PM Dennis Kliban wrote:
> On Thu, Jul 11, 2019 at 4:21 PM David Davis wrote:
>
>> ReservedResources are uni
On Thu, Jul 11, 2019 at 4:21 PM David Davis wrote:
> ReservedResources are unique[0] and the tasking code relies on this
> uniqueness to prevent race conditions[1]. The db transaction prevents two
> workers from acquiring a lock on the same resource. I read through 5120 but
> I am not sure how th
ReservedResources are unique[0] and the tasking code relies on this
uniqueness to prevent race conditions[1]. The db transaction prevents two
workers from acquiring a lock on the same resource. I read through 5120 but
I am not sure how the design would prevent that from happening?
[0]
https://gith
I just wrote up a story to add an ability to filter Tasks by the resources
that they reserved. This is needed for the migration plan tasks and will be
just as useful for other tasks.
The design requires storing ReservedResources permanently in the database.
The status of the task associated with t
One more note: Not all MySQL / MariaDB installations support transactions,
which we use heavily (and rely on?)
https://docs.djangoproject.com/en/2.2/topics/db/transactions/#transactions-in-mysql
On Thu, Jul 11, 2019 at 3:55 PM David Davis wrote:
> Two plugins are currently running into issues
On 7/11/19 3:54 PM, David Davis wrote:
> Two plugins are currently running into issues trying to support
> mariadb/mysql. The pulp_ansible plugin is interested in adding full text
> search and JSONFields. Meanwhile, the pulp_python plugin is trying to
> store emojis in text which mariadb/mysql does
Two plugins are currently running into issues trying to support
mariadb/mysql. The pulp_ansible plugin is interested in adding full text
search and JSONFields. Meanwhile, the pulp_python plugin is trying to store
emojis in text which mariadb/mysql doesn't handle well since it uses 3-byte
utf-8 by d
Based on recent feedback and discussion with the Pulp developers, we want
to collectively adopt two communication practices:
# Breaking Change Communication
* All breaking changes are advertised to pulp-dev using [breaking] brackets
in the subject
* A timeline of when the change is being applied
