[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[atomic-devel] Atomicapp changes for Atomic CLI: use UUIDs for management

I have had a few discussions with Dan and with the Atomic App core
team over the past few weeks. We have recognized some changes that we
can make to Atomic App to make the integration go easier. Below is one
proposed change:

- atomicapp will now manage instances of applications in a similar
manner to the way docker does by using IDs rather than the backing
directory locations as arguments to atomicapp. This means that rather
than the atomicapp software notifying you of a directory path where
your application can be managed from, it will now hand you an ID you
can use to manage it:

atomic install helloapache
--> <idxyz>
atomic edit <idxyz>
--> will open up text editor for answers.conf file
atomic run <idxyz>
--> will run application identified by <idxyz>
atomic stop <idxyz>
--> will stop application identified by <idxyz>
atomic uninstall <idxyz>
--> will remove it from disk: <idxyz> metadata will no longer exist

Running an install and edit is not necessary though. This could work

atomic run helloapache
--> <idxyz>

As well as:

atomic run --answers=/path/to/answers.conf helloapache
--> <idxyz>

We can allow for naming as well:

atomic install --name fooapp helloapache
--> <idxyz>
atomic run fooapp
--> runs <idxyz> -- you can use name instead of id
atomic stop fooapp
--> stops app identified by <idxyz>

As part of this we'd like to make Atomic CLI able to detect if a user
has provided an id or name of an existing "installed" atomicapp. One
crude way to do this is to simply use the directory structure that is
used to manage the atomicapps and making it have a predictable naming scheme.
basically if the directory used the IDs as the directory names then
Atomic CLI could easily scan these and see if the provided argument
corresponds to an existing app or not and then call out to atomicapp
to handle the user's request. Similarly, the "names" that users could
possible give could be simulated as symbolic links to the id of that

APPS_DIRECTORY/fidoapp -> app-4acdb09

This would require us to make sure that failures are handled
appropriately so as to not mess up the directory structure.

Does this way of managing atomicapps/nulecules seem reasonable?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]