The project is divided into three phases: getting the information (in our database), removing the (existing) information, restoring the (updated) information. I know, it doesn’t seem to be a really efficient logic but we plan to improve it further as we go.
First Phase: The action `snapshot` aims to replicate the user install commands. The plan was to implement this using database and not files, so it justifies the need to add support for the tables to the entire stack up from cregistry.
- The snapshot action basically takes a complete copy of all the installed ports and the metadata. Till now,
- 3 new sqlite tables have been added to the registry’s create and update function and regsitrydb version renewed so that existing installations get them too.
- snapshot_create in registry2.0/entry.c enables access to the sqlite database from Tcl frontend using registry APIs. It calls cregistry/entry.c reg_snapshot_create internally.
- reg_snapshot_create creates a snapshot in the snapshots table, calls snapshot_store_ports.
- snapshot_store_ports stores info on all currently installed ports in the snapshot_ports table (and requested flag)
- snapshot_store_port_variants stores port variants with the sign in the corresponding table. It depends on getting parsed variants which I have not written yet (reason below).
- Time spent on figuring out things initially counts as well, right? Only if this does not become an endless excuse.
- for a long time, Tcl or C? In what language do I have to write the above three functions, Tcl or C? Believe me, this is not something you ask your mentor or community or perhaps, anyone. Then I started looking at the implementation of existing commands, one by one, took 3 to 4 days, and then one fine morning, I saw the mapping array from command to function. It was there, right at the bottom of entry.c. Yes, if you give this argument to registry::entry, this method will be called. Had a sound sleep that afternoon.
- for a short time, probably for a day, that there exists something like reg_entry_propget to help you see through dark, to get what you want, just give the key. Should have spent more time going through C files than Tcl ones during community bonding period :/.
- Only one variant of a port can be active at a time. Makes sense. Running `port install apache2 -preforkmpm +workermpm` and then `port install apache2 +openldap` saves apache2 as two different ports in the registry. So, reg_entry_propget only returns one variant of a port when passed as reg_entry pointer. Now, how do I link the two variants installed (note installed and not active) to the same port in my database? If not, all we are left is with one variant mapped to “each” port, questioning the need for snapshot_port_variants table.
- Till ^ gets resolved, I won’t be able to write get_variants_parsed function.
- IMPORTANT: where to add the OS check? I tried starting a discussion on this but never arrived at a decent conclusion.
- where to include the --list for listing snapshots? if with `snapshot` action, then it creates the need for --create which I do not prefer personally. But if with `restore`, then `port restore --list` doesn’t appeal as well. Only if a command existed which lists the choices first and then proceeds so that I could simply copy their design strategy and save myself from confusion every time I decide to do things nicely.
- limiting the number of snapshots that a user can take?
- and more to come :).
I like this one:
Also, I forget, the unreviewed commits are here.
EDIT:
EDIT:
A doubt, so fundamental to my project, that got cleared while writing this post:
- We’re solving for these two end use cases (correct me if I'm wrong):
- running simply `migrate` is (snapshot the current installed state + restore).
- `snapshot` followed by `restore`: restoring back some existing snapshot.
- Interactive restore could be a solution for --list?
Nice Umesh. keep going !!!
ReplyDeletethanks..
Delete