Bug 1647455

Do we really need a flag here?

The API is intended for an advanced, concrete use case where users/customers need to automate a specific series of steps. There should not be ambiguity about what has happened.

It would be better for ansible to default to next_run true.

The principal problem with this request is that it requiree manual intervention, review, and/or script modifications to even catch this output, instead of a more sane default

There is a clear way how to request that, there’s the next_run parameter, and.there is the configuration in NEXT_RUN snapshot which can be retrieved. It’s not very convenient or straightforward for end user, but indeed API is for advanced usage and automation

We already have this functionality.

If you retrieve /api/vms/123 and you find the parameter next_run_configuration_exists set to true, you can then fetch the next_run configuration as:

/api/vms/123?next_run=true, and compare the previous output with this one to see what will be changed.

Is this sufficient?

This is already available. Please re-open if the information in comment#5 is not sufficient

(In reply to Ondra Machacek from comment #5)
> We already have this functionality.
> 
> If you retrieve /api/vms/123 and you find the parameter
> next_run_configuration_exists set to true, you can then fetch the next_run
> configuration as:
> 
> /api/vms/123?next_run=true, and compare the previous output with this one to
> see what will be changed.
> 
> Is this sufficient?

Hi,

so how are we expect the users to use this feature? I understand that in case we use directly RestAPI or SDK. We are expected to process the results. But what about the stacket management tools like Ansible. There is no proper way to process the output in Ansible. The comparison of the current configuration and the next run is close to impossible. 

If you want to see the next run you are mostly interested only in the changes. I believe that the API/Ansible should make it much easier than now.

What do you think?

(In reply to Roman Hodain from comment #7)
> (In reply to Ondra Machacek from comment #5)
> > We already have this functionality.
> > 
> > If you retrieve /api/vms/123 and you find the parameter
> > next_run_configuration_exists set to true, you can then fetch the next_run
> > configuration as:
> > 
> > /api/vms/123?next_run=true, and compare the previous output with this one to
> > see what will be changed.
> > 
> > Is this sufficient?
> 
> Hi,
> 
> so how are we expect the users to use this feature? I understand that in
> case we use directly RestAPI or SDK. We are expected to process the results.
> But what about the stacket management tools like Ansible. There is no proper
> way to process the output in Ansible. The comparison of the current
> configuration and the next run is close to impossible. 

So we should open a BZ for Ansible, as it makes sense to have that in the "higher management" functions. As the API provides this functionality, in case the customes is using the API, he is also in charge of checking this, if needed.

I would propose a warning from ansible in case there is a next-run config available, so the consumer knows he should check that one as well.

I don't think we should "automagically" update the next_run as well, as it could be wanted.
As such I think  a warning in Ansible is sufficient.

> 
> If you want to see the next run you are mostly interested only in the
> changes. I believe that the API/Ansible should make it much easier than now.
> 

I believe it makes sense to have that in Ansible.
@Moran: Could you move that BZ to Ansible after reviewing the ask?

> What do you think?

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days