1

00:00:00,580 --> 00:00:05,790

In this lecture, we will understand more about how the two apply command works.



2

00:00:06,890 --> 00:00:13,680

In the previous lecture, we saw how a up man can be used to manage objects in a declarative way.



3

00:00:14,390 --> 00:00:18,530

This lecture, we'll see a bit more about how the command works internally.



4

00:00:20,630 --> 00:00:27,710

The Apollo command takes into consideration the local configuration file, a live object definition



5

00:00:27,710 --> 00:00:35,850

on coroneted and the last applied configuration before making a decision on what changes are to be made.



6

00:00:36,530 --> 00:00:44,900

So when you run the appli command, if the object does not already exist, the object is created when



7

00:00:44,900 --> 00:00:46,190

the object is created.



8

00:00:46,430 --> 00:00:52,940

An object configuration similar to what we created locally is created within communities, but with



9

00:00:52,940 --> 00:00:55,520

additional fields to store status of the object.



10

00:00:56,270 --> 00:01:00,690

This is the live configuration of the object on the governor's cluster.



11

00:01:01,160 --> 00:01:08,240

This is how communities internally are stores information about an object no matter what approach you



12

00:01:08,240 --> 00:01:09,610

use to create the object.



13

00:01:10,280 --> 00:01:15,350

But when you use the computer, apply command to create an object, it does something a bit more.



14

00:01:16,100 --> 00:01:24,620

The Yamal version of the local object configuration file road is converted to a Jason format, and it



15

00:01:24,620 --> 00:01:31,500

is then stored as the last applied configuration going forward for any updates to the object.



16

00:01:31,880 --> 00:01:37,940

All the three are compared to identify what changes are to be made on the live object.



17

00:01:38,450 --> 00:01:47,630

For example, say when the next image is updated to one dot one nine in our local file and we run the



18

00:01:48,230 --> 00:01:49,100

apply command.



19

00:01:49,580 --> 00:01:56,420

This value is compared with the value in the live configuration and if there is a difference, the life



20

00:01:56,420 --> 00:01:59,480

configuration is updated with the new value.



21

00:02:00,170 --> 00:02:01,270

After any change.



22

00:02:01,310 --> 00:02:08,720

The last applied Jason format is always updated to the latest so that it's always up to date.



23

00:02:10,200 --> 00:02:15,210

So why do we then really need the last applied configuration, right?



24

00:02:15,630 --> 00:02:22,240

So if a field was deleted, say, for example, the typed label was deleted, and now when we run the



25

00:02:22,290 --> 00:02:28,740

computer up like a man, we see that the last applied configuration had a label, but it's not present



26

00:02:28,920 --> 00:02:31,170

in the local configuration.



27

00:02:31,710 --> 00:02:36,110

This means that the field needs to be removed from the live configuration.



28

00:02:36,540 --> 00:02:42,750

So if a field was present in the live configuration and not present in the local or the last applied



29

00:02:42,750 --> 00:02:45,550

configuration, then it will be left as is.



30

00:02:45,900 --> 00:02:52,190

But if a field is missing from the local field and it is present in the last applied configuration,



31

00:02:52,200 --> 00:02:59,160

so that means that in the previous step or whenever the last time we ran the program in that particular



32

00:02:59,160 --> 00:03:01,850

field was there and it is now being removed.



33

00:03:02,280 --> 00:03:05,820

So the last applied configuration helps us figure out.



34

00:03:06,760 --> 00:03:10,870

What field fields have been removed from the local fire?



35

00:03:11,310 --> 00:03:16,510

Right, so that field is then removed from the actual live configuration.



36

00:03:17,500 --> 00:03:24,330

What we just discussed is available for your reference in detail in the cabinet is document pages,



37

00:03:24,340 --> 00:03:32,320

so follow this link to view that, OK, so we saw the three sets of files and we know that the local



38

00:03:32,320 --> 00:03:34,590

file is what's stored on our local system.



39

00:03:34,600 --> 00:03:38,170

The live object configuration is in the community's memory.



40

00:03:38,500 --> 00:03:42,940

But where is this Jason file that has the last applied configuration stored?



41

00:03:43,810 --> 00:03:50,380

Well, it's stored on the live object configuration on the cabin in this cluster itself as an annotation



42

00:03:50,680 --> 00:03:53,480

named last applied configuration.



43

00:03:54,220 --> 00:04:00,370

So remember that this is only done when you use the apply command, the cuttle create or replace command



44

00:04:00,760 --> 00:04:03,340

do not stored the last applied configuration like this.



45

00:04:03,350 --> 00:04:10,690

So you must bear in mind not to mix the imperative and declarative approaches while managing the Cabinet



46

00:04:10,690 --> 00:04:11,270

as objects.



47

00:04:12,010 --> 00:04:18,340

So once you use the API command going forward, whenever a change is made, the API command compares



48

00:04:18,340 --> 00:04:19,510

all three sections.



49

00:04:19,510 --> 00:04:25,200

The local definition file, the live object configuration and the last applied configuration stored



50

00:04:25,240 --> 00:04:31,840

within the life object configuration file for deciding what changes are to be made to the live configuration,



51

00:04:31,840 --> 00:04:33,580

similar to what we saw in the previous slide.



52

00:04:34,300 --> 00:04:36,070

Well, that's it for this lecture.



53

00:04:36,280 --> 00:04:37,900

I will see you in the next.