claiming to check if this is still valid

bumping to high because this changes from a warning to a fail to build in the next version of npm

Leaving as open until we move to stretch

To be clear, you mean that cleartables mentioned above wouldn't be deployed?

We figured this out. On Cassandra keyspace creation time the metadata for the layer is saved in Cassandra, so testing anything here needs keyspace deletion and creation. This bedeviled debugging the problem.

This is part of the new style work, which will not be deployed.

This is part of the deploy of new styles to production which we are no longer doing.

This is part of the deploy of new styles to production which we are no longer doing.

This is part of the deploy of new styles to production which we are no longer doing.

This is part of the deploy of new styles to production which we are no longer doing.

This is part of the deploy of new styles to production which we are no longer doing.

This is part of the deploy of new styles to production which we are no longer doing.

This is part of the deploy of new styles to production which we are no longer doing.

This still needs documenting.

We figured this out - it requires specifying the environment on the scap command line

We don't see anything for the maps team to do on this - at the very least, we don't think it needs any resources from us.

Keyspace names aren't so important since we're not going to deploy new stuff.

Fixed.

This was part of the new style stuff, which isn't getting deployed.

This should become easier when we're on stretch

Moot point since we're not planning to deploy it.

@CKoerner_WMF We think the main elements here are community aspects, rather than any technical things

This is still a good idea and wouldn't result in any changes visible to the user.

This is still an issue - we need to figure out what's happening, but it's not an immediate priority. This is independent of needing to upgrade Mapnik

We've deployed to all the wikis we plan to, and don't see the need to do this anymore.

@CKoerner_WMF We're leaving this open as it's assigned to you, but you'll need to figure out some action here.

This is a bug, but we're not clear on if it's a data issue, a style issue, or what the style issue is, so it needs more triage.

Just confirming that this is still a bug.

New style stuff - closing. I might have also done this one.

I feel we've got this ticketed elsewhere and is a new style thing. In any case, as a user-facing change, we wouldn't deploy it.

This would be a user-facing enhancement which we wouldn't deploy, so this is declined due to resource constraints.

No one else is doing this, so we've decided we don't really *need* this. Which of course will immediately cause a rendering problem where we wish we had it ;)

This would require a database schema change, which we wouldn't deploy, so this is declined due to resource constraints.

This isn't very practical, and the new style work has been thrown into question.

Looks like it's either missing piers, or using outdated coastlines. The latter is fixable. I'm not sure if we can do the former because it's a user-facing change and we don't have a product manager for user-facing changes.

The data has likely changed there.

We'd have to decide if we're going to fix issues in our osm bright fork that were fixed in the new style work that isn't being deployed.

@Gehel there are some notes in the docs that imply that not all the maps servers are equal, so we should pick which ones are going to be reimaged. Which ones are the best to do?

@Gehel you tagged this as resolved but T197059 isn't done

Given the new pressure about getting this out on time, I'm not looking to add it. It'd be a good test of adding a feature after roll-out, since it doesn't require a DB reload, nor a breaking schema change.

This is now believed to be fixed.

Done, kind of. We've moved a bunch of them scap.

Any of those solution is likely to require some changes to tilerator / kartotherian, so it is likely to require some development time (and it is unclear if / when we can get access to dev resources for maps).

I verified this works, but it's blocked on the other issues with maps-test2004

Done in documentation.

So, I had this working earlier tonight. I came back after dinner and worked on other parts of the instructions, and now it's now not working. I checked that I'm not crazy, and https://phabricator.wikimedia.org/T194106#4255608 was done from maps-test2004, and my console log shows I tested tilerator too.

Served from the Kartotherian frontend.

Adding descriptions and fields in https://github.com/kartotherian/meddo/pull/16, and I'll rebuild and test with it

After spending the morning trying to wrap my non-maps-expert head around this: it looks like vector_layers is considered a required field in this context (to be formalized), the vector_layers field is generated by the source's consumer (T160025), and resolving T160025 might take care of this (as suggested at the conclusion of Paul's comment above)?

@mojodna, @Mholloway, and myself were looking at fixing this by adding a tilejson, but I'm not sure that's the right approach.

I worked with @Mholloway and @mojodna, author of tilelive-tmsource, at debugging the errors.

T195476: Unable to create source "v3"self._closeAsync is not a function error goes away when Cassandra is running. Instead we get a TypeError: Cannot read property 'length' of undefined message which we're debugging

When Cassandra is running, this error goes away. It doesn't change the need to fix it, and a more meaningful error message would also be a good idea.