I have a bunch of keys in a keyring that I want to destroy (essentially "cleaning-up" the keyring. I've currently written a script that (using gcloud cli):
will iterate through all the keys
grab all versions for each key
destroy each version
Is there a better way to go about this? A bulk destroy of all versions at once for a particular key for example?
These keys are configured with a scheduled auto-rotation. If I schedule all the versions for destruction but the next rotation period is before the key version is destroyed, will it still rotate? Do I also have to disable key rotation on all these keys to really prevent them from coming back??
Your algorithm is correct.
Yes, this is the best way. You can parallelize the deletion operations to make it go faster.
Deleting key versions does not disable the rotation policy. You must disable key rotation policies to prevent new key versions from being created.
Related
How can I make OrionLD recognize when I update the content of a context file referenced by OrionLD?
In previous versions of OrionLD, you could get the latest context by restarting OrionLD.
However, with the implementation of the Persist context cache feature, it is no longer possible to overwrite the context information.
(https://github.com/FIWARE/context.Orion-LD/pull/844)
Is there any way to do this?
I restarted OrionLD and mongoDB, but
OrionLD and mongoDB were restarted, but the latest context was not recognized.
Do I need to manually delete the document in mongoDB where the context information is stored?
■My environment
・Orion
：fiware/orion-ld:latest
(post-v0.8.1)
・Mongo
：mongo:3.6
Thank you.
Sorry about that. We recently defined how this is to work in ETSI ISG CIM, the workgroup that defines the NGSI-LD API. It's not public yet, but I will try to implement this asap anyway. As of right now, yeah, I'm afraid a manual delete from mongo is the only way to do it.
WAIT ...
I did implement the DELETE request on cached contexts. For that you'll need the local identifier (GET /ngsi-ld/v1/jsonldContexts). Once you have the local identifier you can ask the broker to DELETE the context and after that, it will be downloaded anew.
It's a pretty good "workaround" until I implement the "overwrite" option for cached contexts.
The olm-book mentions about dependency resolution during install time, can you please also describe how uninstall/cleanup works.
Does the OLM keep reference counter of dependent operators when its a shared dependency ?
How to cleanup the dependent operators and when to do this?
olm-book : https://operator-framework.github.io/olm-book/docs/operator-dependencies-and-requirements.html
I can explain on how operator-sdk cleanup command works while uninstalling an operator bundle/packagemanifest managed by OLM.
The first step of the process is to identify and remove the subscription so that we stop any upgrades or further installs. Followed by this, we get the ClusterServiceVersion for the particular operator which is to be uninstalled from the subscription itself. When OLM creates resources it adds owner references/owner label to every namespaced/cluster scoped resource specified in the CSV. Hence, when a CSV is deleted the OLM garbage collector identifies the dependent resources through the owner references and deletes them.
If you want to cleanup the operator manually, I would suggest to just remove the ClusterServiceVersion referenced in installplan and leave it to the OLM and Kubebuilder GC to delete the resources.
Does Sublime Text (2|3) have an API method or some way of determining if a shortcut or hot key sequence has already been assigned? I have lots of plugins and macros installed, and when making new ones it can be difficult to determine what key sequence to assign it to so I don't conflict with something else. Key bindings can be assigned in .sublime-keymap files in Packages/Default, Packages/User, and whichever plugin wants to assign them. To make things more complicated, I work on three different OSes, and there are different keymaps for each platform. Do I have to keep manually searching all the keymap files myself, or is there a better way to do it?
You might try installing and using FindKeyConflicts.
You can also open a console ctrl + ` and enter sublime.log_commands(True). You can then enter your shortcut/key sequence and see what, if anything, is bound to it.
We have inherited some code that makes use of Linq2Sql and we've just found that an instance of the Data Context is being stored in a class member that is defined as private. As this class is used inside a web application once the class is created, an instance of the data context will be created and assigned to the static member - resulting in an instance of the data context that will now be used by all instances of that class (so across all users, a potential problem in itself) but also that instance of the data context will now exist for the duration of the web application (as it is held in a static class member).
Ignoring the bad design decisions that were originally taken, my question here is what happens to the data read into the data context? I know the session in NHibernate keeps a reference to any objects it reads / creates so it can track changes, etc. and the session can slowly grow and grow and never clears out unless you implicitly tell it to. Does Linq2Sql do something similar, so if the web application lived for ever (without recycling) would this linq2Sql context slowly grow until the machine either ran out of memory, or potentially it has read the entire database by satisfying the incoming requests? It's my understanding that a context isn't usually like a cache, which will remove items that "expire" from itself, or when hitting a memory limit, start removing least used items. Because of what it does, I don't think the data context is ever able to do that? Has anyone had experience of this, and either confirm my understanding or provide a reference to show what a long lived data context can do to stop this happening.
Yes the DataContext will keep track of objects it has read if its ObjectTrackingEnabled property is set to true. It is enabled by default. You cannot change the value of ObjectTrackingEnabled to false if the DataContext is already tracking state.
We set ObjectTrackingEnabled to false when we are just doing reads with no intention of making any changes. You cannot call SubmitChanges when ObjectTrackingEnabled is set to false.
I hope that helps.
Yes, a DataContext will retain references to all of the objects that have ever been associated with it. It might be that objects that have been deleted will be expelled from the cache, but otherwise it holds on to them, no matter how much memory it will cost.
Depending on the architecture and the size of the data set, the worker process will, at some point, run out of memory and crash. The only remedy would be to disable object tracking (through ObjectTrackingEnabled) or to refactor the code so it either uses a single DataContext per request, or (and this is not recommended) to regularly recycle the application-wide DataContext.
Non-trivial native extensions will require per-interpreter data
structures that are dynamically allocated.
I am currently using Tcl_SetAssocData, with a key corresponding
to the extension's name and an appropriate deletion routine,
to prevent this memory from leaking away.
However, Tcl_PkgProvideEx also allows one to record such
information. This information can be retrieved by
Tcl_PkgRequireEx. Associating the extension's data structures
with its package seems more natural than in the "grab-bag"
AssocData; yet the Pkg*Ex routines do not provide an
automatically invoked deletion routine. So I think I need
to stay with the AssocData approach.
For which situations were the Pkg*Ex routines designed for?
Additionally, the Tcl Library allows one to install
ExitHandlers and ThreadExitHandlers. Paraphasing the
manual, this is for flushing buffers to disk etc.
Are there any other situations requiring use of ExitHandlers?
When Tcl calls exit, are Tcl_PackageUnloadProcs called?
The whole-extension ClientData is intended for extensions that want to publish their own stub table (i.e., an organized list of functions that represent an exact ABI) that other extensions can build against. This is a very rare thing to want to do; leave at NULL if you don't want it (and contact the Tcl core developers' mailing list directly if you do; we've got quite a bit of experience in this area). Since it is for an ABI structure, it is strongly expected to be purely static data and so doesn't need deletion. Dynamic data should be sent through a different mechanism (e.g., via the Tcl interpreter or through calling functions via the ABI).
Exit handlers (which can be registered at multiple levels) are things that you use when you have to delete some resource at an appropriate time. The typical points of interest are when an interpreter (a Tcl_Interp structure) is being deleted, when a thread is being deleted, and when the whole process is going away. What resources need to be specially deleted? Well, it's usually obvious: file handles, database handles, that sort of thing. It's awkward to answer in general as the details matter very much: ask a more specific question to get tailored advice.
However, package unload callbacks are only called in response to the unload command. Like package load callbacks, they use “special function symbol” registration, and if they are absent then the unload command will refuse to unload the package. Most packages do not use them. The use case is where there are very long-lived processes that need to have extra upgradeable functionality added to them.