April 2017 - Pdb-tech

Sync issue - fac_id 3 missing?
by Ruairi Carroll 14 Apr '17

14 Apr '17

Hey, I'm trying to run a sync of the DB locally, and after some initial struggles, I'm finally able to start to sync the data. However, my sync bombs out when when trying to sync fac_id 3, as per my logs below (Full log is on PasteBin here <https://pastebin.com/r55K4r8Y>). {'fac': *[u'facility instance with id 3 does not exist.']*} : errors: {'fac': [u'facility instance with id 3 does not exist.']} fac: Missing Object, dict: {'_validators': [], 'auto_created': False, 'serialize': True, '_unique': False, 'unique_for_year': None, 'blank': False, 'help_text': u'', 'null': False, 'to_fields': ['id'], 'db_tablespace': '', 'db_index': True, 'is_relation': True, 'unique_for_month': None, 'unique_for_date': None, 'primary_key': False, 'concrete': True, 'swappable': True, 'max_length': None, 'rel': <ManyToOneRel: django_peeringdb.networkfacility>, 'from_fields': [u'self'], 'verbose_name': u'fac', '_choices': [], 'creation_counter': 129, 'validators': [], 'editable': True, 'related_model': <class 'django_peeringdb.models.concrete.Facility'>, 'error_messages': {u'unique': <django.utils.functional.__proxy__ object at 0x80a4d6a90>, u'invalid': <django.utils.functional.__proxy__ object at 0x80a55c550>, u'invalid_choice': <django.utils.functional.__proxy__ object at 0x809ac0990>, u'blank': <django.utils.functional.__proxy__ object at 0x80a4d6a50>, u'null': <django.utils.functional.__proxy__ object at 0x80a4d6a10>, u'unique_for_date': <django.utils.functional.__proxy__ object at 0x80a4d6ad0>}, '_related_fields': [(<django.db.models.fields.related.ForeignKey: fac>, <django.db.models.fields.AutoField: id>)], '_error_messages': None, 'db_constraint': True, '_verbose_name': None, 'name': 'fac', 'db_column': None, 'default': 0, 'attname': u'fac_id', 'column': u'fac_id', 'model': <class 'django_peeringdb.models.concrete.NetworkFacility'>, 'opts': <Options for NetworkFacility>} *fac.3 not found locally, trying to fetch object... * Starting new HTTPS connection (1): www.peeringdb.com *"GET /api/fac/3?depth=0 HTTP/1.1" 404 None* When I look deeper here, I see that this is the core of the issue: Starting new HTTPS connection (1): www.peeringdb.com "*GET /api/netfac?since=1484585605&limit=0* HTTP/1.1" 200 None netfac last update 1484585605 1808 changed data to be processed 1808 Which, if we look at the data this returns, contains "fac_id": 3. So, suggestions on how to proceed here? /Ruairi

2 2

ixgen: api library in go and peering generator
by Jörg Kost 09 Apr '17

09 Apr '17

Hello pals, happy to release ixgen, that is replacing my old tool chains. From the readme: Ixgen is yet-another open-source, multi-platform generator for peering configurations on IXs incorporating the global peeringdb api, but also is able to spin up its own "compatible" server for faster results. Ixgen is configured by an INI- or JSON-style format, producing custom template-driven or fixed JSON-configurations, that can be printed on the terminal, to a file or served by HTTP. Direct access to routers REST-APIs and ssh/scp-upload is planned. Ixgen is shipped with cross-compiled executables for Darwin, Linux and Windows. Fetch the first release: https://github.com/ipcjk/ixgen/releases Check out the README: https://github.com/ipcjk/ixgen/blob/master/Readme.md Happy hacking, Jörg

1 0

django_peeringdb sync issues with SYNC_STRIP_TZ == True
by Milton Ngan 07 Apr '17

07 Apr '17

I just opened an issue on GitHub about this already, but I'll summarize the issue. When using the 'peeringdb sync' command from the Python peeringdb module, the 'since' Unix timestamp is calculated incorrectly. The dates are properly stored in the database in UTC, but the Unix timestamp is calculated using the local timezone via mtkime. So us poor people West of UTC will get a Unix timestamp which is ahead of where it should be. So any records created/updated in this gap will be missed. Being in UTC-7/-8 that gap is pretty big and we hit this all time now. I didn't seem to see it as much earlier, but this could be due to increased usage of PeeringDB over the past year or two. This issue is probably not affecting anyone East of UTC because their timestamps will be behind where it ought to be which is fine because you get duplicate updates which just get merged.

2 2