[PDB Data Ownership-TF] conditions for being listed in a facility

[Arnold Nipper]

On 09.01.2020 18:00, Chris Caputo wrote:
> On Thu, 9 Jan 2020, Arnold Nipper wrote:
>> On 09.01.2020 16:45, Chris Caputo wrote:
>>> On 07.01.2020 22:58, Chris Caputo wrote:
>>>> - ixlan: Join of ix and netixlan, listing networks at IXP
>>>>   - Ex: https://www.peeringdb.com/api/ixlan/13
>>>
>>> On Wed, 8 Jan 2020, Arnold Nipper wrote:
>>>> Actually, grandparent as the parent of ixpfx is ixlan. Let's see what PC
>>>> comes up, once we remove ixlan.
>>>
>>> I noticed in the upcoming release notes:
>>>
>>>   - * Important note - as part of this release we'll begin dropping 
>>>       support for IX LANs. No impact is expected in this release but the 
>>>       Admin Committee may be reaching out to various IX owners to remodel 
>>>       their IX objects.  Details of this change are in github:  
>>>       https://github.com/peeringdb/peeringdb/issues/21
>>>
>>> I compared production:
>>>
>>>   https://www.peeringdb.com/api/ixlan/13
>>>
>>> and beta (since it has the above change in place now):
>>>
>>>   https://beta.peeringdb.com/api/ixlan/13
>>>
>>> and the results are very similar.
>>>
>>
>> Actually the results should be identical.
> 
> Mostly.  There's a new field known as "info_never_via_route_servers" in 
> the results, and phone numbers have been canonicalized.
> 

The ixlan object has none of these fields. Hence output is identical.

>> However, up to now and ix may
>> have unlimited numbers of ixlans. That will change with the next release
>> where each ix exactly has one ixlan. Even with exactly the same id (i.e.
>> ix_id == ixlan_id). That's the reason we will be able to drop ixlan in
>> V3 completely.
>>
>>> Thus it appears the REST API "ixlan" result is very different than the 
>>> database table "ixlan".  Just something to keep in mind as we discuss 
>>> things.
>>>
>>
>> Is the database table layout public somewhere?
> 
> A version of it is visible for those that "peeringdb sync" with the 
> database.  Ie.:
> 
> $ sqlite3 peeringdb.sqlite3
> sqlite> .schema
> [...]
> CREATE TABLE IF NOT EXISTS "peeringdb_ixlan" ("id" integer NOT NULL 
> PRIMARY KEY AUTOINCREMENT, "status" varchar(255) NOT NULL, "created" 
> datetime NOT NULL, "updated" datetime NOT
>  NULL, "version" integer NOT NULL, "name" varchar(255) NOT NULL, "descr" 
> text NOT NULL, "mtu" integer unsigned NULL CHECK ("mtu" >= 0), "vlan" 
> integer unsigned NULL CHECK ("vlan"
>  >= 0), "dot1q_support" bool NOT NULL, "rs_asn" integer unsigned NULL 
> CHECK ("rs_asn" >= 0), "arp_sponge" varchar(17) NULL UNIQUE, "ix_id" 
> integer NOT NULL REFERENCES "peeringdb_
> ix" ("id") DEFERRABLE INITIALLY DEFERRED);
> [...]
> 
>> And is it relevant? We are always only talking about API objects so far.
> 
> I was confused by you saying - "Let's see what PC comes up, once we remove 
> ixlan.".  I now understand you meant in the db schema and not the REST 
> API.
> 

I meant in the API. We will drop ixlan in V3. I.e. there will be no
ixlan object any more. This is my understanding.


Arnold
-- 
Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200109/f6d5998b/attachment-0001.sig>