Re: load-server-state-from-file "automatic" transfer?
On Mon, Jul 29, 2019 at 11:28:29AM +0200, Daniel Schneller wrote: > Hi! > > Thanks for taking a look and explaining. Should I create a ticket on GitHub > for this? > > Daniel > > Sure, you can fill a feature request so we don't lose it. -- William Lallemand
Re: load-server-state-from-file "automatic" transfer?
Hi! Thanks for taking a look and explaining. Should I create a ticket on GitHub for this? Daniel > On 25. Jul 2019, at 10:44, William Lallemand wrote: > > On Thu, Jul 25, 2019 at 10:23:24AM +0200, Aleksandar Lazic wrote: >> Hi. >> >> Am 25.07.2019 um 10:06 schrieb William Lallemand: >>> On Thu, Jul 25, 2019 at 08:07:45AM +0200, Baptiste wrote: Hi Daniel, You're making a good point. Use the file system was the simplest and fastest way to go when we first designed this feature 4 or 5 years ago. I do agree that now with master/worker and threaded model being pushed that using the runtime-api may make sense and would be even more "cloud native". Maybe @William would have an advice on this one. Baptiste >>> >>> Hi, >>> >>> The simplest way to do that with the current architecture would be to do the >>> same thing as the "seamless reload" feature (-x). >>> >>> The new process will need to connect to the old one, send the `show servers >>> state` command, and then parse it using the server state file parser. >>> >>> However, what I don't like with this, is that we still need to configure a >>> "stats socket" manually in the configuration, it is not doable yet using the >>> internal socketpair of the master-worker model. >> >> How about to catch the idea from Daniel to use a *internal* peers setup for >> such >> states? >> > > I don't think it makes sense to use peers for that. > > The idea to do it with the stats socket is good, we only need to improve the > master-worker so a worker could use the socketpair to connect to another > worker. The only drawback is that it needs a configured stats socket in the > current model, but we already have this limitation with the seamless reload. > > -- > William Lallemand signature.asc Description: Message signed with OpenPGP
Re: load-server-state-from-file "automatic" transfer?
On Thu, Jul 25, 2019 at 10:23:24AM +0200, Aleksandar Lazic wrote: > Hi. > > Am 25.07.2019 um 10:06 schrieb William Lallemand: > > On Thu, Jul 25, 2019 at 08:07:45AM +0200, Baptiste wrote: > >> Hi Daniel, > >> > >> You're making a good point. Use the file system was the simplest and > >> fastest way to go when we first designed this feature 4 or 5 years ago. > >> I do agree that now with master/worker and threaded model being pushed that > >> using the runtime-api may make sense and would be even more "cloud native". > >> > >> Maybe @William would have an advice on this one. > >> > >> Baptiste > > > > Hi, > > > > The simplest way to do that with the current architecture would be to do the > > same thing as the "seamless reload" feature (-x). > > > > The new process will need to connect to the old one, send the `show servers > > state` command, and then parse it using the server state file parser. > > > > However, what I don't like with this, is that we still need to configure a > > "stats socket" manually in the configuration, it is not doable yet using the > > internal socketpair of the master-worker model. > > How about to catch the idea from Daniel to use a *internal* peers setup for > such > states? > I don't think it makes sense to use peers for that. The idea to do it with the stats socket is good, we only need to improve the master-worker so a worker could use the socketpair to connect to another worker. The only drawback is that it needs a configured stats socket in the current model, but we already have this limitation with the seamless reload. -- William Lallemand
Re: load-server-state-from-file "automatic" transfer?
Hi. Am 25.07.2019 um 10:06 schrieb William Lallemand: > On Thu, Jul 25, 2019 at 08:07:45AM +0200, Baptiste wrote: >> Hi Daniel, >> >> You're making a good point. Use the file system was the simplest and >> fastest way to go when we first designed this feature 4 or 5 years ago. >> I do agree that now with master/worker and threaded model being pushed that >> using the runtime-api may make sense and would be even more "cloud native". >> >> Maybe @William would have an advice on this one. >> >> Baptiste > > Hi, > > The simplest way to do that with the current architecture would be to do the > same thing as the "seamless reload" feature (-x). > > The new process will need to connect to the old one, send the `show servers > state` command, and then parse it using the server state file parser. > > However, what I don't like with this, is that we still need to configure a > "stats socket" manually in the configuration, it is not doable yet using the > internal socketpair of the master-worker model. How about to catch the idea from Daniel to use a *internal* peers setup for such states? Regards Aleks
Re: load-server-state-from-file "automatic" transfer?
On Thu, Jul 25, 2019 at 08:07:45AM +0200, Baptiste wrote: > Hi Daniel, > > You're making a good point. Use the file system was the simplest and > fastest way to go when we first designed this feature 4 or 5 years ago. > I do agree that now with master/worker and threaded model being pushed that > using the runtime-api may make sense and would be even more "cloud native". > > Maybe @William would have an advice on this one. > > Baptiste Hi, The simplest way to do that with the current architecture would be to do the same thing as the "seamless reload" feature (-x). The new process will need to connect to the old one, send the `show servers state` command, and then parse it using the server state file parser. However, what I don't like with this, is that we still need to configure a "stats socket" manually in the configuration, it is not doable yet using the internal socketpair of the master-worker model. -- William Lallemand
Re: load-server-state-from-file "automatic" transfer?
On Wed, Jul 24, 2019 at 1:38 PM Daniel Schneller < daniel.schnel...@centerdevice.com> wrote: > Hi! > > I have been looking into load-server-state-from file to prevent 500 errors > being > reported after a service reload. Currently we are seeing these, because > the new > instance comes up and first wants to see the minimum configured number of > health > checks for a backend server to succeed, before it hands requests to it. > > From what I can tell, the state file needs to be saved manually before a > service > reload, so that the new process coming up can read it back. I can do that, > of course, > but I was wondering what the reasoning was to not have this data > transferred to a > new process in a similar fashion as file handles or stick-tables (via > peers)? > > Thanks a lot! > > Daniel > > > > -- > Daniel Schneller > Principal Cloud Engineer > GPG key at https://keybase.io/dschneller > > CenterDevice GmbH > Rheinwerkallee 3 > 53227 Bonn > www.centerdevice.com > __ > Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina, Michael > Rosbach, Handelsregister-Nr.: HRB 18655, HR-Gericht: Bonn, USt-IdNr.: > DE-815299431 > > Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche > und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige > Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie > bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügte > Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. > beigefügter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht > gestattet. > > Pflichtinformationen gemäß Artikel 13 DSGVO > Im Falle des Erstkontakts sind wir gemäß Art. 12, 13 DSGVO verpflichtet, > Ihnen folgende datenschutzrechtliche Pflichtinformationen zur Verfügung zu > stellen: Wenn Sie uns per E-Mail kontaktieren, verarbeiten wir Ihre > personenbezogenen Daten nur, soweit an der Verarbeitung ein berechtigtes > Interesse besteht (Art. 6 Abs. 1 lit. f DSGVO), Sie in die > Datenverarbeitung eingewilligt haben (Art. 6 Abs. 1 lit. a DSGVO), die > Verarbeitung für die Anbahnung, Begründung, inhaltliche Ausgestaltung oder > Änderung eines Rechtsverhältnisses zwischen Ihnen und uns erforderlich ist > (Art. 6 Abs. 1 lit. b DSGVO) oder eine sonstige Rechtsnorm die Verarbeitung > gestattet. Ihre personenbezogenen Daten verbleiben bei uns, bis Sie uns zur > Löschung auffordern, Ihre Einwilligung zur Speicherung widerrufen oder der > Zweck für die Datenspeicherung entfällt (z. B. nach abgeschlossener > Bearbeitung Ihres Anliegens). Zwingende gesetzliche Bestimmungen – > insbesondere steuer- und handelsrechtliche Aufbewahrungsfristen – bleiben > unberührt. Sie haben jederzeit das Recht, unentgeltlich Auskunft über > Herkunft, Empfänger und Zweck Ihrer gespeicherten personenbezogenen Daten > zu erhalten. Ihnen steht außerdem ein Recht auf Widerspruch, auf > Datenübertragbarkeit und ein Beschwerderecht bei der zuständigen > Aufsichtsbehörde zu. Ferner können Sie die Berichtigung, die Löschung und > unter bestimmten Umständen die Einschränkung der Verarbeitung Ihrer > personenbezogenen Daten verlangen. Details entnehmen Sie unserer > Datenschutzerklärung (https://www.centerdevice.de/datenschutz/). Unseren > Datenschutzbeauftragten erreichen Sie per E-Mail unter erdm...@sicdata.de. > > > Hi Daniel, You're making a good point. Use the file system was the simplest and fastest way to go when we first designed this feature 4 or 5 years ago. I do agree that now with master/worker and threaded model being pushed that using the runtime-api may make sense and would be even more "cloud native". Maybe @William would have an advice on this one. Baptiste
load-server-state-from-file "automatic" transfer?
Hi! I have been looking into load-server-state-from file to prevent 500 errors being reported after a service reload. Currently we are seeing these, because the new instance comes up and first wants to see the minimum configured number of health checks for a backend server to succeed, before it hands requests to it. From what I can tell, the state file needs to be saved manually before a service reload, so that the new process coming up can read it back. I can do that, of course, but I was wondering what the reasoning was to not have this data transferred to a new process in a similar fashion as file handles or stick-tables (via peers)? Thanks a lot! Daniel -- Daniel Schneller Principal Cloud Engineer GPG key at https://keybase.io/dschneller CenterDevice GmbH Rheinwerkallee 3 53227 Bonn www.centerdevice.com __ Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina, Michael Rosbach, Handelsregister-Nr.: HRB 18655, HR-Gericht: Bonn, USt-IdNr.: DE-815299431 Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügte Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. Pflichtinformationen gemäß Artikel 13 DSGVO Im Falle des Erstkontakts sind wir gemäß Art. 12, 13 DSGVO verpflichtet, Ihnen folgende datenschutzrechtliche Pflichtinformationen zur Verfügung zu stellen: Wenn Sie uns per E-Mail kontaktieren, verarbeiten wir Ihre personenbezogenen Daten nur, soweit an der Verarbeitung ein berechtigtes Interesse besteht (Art. 6 Abs. 1 lit. f DSGVO), Sie in die Datenverarbeitung eingewilligt haben (Art. 6 Abs. 1 lit. a DSGVO), die Verarbeitung für die Anbahnung, Begründung, inhaltliche Ausgestaltung oder Änderung eines Rechtsverhältnisses zwischen Ihnen und uns erforderlich ist (Art. 6 Abs. 1 lit. b DSGVO) oder eine sonstige Rechtsnorm die Verarbeitung gestattet. Ihre personenbezogenen Daten verbleiben bei uns, bis Sie uns zur Löschung auffordern, Ihre Einwilligung zur Speicherung widerrufen oder der Zweck für die Datenspeicherung entfällt (z. B. nach abgeschlossener Bearbeitung Ihres Anliegens). Zwingende gesetzliche Bestimmungen – insbesondere steuer- und handelsrechtliche Aufbewahrungsfristen – bleiben unberührt. Sie haben jederzeit das Recht, unentgeltlich Auskunft über Herkunft, Empfänger und Zweck Ihrer gespeicherten personenbezogenen Daten zu erhalten. Ihnen steht außerdem ein Recht auf Widerspruch, auf Datenübertragbarkeit und ein Beschwerderecht bei der zuständigen Aufsichtsbehörde zu. Ferner können Sie die Berichtigung, die Löschung und unter bestimmten Umständen die Einschränkung der Verarbeitung Ihrer personenbezogenen Daten verlangen. Details entnehmen Sie unserer Datenschutzerklärung (https://www.centerdevice.de/datenschutz/). Unseren Datenschutzbeauftragten erreichen Sie per E-Mail unter erdm...@sicdata.de. signature.asc Description: Message signed with OpenPGP
