Project

General

Profile

Actions
Copy link

Bug #8687

closed

Inconsistent directive API parameters at creation

Added by Alexis Mousset over 8 years ago. Updated over 8 years ago.

Status:
Released
Priority:
N/A
Assignee:
François ARMAND
Category:
API
Target version:
2.11.23
Pull Request:
https://github.com/Normation/rudder/p...
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

In the directive API:

  • the priority attribute in exported, can be modified, but cannot be provided at creation
  • the isSystem attribute in exported, can be modified, but cannot be provided at creation
  • The isEnabled attribute is called enabled at creation

Subtasks 4 (0 open — 4 closed)

Bug #8715: Migrate 'api_compatibility_mode' so it's enable on migrationReleasedAlexis Mousset2016-07-20Actions
Bug #8716: Remove 'isxxx' and add priority in Directive from api docReleasedFrançois ARMAND2016-07-20Actions
Bug #8768: Style of title Api backward compatibility in Settings is invalidReleasedVincent MEMBRÉ2016-07-28Actions
Bug #8780: Test broken since we added a new entry in bootstrap.ldif ...ReleasedBenoît PECCATTE2016-07-28Actions
Actions
Copy link
 #1

Updated by Alexis Mousset over 8 years ago

  • Subject changed from Inconsistent API parameters to Inconsistent directive API parameters at creation
Actions
Copy link
 #2

Updated by François ARMAND over 8 years ago

We need to ensure that POST (GET url_api) works.
For that case, we need to:

- just add the missing priority parameter,
- remove from documentation the "isXXX" to only keep "XXX" variant,
- keep aliases in code to node break existing script, marking "isXXX" variant deprecated,
- remove in next major API the old "isXXX" values.

Actions
Copy link
 #3

Updated by Vincent MEMBRÉ over 8 years ago

Priority works, it just not documented.

We do not accept "isXXX" as parameter, but always "XXX". But we always answer "isXXX"

Actions
Copy link
 #4

Updated by Vincent MEMBRÉ over 8 years ago

I don't think "system" should be set/modified

Actions
Copy link
 #5

Updated by Vincent MEMBRÉ over 8 years ago

  • Assignee set to Vincent MEMBRÉ
  • Target version set to 2.11.23

We will:

  • Document priority in directive creation (another issue)
  • Always send 'xxx' instead of 'isxxx"
  • Define a new property 'api compatibility' that is 'disabled' on new install, 'enabled' on migration which allows:
    • If "enabled", api will also send "isxxx" in response, which will allow compatibility with old script treating the "isxxx -> xxx" case
  • Deprecate all current API in master, so we can create a new one only snedinf 'xxx'
  • Remove all deprecated API and the property in master+1
Actions
Copy link
 #6

Updated by Vincent MEMBRÉ over 8 years ago

  • Status changed from New to In progress
Actions
Copy link
 #7

Updated by Vincent MEMBRÉ over 8 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Vincent MEMBRÉ to François ARMAND
  • Pull Request set to https://github.com/Normation/rudder/pull/1136
Actions
Copy link
 #8

Updated by Benoît PECCATTE over 8 years ago

If you do not accept system, you break the "export then import" workflow, which is the first use of this kind of API.

I suggest that you accept the "system" attribute and return an error if it is true.

Actions
Copy link
 #9

Updated by Vincent MEMBRÉ over 8 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
Actions
Copy link
 #10

Updated by Alexis Mousset over 8 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.11.23, 3.1.12 and 3.2.5 which were released today.

Actions
Copy link

Also available in: Atom PDF