In this lecture, we will understand more about how the two apply command works.
In the previous lecture, we saw how a up man can be used to manage objects in a declarative way.
This lecture, we'll see a bit more about how the command works internally.
The Apollo command takes into consideration the local configuration file, a live object definition
on coroneted and the last applied configuration before making a decision on what changes are to be made.
So when you run the appli command, if the object does not already exist, the object is created when
the object is created.
An object configuration similar to what we created locally is created within communities, but with
additional fields to store status of the object.
This is the live configuration of the object on the governor's cluster.
This is how communities internally are stores information about an object no matter what approach you
use to create the object.
But when you use the computer, apply command to create an object, it does something a bit more.
The Yamal version of the local object configuration file road is converted to a Jason format, and it
is then stored as the last applied configuration going forward for any updates to the object.
All the three are compared to identify what changes are to be made on the live object.
For example, say when the next image is updated to one dot one nine in our local file and we run the
apply command.
This value is compared with the value in the live configuration and if there is a difference, the life
configuration is updated with the new value.
After any change.
The last applied Jason format is always updated to the latest so that it's always up to date.
So why do we then really need the last applied configuration, right?
So if a field was deleted, say, for example, the typed label was deleted, and now when we run the
computer up like a man, we see that the last applied configuration had a label, but it's not present
in the local configuration.
This means that the field needs to be removed from the live configuration.
So if a field was present in the live configuration and not present in the local or the last applied
configuration, then it will be left as is.
But if a field is missing from the local field and it is present in the last applied configuration,
so that means that in the previous step or whenever the last time we ran the program in that particular
field was there and it is now being removed.
So the last applied configuration helps us figure out.
What field fields have been removed from the local fire?
Right, so that field is then removed from the actual live configuration.
What we just discussed is available for your reference in detail in the cabinet is document pages,
so follow this link to view that, OK, so we saw the three sets of files and we know that the local
file is what's stored on our local system.
The live object configuration is in the community's memory.
But where is this Jason file that has the last applied configuration stored?
Well, it's stored on the live object configuration on the cabin in this cluster itself as an annotation
named last applied configuration.
So remember that this is only done when you use the apply command, the cuttle create or replace command
do not stored the last applied configuration like this.
So you must bear in mind not to mix the imperative and declarative approaches while managing the Cabinet
as objects.
So once you use the API command going forward, whenever a change is made, the API command compares
all three sections.
The local definition file, the live object configuration and the last applied configuration stored
within the life object configuration file for deciding what changes are to be made to the live configuration,
similar to what we saw in the previous slide.
Well, that's it for this lecture.
I will see you in the next.