--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Have you looked at my zero-downtime upgrades on SlideShare?
HTHLucaSent from my iPhone
Hello,--As I can see for Gerrit of Gerrit source code, you upgrade versions automaticaly.We want to have the new release installed automaticaly in the night after that are published.How can I do the same mainly for the shema upgrade of database ?Thanks per advance.
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
On 22 Nov 2016, at 12:05, Saša Živkov <ziv...@gmail.com> wrote:On Sat, Nov 19, 2016 at 2:25 PM, <luca.mi...@gmail.com> wrote:Have you looked at my zero-downtime upgrades on SlideShare?Hi Luca,thanks for sharing your slides! Nice work!I have a few questions about your slides:After the Stage 3 (slide 15) the schema version on the copy is higher than the schemaversion on the productive system (for a major upgrade).
During Stage 5 you perform DB export/import again. How does it work when theschema version is different?
I guess that during the init you make sure not to dropunneeded tables/columns?
In stage 6 you perform an init again?
What would that init do when the schemaversion is already up-to-date?
Hi Saša,see my feedback below.On 22 Nov 2016, at 12:05, Saša Živkov <ziv...@gmail.com> wrote:On Sat, Nov 19, 2016 at 2:25 PM, <luca.mi...@gmail.com> wrote:Have you looked at my zero-downtime upgrades on SlideShare?Hi Luca,thanks for sharing your slides! Nice work!I have a few questions about your slides:After the Stage 3 (slide 15) the schema version on the copy is higher than the schemaversion on the productive system (for a major upgrade).Yes.During Stage 5 you perform DB export/import again. How does it work when theschema version is different?Thanks for the question :-)Stage 5 will:- import a Version X of the DB (old version)
- keep an existing Version X + N of the Index (new version)I guess that during the init you make sure not to dropunneeded tables/columns?We don't do init at Stage 5. Week keep version X of the DB.
In stage 6 you perform an init again?Yep, because at Stage 5 the DB would have come back to version X. So we need to upgrade it again to version X + N.
What would that init do when the schemaversion is already up-to-date?Nothing, keep it as-is.
Saša
HTHLucaSent from my iPhone
Hello,As I can see for Gerrit of Gerrit source code, you upgrade versions automaticaly.We want to have the new release installed automaticaly in the night after that are published.How can I do the same mainly for the shema upgrade of database ?Thanks per advance.--
--
To unsubscribe, email repo-discuss+unsub...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 22 Nov 2016, at 12:45, Saša Živkov <ziv...@gmail.com> wrote:On Tue, Nov 22, 2016 at 1:33 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:Hi Saša,see my feedback below.On 22 Nov 2016, at 12:05, Saša Živkov <ziv...@gmail.com> wrote:On Sat, Nov 19, 2016 at 2:25 PM, <luca.mi...@gmail.com> wrote:Have you looked at my zero-downtime upgrades on SlideShare?Hi Luca,thanks for sharing your slides! Nice work!I have a few questions about your slides:After the Stage 3 (slide 15) the schema version on the copy is higher than the schemaversion on the productive system (for a major upgrade).Yes.During Stage 5 you perform DB export/import again. How does it work when theschema version is different?Thanks for the question :-)Stage 5 will:- import a Version X of the DB (old version)Basically this replaces the existing DB (X+N version) with the DB from the productive instance (version X).I think naming this step "replace" instead of "import" is more precise?
- keep an existing Version X + N of the Index (new version)I guess that during the init you make sure not to dropunneeded tables/columns?We don't do init at Stage 5. Week keep version X of the DB.Sorry, I was referring to the init from the stage 3.
In stage 6 you perform an init again?Yep, because at Stage 5 the DB would have come back to version X. So we need to upgrade it again to version X + N.This assumes that all schema migrations are idempotent i.e. if something was already migrated from DB to Git thenrunning the same schema migration will handle that gracefully. Which usually is the case :-)
On 24 Nov 2016, at 09:04, Damien Chesneau <ches....@gmail.com> wrote:Hello,I have read this, thats a great help for us.How to get schema update script automaticaly, do you have in gerrit a folder with all this scripts ?
And you explain 1/2 month of planning for a repo upgrade but we need to do this in 10 min max.
Hi Steffen,the "read only" plugin is a Groovy script and can be found at [2].With regards to REST API, we just added some simple rewrite rules. The missing bit was the state changes that could be triggered via SSH (review / verified by robots or Jenkins).The read-only window last however for a couple of minutes, so the risk of losing some of them would not have been high.Setting the projects with "read only" state would work as well, however you would need to record the status "pre-readonly" and resume it correctly afterwards.
On Thu, Nov 24, 2016 at 6:11 PM Luca Milanesio <luca.mi...@gmail.com> wrote:Hi Steffen,the "read only" plugin is a Groovy script and can be found at [2].With regards to REST API, we just added some simple rewrite rules. The missing bit was the state changes that could be triggered via SSH (review / verified by robots or Jenkins).The read-only window last however for a couple of minutes, so the risk of losing some of them would not have been high.Setting the projects with "read only" state would work as well, however you would need to record the status "pre-readonly" and resume it correctly afterwards.I've started working on making this into a standalone plugin.So far I've uploaded 2 changes:The first simply mimics the functionality of the existing groovy plugin, using the commit validator to block all incoming commits. The following change adds an HTTP filter that blocks POST/PUT/DELETE requests.
The missing piece is still the fact that state can be changed by ssh commands. I've been looking into the possibility of implementing a repository manager that opens the repositories read-only, but that doesn't seem to be very easy.
On Tue, Feb 20, 2018 at 10:15 PM David Pursehouse <david.pu...@gmail.com> wrote:On Thu, Nov 24, 2016 at 6:11 PM Luca Milanesio <luca.mi...@gmail.com> wrote:Hi Steffen,the "read only" plugin is a Groovy script and can be found at [2].With regards to REST API, we just added some simple rewrite rules. The missing bit was the state changes that could be triggered via SSH (review / verified by robots or Jenkins).The read-only window last however for a couple of minutes, so the risk of losing some of them would not have been high.Setting the projects with "read only" state would work as well, however you would need to record the status "pre-readonly" and resume it correctly afterwards.I've started working on making this into a standalone plugin.So far I've uploaded 2 changes:The first simply mimics the functionality of the existing groovy plugin, using the commit validator to block all incoming commits. The following change adds an HTTP filter that blocks POST/PUT/DELETE requests.These changes are now merged, so with the read only plugin it's possible to prevent changes being pushed (either directly or for review) and prevent any REST calls other than GET.The missing piece is still the fact that state can be changed by ssh commands. I've been looking into the possibility of implementing a repository manager that opens the repositories read-only, but that doesn't seem to be very easy.This is still the missing piece. Making a read-only repository manager likely won't solve it either, since some of the ssh commands cause changes in the database rather than in the git repository.If anyone has any ideas how to solve this, I would like to hear them :)
On Wednesday, February 28, 2018 at 6:01:04 AM UTC+1, David Pursehouse wrote:On Tue, Feb 20, 2018 at 10:15 PM David Pursehouse <david.pu...@gmail.com> wrote:On Thu, Nov 24, 2016 at 6:11 PM Luca Milanesio <luca.mi...@gmail.com> wrote:Hi Steffen,the "read only" plugin is a Groovy script and can be found at [2].With regards to REST API, we just added some simple rewrite rules. The missing bit was the state changes that could be triggered via SSH (review / verified by robots or Jenkins).The read-only window last however for a couple of minutes, so the risk of losing some of them would not have been high.Setting the projects with "read only" state would work as well, however you would need to record the status "pre-readonly" and resume it correctly afterwards.I've started working on making this into a standalone plugin.So far I've uploaded 2 changes:The first simply mimics the functionality of the existing groovy plugin, using the commit validator to block all incoming commits. The following change adds an HTTP filter that blocks POST/PUT/DELETE requests.These changes are now merged, so with the read only plugin it's possible to prevent changes being pushed (either directly or for review) and prevent any REST calls other than GET.The missing piece is still the fact that state can be changed by ssh commands. I've been looking into the possibility of implementing a repository manager that opens the repositories read-only, but that doesn't seem to be very easy.This is still the missing piece. Making a read-only repository manager likely won't solve it either, since some of the ssh commands cause changes in the database rather than in the git repository.If anyone has any ideas how to solve this, I would like to hear them :)I've uploaded new SSH command interceptor extension point: [1] andadded HijackCommandInterceptor to readonly plugin: [2], here in action:
$ ssh d gerrit versiongerrit version (dev)$ ssh d gerrit plugin enable readonly$ ssh d gerrit plugin lsName Version Status File-------------------------------------------------------------------------------readonly 60dedcd-dirty ENABLED readonly.jar$ ssh gerritd gerritSSH subsystem is disabled$ ssh gerritd gerrit plugin rm readonly$ ssh gerritd gerrit versiongerrit version (dev)
--
This is not the first time we introduce a new extension point in a stable branch: why don'y we cherry pick to stable-2.14?As long as it does not break any compatibility and preserves maximum stability, I don't see any problem with it :-)
Additionally, if no plugins are using it, it should be transparent to current Gerrit setups, correct?
Additionally, it would allow everyone in the community to perform Blue/Green deployments even during DB upgrades, which is very nice :-)Luca.On 28 Feb 2018, at 08:52, David Pursehouse <david.pu...@gmail.com> wrote:On Wed, Feb 28, 2018 at 5:49 PM Luca Milanesio <luca.mi...@gmail.com> wrote:This is not the first time we introduce a new extension point in a stable branch: why don'y we cherry pick to stable-2.14?As long as it does not break any compatibility and preserves maximum stability, I don't see any problem with it :-)I was just about to suggest exactly the same...