Swiftstack - Containers not getting removed - openstack-swift

Even after deleting containers and objects directly from file system, Swift is listing the containers when executed GET command on it. However, if we try to delete the container with DELETE command then 404: Not Found error message is returned. Please explain whether there is something wrong or is there some kind of cache?

I think the problem came from deleting the containers and/or objects directly from the file system.
Swift's methods for handling write requests for object and container have to be very careful to ensure all the distributed index information remains eventually consistent. Direct modification of the file system is not sufficient. It sounds like the container databases got removed before they had a chance to update the account databases listings - perhaps manually unlinked before all of the object index information was removed?
Normally after a delete request the containers have to hang around for awhile as "tombstones" to ensure the account database gets updated correctly.
As a work around you could recreate them (with a POST) and then re-issue the DELETE; which should successfully allow the DELETE of the new empty containers and update the account database listing directly.
(Note: the container databases themselves, although empty, will still exist on disk as tombstones until the the reclaim_age passes)

Related

Adding an exception to kubernetes garbage collection

In our project we have multiple cron-job using very large images, configured to run pretty often.
Whenever the garbage collection threshold is met images associated with those cron-jobs are removed, because they are not currently in use. Pulling those images from repository whenever they are needed introduces some problems due to their size.
My question is can i make it so that images associated with cron-jobs are ommited during garbage collection? A way to add an exception?
So far the only thing i came up with was creating another deployment that would use same image 24/7 with some changes so that it's execution doesn't finish normally. So that the image is in use when garbage collection is triggered.
I don`t know the way to specify a list of image name exceptions to Image Garbage Collection Policy, but maybe you can workaround it by overriding a default value (2 minutes) of
Minimum age for an unused image before it is garbage collected.
through the following kubelet flags:
--minimum-image-ttl-duration=12h (by default it`s set to 2m - minutes)
the other user controlled flags are documented here
The above one I found in kubelet source code on GitHub

db2ilist shows the instance, but db2idrop says instance doesn't exists

/opt/IBM/db2_10_01/bin/db2ilist shows the instance db2inst1 exists. But, when I try to drop it using /opt/IBM/db2_10_01/instance/db2idrop it gives error:
The specified instance "db2inst1" does not exist. Specify an existing instance
name.
How to drop instance in such scenario
This can happen when Db2-instance removal was incorrectly performed, often if directories were manually removed or mount points unavailable etc.
To recover, study this page until you comprehend it.
Become root and run
db2greg -dump
Study its output carefully and ensure you comprehend the output (read the documentation carefully).
You may see the line that identifies the db2inst1 - so carefully verify that each detail matches your expectation and the documentation.
Take a secure backup of the global-registry-file. This is a vital step.
As root, run db2greg without any arguments and study the instructions. Your aim is to run db2greg -delinstrec with some additional options to identify the line to delete, via a comma-separated list of field=value tokens.
For example db2greg -delinstrec instancename=db2inst1,instancepath=... etc.
When db2greg -delinstrec completes successfully (it takes a couple of seconds), you can then run db2ilist and you should find that db2inst1 has disappeared.

Preventing Deletion with django-simple-history

I started using django-simple-history in order to keep the history but when I delete an object (from admin page at least) I notice that it is gone for good.
I suppose I could create tags and "hide" objects instead of deleting in my views but would be nice if there is an easier way with django-simple-history, which would also cover admin operations.
When objects are deleted, that deletion is also recorded in history. The object does not exist anymore, but its history is safe.
If you browse your database, you should find a table named:
[app_name]_history[model_name]
It contains a line with the last state of the object. That line also contains additional columns: history_id, history_change_reason, history_date, history_type. For a deletion, history_type will be set to "-" (minus sign).
Knowing that, it is possible to revert a deletion programmatically, but not through the Django Admin. Have a look at django-simple-history documentation for details on how to do it programmatically.
Hope that helps!

Update/overwrite DNS record Google Cloud

Does anyone know what is a best practice to overwrite records under Google DNS Cloud, using API? https://cloud.google.com/dns/api/v1/changes/create does not help!
I could delete and create, but it is not nice ;) and could cause an outage.
Regards
The Cloud DNS API uses Changes objects to perform the update actions; you can create Changes but you don't ever delete them. In the Cloud DNS API, you never operate directly on the resource record sets. Instead, you create a Changes object with your desired additions and deletions and if that is created successfully, it applies those updates to the specified resource record sets in your managed DNS zone.
It's an unusual mental model, sort of like editing a file by specifying a diff to be applied, or appending to the commit history of a Git repository to change the contents of a file. Still, you can certainly achieve what you want to do using this API, and it is applied atomically at the authoritative servers (although the DNS system as a whole does not really do anything atomically, due to caching, so if you know you will be making changes, reduce your TTLs before you make the changes). The atomicity here is more about the updates themselves: if you have multiple applications making changes to your managed zones, and there are conflicts in changes to the particular record sets, the create operation will fail, and you will have retry the change with modified deletions (rather than having changes be silently overwritten).
Anyhow, what you want to do is to create a Changes object with deletions that specifies the current resource record set, and additions that specifies your desired replacement. This can be rather verbose, especially if you have a domain name with a lot of records of the same type. For example, if you have four A records for mydomain.example (1.1.1.1, 2.2.2.2, 3.3.3.3, and 4.4.4.4) and want to change the 3.3.3.3 address to 5.5.5.5, you need to list all four original A records in deletions and then the new four (1.1.1.1, 2.2.2.2, 4.4.4.4, and 5.5.5.5) in additions.
The Cloud DNS documentation provides example code boilerplate that you can adapt to do what you want: https://cloud.google.com/dns/api/v1/changes/create#examples, you just need to set the deletions and additions for the Changes object you are creating.
I have never used APIs for this purpose, but if you use command line i.e. gcloud to update DNS records, it binds the change in a single transaction and both tasks of deleting the record and adding the updated record are executed as a single transaction. Since transactions are atomic in nature, it shouldn't cause any outage.
Personally, I never witnessed any outage while using gcloud for updating DNS settings for my domain.

radosgw remain shadow files when I delete objects in pool

I deployed the rgw in my cluster and when I did the test,I frequently uploaded and deleted the objects,and after that I found a lot of shadows files remain in .rgw.buckets,I try to run the commend:radosgw-admin temp remove but it give me a error which arg remove cannot be recognized.I also try to config gc but gc list always gives me en empty list.
Could someone tell how to deal with shadow file or how to delete them?
Thanks so much
the gc triggers after sometime, but it does take a few hours before it can get all the shadow objects... What does gc list --include-all show? In general, --include-all may show the objects pending deletion) Does it decrease after a few hours?
Another option is to try finding orphaned objects using radosgw-admin orphans find on the pool, these can be deleted later manually via a rados client of choice (edit not sure why my previous answer got deleted..)