[katello-devel] Renaming of environments: summary

[Dmitri Dolguikh]

The discussion here covers Katello API. A big point that I keep failing 
to communicate is that we, Katello developers, can't know all possible 
clients of Katello REST API. Yes, Katello cli is going to be fine, since 
it doesn't (at least presently) cache/persist locally any information it 
receives. Yes, yum is going to be fine too.

The hypothetical customer/3rd party system in the example I made is 
utterly fubared however. When accessing data at the url it persisted, it 
receives completely different data. We just violated someone else's data 
integrity. Why doesn't this bother anyone?

Imagine some piece of code violated Katello internal data integrity the 
same way - what would your reaction be then?
-d


On 15/08/12 05:26 AM, Lukas Zapletal wrote:
> On Tue, Aug 14, 2012 at 05:15:58PM +0100, Dmitri Dolguikh wrote:
>> In this light: some piece of code on the client side uses API to
>> enumerate available environments. Some time passes. Some admin
>> deletes one of the environments. Some time passes. Some admin
>> creates an environment with the same label. The original client
>> re-syncs environments. Instead of detecting a deleted environment,
>> it sees that the environment is there and alive. The resulting
>> issues are going to be a living hell to debug.
> I don't see any issues in this scenario. Created, deleted, created
> again, re-synced. Everything is fine, clients are not able to connect to
> the original environment via yum (it has different certificate). CLI
> also works, you can re-sync without any problems. What is the issue
> again?
>
> Having labels does not mean we are resigning from primary keys. Every
> resource should have it's own primary key as we have it today. Anybody
> will be able to notice the change. Theoretically numeric id could be
> re-assigned by sql server, but that is another story...
>