Ugh sorry, should’ve read carefully - the use case seems more related to turning on/off h2 at a individual server level (and not at an origin level) and not a origin configuration which is unrelated.
Sorry for the confusion! > On Sep 5, 2023, at 7:33 PM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.invalid> wrote: > > Yeah, I meant the origin server session sharing configuration is a similar > example to that of configuring an origin’s H2 support that was brought up, > not that it’s related to HostDB. > > >> On Sep 5, 2023, at 7:12 PM, SUSAN HINRICHS <shinr...@ieee.org.invalid> wrote: >> >> I am also ok with removing the hostdb persistence. >> >> I am confused about how this is similar to origin server session sharing. >> >> On Tue, Sep 5, 2023, 6:12 PM Sudheer Vinukonda >> <sudheervinuko...@yahoo.com.invalid> wrote: >> >>>>> I think this is similar to the the current and existing ugliness we >>> have around marking parents down as well (which uses librecords and >>> persistent metrics to store string values). That’s not great either, so a >>> general concept of a persistent key-value store is needed already! I think >>> your use case falls inline with what we need to do for the parent host >>> up/down state as well, so even more reasons why we need that :). >>> +1 >>> Another similar example that comes to mind is the Origin Server Session >>> sharing configurations. >>> Thanks, >>> Sudheer >>> On Tuesday, September 5, 2023 at 03:06:32 PM PDT, Leif Hedstrom < >>> zw...@apache.org> wrote: >>> >>> >>> >>>>>> On Sep 5, 2023, at 3:59 PM, Masakazu Kitajo <mas...@apache.org> wrote: >>>>> >>>>> Sounds reasonable. >>>>> >>>>> Just one question. What would be the best places to store information >>> like >>>> "This origin server supports / prefers / breaks H2" ? We might want to >>>> administratively disable H2-to-Origin for a particular origin server. We >>>> currently don't use HostDB for it but I'm not sure where we can store it >>> if >>>> the persistence is going to be removed. >>> >>> >>> This is a good question, and I think this is similar to the the current >>> and existing ugliness we have around marking parents down as well (which >>> uses librecords and persistent metrics to store string values). That’s not >>> great either, so a general concept of a persistent key-value store is >>> needed already! I think your use case falls inline with what we need to do >>> for the parent host up/down state as well, so even more reasons why we need >>> that :). >>> >>> Cheers, >>> >>> — Leif >>> >>>
