Page MenuHomePhabricator

[S] Ensure that tunnel rows are updated with the correct data during actor data import and update
Closed, ResolvedPublic

Description

Tunnel operators are known in advance, so we are populating the tunnels table in advance, for performance and complexity reasons. (Done in T344499.)

However, the table structure is:

+-----------+---------------------+------+-----+---------+----------------+
| Field     | Type                | Null | Key | Default | Extra          |
+-----------+---------------------+------+-----+---------+----------------+
| pkid      | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| operator  | varbinary(256)      | YES  | UNI | NULL    |                |
| type      | varbinary(5)        | YES  |     | NULL    |                |
| anonymous | tinyint(1)          | YES  |     | NULL    |                |
+-----------+---------------------+------+-----+---------+----------------+

...with the type and anonymous values for each operator not known in advance.

We should ensure that the tunnels table is updated with the correct values in these fields as data is imported/updated. (For the initial populate, they are given the default null values.)

Event Timeline

@STran I'm not making this a deployment blocker, because I don't believe we are using these values to begin with. Is that correct?

Tchanders renamed this task from Ensure that tunnel rows are updated with the correct data during actor data import and update to [S] Ensure that tunnel rows are updated with the correct data during actor data import and update.Nov 1 2023, 6:53 PM

@STran I'm not making this a deployment blocker, because I don't believe we are using these values to begin with. Is that correct?

I believe type is relevant because in the /vpns and /vpn/:label endpoints we only show tunnels of type=VPN.

@STran @Tchanders We don't appear to be updating the tunnels if their type changes. This could affect what is returned by the /vpn endpoints. Is this OK?

This is expected behavior for now. I think we'll have a discussion later on about historical data/updating IP information.

This is expected behavior for now. I think we'll have a discussion later on about historical data/updating IP information.

OK, thanks. I will move this task along.

@STran does this task need moving to the next sprint or can this be marked as resolved?