Apparently akamaihd.net hostnames can't be managed by the API and if they already exist, we can't manage the property through bossman.

PAPIHostnamesValidationError
detail: The System could not find cnameTo value ...-vh.akamaihd.net.
instance:
status: 400
title: Bad cnameTo
type: https://problems.luna.akamaiapis.net/papi/v0/property-version-hostname/bad-cnameto

One possibility is to Allow bossman to manage rules.json and ignore hostnames.json

Hi @TomasHampl, @berk76,

Currently bossman apply will exit with status 0 even if some of the properties had validation errors.

This may not be the best behavior for automation contexts. Should we instead fail with a non-zero status if any of the property versions had errors?

In particular, accountId, contractId, groupId

The issue here is that prerelease and release both require confirmation before they are actually applied.

The change here would be to implement a --yes flag, along with some terminal-aware progress display (if terminal, then use fancy progress bars; if non-terminal, use plain output).

Hi @ynohat ! I hope you're doing great 😃

I started getting these kinds of validation errors when creating new version of existing cloudlet policy. This happens to me using latest 0.42.0 and also when I revert to previous version, I've been running -- 0.39.7. So, since it has surfaced just now, it might not be related to changes in bossman itself.

The issue is probably due to bossman populating the description field with strings longer than what is the API limit (according to the API response this is 255 characters). In my case, bossman created description field with 387 characters.

CloudletAPIV3Error
errors:
- detail: Value of `description` size must be between 0 and 255.
  invalidField: description
  invalidValue: ' --- description field with more than 255 characters --- '
  title: Validation failed
instance: 46414bf5-385a-4bb8-90e3-f43607481073
status: 400
title: Validation failed
type: /cloudlets/v3/error-types/validation-failed

I'll try to workaround this issue my local code changes for now 👍

A serious performance regression in 4.x led to a reversal to >=3.2.0, <4.0.0.

This appears to be fixed in 4.3.1.

cf. python-jsonschema/jsonschema#853.

bossman apply evaluates if a revision should be applied based on the presence of git notes.

When a transient API error occurs (e.g. 500) during the property hostname or rule tree update,
bossman stores notes, setting has_error: true. The next apply command considers that the
revision had errors and shouldn't be retried.

We should instead be storing notes with has_error: true only when the error is caused by
invalid content in git (and it would be useless to retry).

bossman apply does not try to re-apply a version it has already applied when the previous application failed with a bad request error, which is usually associated with rule tree validation errors. This normally makes sense because a validation error should really be fixed in a new commit.

Some 400 errors are transient, and should be retry-able. For example:

> bossman apply --force example_prop
⬆ build/akamai/property/example_prop [ffb7e0bd] "Merge branch 'integration'" John Doe
PAPIHostnamesValidationError
clientIp: xxxxxxxxx
detail: Invalid timestamp
instance: https://xyz.luna.akamaiapis.net/papi/v1/properties/prp_xxxxxxx/versions/17/hostnames
method: PUT
requestId: 55cb08a
requestTime: '2022-01-05T09:08:49Z'
serverIp: xxxxxxxxxxxxxxx
status: 400
title: Bad request
type: https://problems.luna.akamaiapis.net/-/pep-authn/request-error

Because this is a 400 error, bossman annotates the resource with a git note that says an error occurred, forcing us to either create a new commit, or hack the notes directly:

git fetch origin '+refs/notes/build/akamai/property/*:refs/notes/build/akamai/property/*'
git fetch --all
git notes --ref=refs/notes/build/akamai/property/example_property remove HEAD
git push origin '+refs/notes/build/akamai/property/example_property:refs/notes/build/akamai/property/example_property'

In Property Manager, CP Codes can be created by adding the behavior to the configuration, but this is an out of band process.

In the rule tree, the CP Code id is required. This means that adding a CP Code is more challenging, the json cannot just be edited to add a new CP Code.

A proposed solution would be to allow CP Codes to be specified just with their name. Bossman should then traverse the rule tree and create CP Codes in place as required.

If the CP Code id is already present, no action is required.

CP Codes are associated with a contract, product and group.
It should be enough to assign the CP Code to the contract and product associated with the rule tree.

The group is trickier, because two configurations in different groups may reference the same CP Code. This can be treated as an edge case to be managed post hoc in the UI.

Hello @ynohat !

I was wondering if it would make sense to introduce a confirmation request when you use the bossman apply command.

Hypothetical scenario could look like this:

$ bossman apply *example.org
This is going to create 12 new versions in the property a.example.org
This is going to create 2 new versions in the property b.example.org
Do you want to continue? [Y/n]

Let me know what do you think about that 😃 This would unfortunately had an impact on any existing CI/CD pipelines which are using bossman apply in their flow.

Facts:

• gitpython uses posix paths
• windows paths don't play well with rich console

So the best option is to normalize all paths to posix when reading the filesystem.

This is critical for usability, otherwise failure is only caught at prerelease/release time

Hello @ynohat

recently I installed bossman from scratch and found bossman validation was extremely slow. Reason is new jsonschema==4.1.0 dependency. I fixed it by downgrading to the same version I am using on my notebook jsonschema==3.2.0.

Have a nice day.

Bossman failed and output started with a long stack trace that included non relevant diagnostic and suggestion:
"│ 22 │ raise BossmanError("Repository not initialized or needs migration, please run `bossm │"

Output ended with the error message:
"error: [Errno 11] Resource temporarily unavailable: '.bossmancache'"

I didn't notice it but I noticed that there was a bossman process still running. After this process was finished, i was able to run bossman.

It would be more clear if stack trace was not displayed with the verbosity by default.

I have installed the stable version of Bossman using python3 -m pip install bossman command despite all the pre-requisites, I have python 3.8.9, and when executing the Bossman init command, I am getting the below error:

Traceback (most recent call last):
File "/usr/local/bin/bossman", line 5, in
from bossman.cli import main
ModuleNotFoundError: No module named 'bossman'

And my /usr/local/bin/bossman file is shown below:

#!/usr/local/opt/[email protected]/bin/python3.9

-- coding: utf-8 --

import re
import sys
from bossman.cli import main
if name == 'main':
sys.argv[0] = re.sub(r'(-script.pyw|.exe)?$', '', sys.argv[0])
sys.exit(main())

Would you please help me fix the problem because I have tried uninstalling/Installing Python and Bossman?

Currently when we run "bossman apply" command for a property name that doesn't exists, the message returned is : "all resources up to date".
This message misleads us, as finally we should expect instead a message like : " No ressources matching".
As an example :
$ bossman apply invalidPropertyName
🍪 all resources up to date

To be replaced by :
$ bossman apply invalidPropertyName
🍪 No Ressources matching

Bossman command are throwing the below error:

There are no problems with the git command because all the git command are working fine.

I am not sure yet if this is a real issue, but referencing here in case discussion is useful and people wonder.