-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Central Repository: plugin install and sync #45
Central Repository: plugin install and sync #45
Conversation
a7a2ec1
to
cb3135a
Compare
BTW, with this PR, you can easily manually access the DB of the Central Repo being used, if needed: |
a0016d3
to
009b63b
Compare
pkg/discovery/oci_central.go
Outdated
func (od *OCIDiscoveryForCentralRepo) getPluginsFromDB(dbFilePath string) ([]Discovered, error) { | ||
db, err := sql.Open("sqlite3", dbFilePath) | ||
if err != nil { | ||
return nil, errors.Wrapf(err, "failed to open the DB for discovery '%s'", od.Name()) | ||
} | ||
defer db.Close() | ||
|
||
// We need to order the results properly because the logic of processRows() | ||
// expects an ordering of PluginName, then Target, then Version. | ||
// The column order must also match the order used in getNextRow(). | ||
dbQuery := "SELECT PluginName,Target,RecommendedVersion,Version,Hidden,Description,Publisher,Vendor,OS,Architecture,Digest,URI FROM PluginBinaries ORDER BY PluginName,Target,Version;" | ||
rows, err := db.Query(dbQuery) | ||
if err != nil { | ||
return nil, errors.Wrapf(err, "unable to setup DB query for discovery '%s'", od.Name()) | ||
} | ||
defer rows.Close() | ||
|
||
allPluginPtrs, err := od.processRows(rows) | ||
if err != nil { | ||
return nil, err | ||
} | ||
|
||
// Convert from plugin pointers to plugins | ||
// TODO(khouzam): continue optimizing by converting every call | ||
// to using pointers | ||
var allPlugins []Discovered | ||
for _, pluginPtr := range allPluginPtrs { | ||
allPlugins = append(allPlugins, *pluginPtr) | ||
} | ||
return allPlugins, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we put this into a separate golang package that handles all the SQL queries together?
We need to add more SQL queries that can be used at multiple places. Combining all SQL queries related stuff into separate packages might be better. WDYT? @marckhouzam
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a good idea. I will work something out and update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to factoring out the db access from the logic of obtaining the 'db' via the OCI registry to minimize churn should we elect to use a different db backend in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pushed a commit to address this.
The approach I took is to create a new DiscoveryBackend
interface. A DiscoveryBackend
represents the content management logic behind a plugin Discovery
. The commit also creates an implementation of this new DiscoveryBackend
for the SQLite backend of the Central Repository.
Note: The DiscoveryBackend
support is included in the "discovery" package itself at the moment. This is so that it can use the Discovered
type. Making the new DiscoveryBackend
part of its own package would prevent it from using the Discovered
type due to a cyclical dependency. This would then force us to create yet another type to characterize plugins for the DiscoveryBackend
to use. This new type would then need to be converted to the Discovered
type by the Discovery
.
An alternative would be to move the Discovered
type to its own package that could be imported by both the "discovery" package, and a new "discoverybackend" package.
We should discuss this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have discussed this and we have agreed that we will create a new type that the DiscoveryBackend
can return, so as to decouple the DiscoveryBackend
from the discovery
package.
This will be done in a follow-up PR to allow this PR to get in now.
d9e2e95
to
3dc26f0
Compare
I've added a commit to this PR to so that |
3dc26f0
to
f49f84d
Compare
Actually, this is incomplete for the Central Repo feature. Context plugins need to be installed from the Central Repo, which this commit does not. I will update. |
f49f84d
to
dd31e2b
Compare
This has been done with Anuj's guidance 👍 |
dd31e2b
to
d198773
Compare
9b2edee
to
2e6793f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overall changes look good. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks for the refactoring and renaming.
I have some nits that are not blocking
a8689c3
to
8a8483a
Compare
When enabling the "features.global.central-repository" feature flag, it is now possible install plugins from a Central Repository. tanzu plugin install: working tanzu plugin clean: working tanzu plugin upgrade: working tanzu plugin describe: working tanzu plugin sync: working, now only syncs context plugins. tanzu plugin list: lists *all* plugins from the Central Repo. This will be optimized in a follow-up commit. This first implementation fetches all plugins from the SQLite DB all the time. It is then the plugin manager that filters the list of plugins to find the correct one. We took this approach to reduce the code changes necessary, but this will optimized in a follow-up effort. As part of this effort we create a new DiscoveryBackend interface. A DiscoveryBackend is the inventory management logic behind a plugin Discovery. This commit creates a DiscoveryBackend implementation for the SQLite backend of the Central Repository. Signed-off-by: Marc Khouzam <kmarc@vmware.com>
8a8483a
to
32de66d
Compare
What this PR does / why we need it
This commit creates a new OCI discovery implementation which handles the Central Repository format.
When enabling the "features.global.central-repository" feature flag, it is now possible install plugins from a Central Repository.
tanzu plugin install
: workingtanzu plugin clean
: workingtanzu plugin upgrade
: workingtanzu plugin describe
: workingtanzu plugin list
: lists all plugins from the Central Repo. #53 fixed this.tanzu plugin sync
: only syncs from current contexts, but not yet installing from Central repo. This will be part of another PR, since it is a substantial change.This first step fetches all plugins from the SQLite DB all the time. Then the plugin manager filters the list of plugins to find the correct one. I took this approach to reduce the code changes necessary, but this will optimized in a follow-up effort.
Describe testing done for PR
I've tested this with a test Central Repository from #41. You can follow these steps:
To test plugin sync:
Release note
Additional information