Keep `general` state from becoming stale

[Caleb-Ellis]

Relevant PR comments: https://github.com/canonical-web-and-design/maas-ui/pull/133#pullrequestreview-278872985

At the moment, general data is only fetchable and in many cases its in some way derived from config state. We need a way to re-fetch general state whenever config is synced (UPDATE_CONFIG_NOTIFY).

[squidsoup]

@Caleb-Ellis can you provide an example of where this is an issue in the app please?

[Caleb-Ellis]

@squidsoup It's not currently a huge issue, and I imagine it's only going to affect MAASes with more than one person using it at a time. Basically there are a few fields in state.general that are derived from elsewhere in state, however it itself isn't updated when any of those other state objects are updated.

I became aware of it in the above PR where you can update the default OS/release for deploying machines. The list of OSes and releases you can select are fetched from state.general but when you save the form what you're actually saving is state.config. And since state.general isn't refetched when state.config is saved you can have a discrepancy between values.

e.g. if you changed the default OS/Release from Bionic to Xenial, you would have in state:

state: {
  general: {
    osInfo: {
      default_osystem: "ubuntu",
      default_distro_series: "bionic"
      ...
    }
    ...
  },
  config: {
    items: [
      {
        name: "default_osystem",
        value: "ubuntu"
      },
      {
        name: "default_distro_series",
        value: "xenial"
      },
      ...
    ]
    ...
  }
  ...
}

...until you explicitly fetch state.general.osInfo again, by refreshing or navigating to a page that does it or whatever. So yeah. not a huge issue but it feels wrong to have things in the state object that aren't true.

[huwshimi]

It looks like we get 'config' sync messages but not 'general' when these values change. We can either implement some kind of mapping between these on our end or request changes to the ws api.

[squidsoup]

Making the change on the WS API sounds potentially less brittle, what would that look like?

On Mon, Nov 11, 2019 at 3:39 PM huwshimi [email protected] wrote:

It looks like we get 'config' sync messages but not 'general' when these values change. We can either implement some kind of mapping between these on our end or request changes to the ws api.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/maas-ui/issues/148?email_source=notifications&email_token=AAA7Z3XUMTWC7KEEKEAQVKTQTHUM3A5CNFSM4IO5254KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDYQTTI#issuecomment-552667597, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA7Z3S623CSBTT7O2YFN4TQTHUM3ANCNFSM4IO5254A .

-- Kit Randel (blr) Canonical - Web Team

[huwshimi]

The change would just be to add the normal sync/update message that other models get when they change.

[huwshimi]

I couldn't find a Launchpad bug for this so I filed one: https://bugs.launchpad.net/maas/+bug/1950106.

[Caleb-Ellis]

Still valid. It's the root cause for a couple of other LP bugs too (that I can't quite remember). Adding a blocked label as essentially this requires a backend fix