This thread has died down a bit, but I don’t think we came to any real consensus, so I going to attempt to get some consensus. I think we have a need for two things: the ability to store serial numbers for a server and the ability to store “notes” for a server. The way I see it there are two ways (maybe more?) we can solve this without getting too crazy:
The first way to solve this would be to use the hwinfo table. The hwinfo table gives users the ability to store key/value pairs (in columns named description and val) and has a foreign key to a server object. We can add some fields to Traffic Portal and the API that store\get serial number and notes keys in the hwinfo table and assign the foreign key to the server object. Obviously using strings and key/value pairs is not the most ideal way to do things, but if we implement the API correctly, we could be reasonably safe in relying on the strings. The real benefit to this solution is that it would not require and changes to the database schema, just a few API and UI changes. For what it’s worth we have created a precedent for doing this with profiles/parameters. The other way we can accomplish this is to add two new columns to the server table and make them available in the UI and API. The first column would be serial_number and would have to be a varchar(n) (varchar(30)?), but we could use a regex constraint to limit it to alphanumeric characters. The second would be “note” and that would probably have to be a text field. I personally prefer the first option myself, but we need to get some consensus. Any thoughts? Other reasonable suggestions? Unfortunately we can’t re-factor the whole database schema just because we want to add a few new fields. Thanks, Dave On Wed, Nov 21, 2018 at 5:28 PM Hank Beatty <hbea...@apache.org> wrote: > I'm +1 on adding a jsonb as well. As far as editing... What about using > the text field that Jan presented at the TC summit? It could be written > in YAML and easily converted to JSON. > > -Hank > > On 11/20/2018 04:29 PM, Steve Malenfant wrote: > > +1 json would help us with Ansible as well to store various variables. > > would be nice to have by cache group, servers, type... maybe not > possible. > > > > On Tue, Nov 20, 2018 at 12:52 PM Rawlin Peters <rawlin.pet...@gmail.com> > > wrote: > > > >> I think I'm mostly +1 on the compromise of adding an arbitrary jsonb > >> column. Then it is up to whatever downstream components might be using > >> the column to make sure it works for their purposes. In the API we > >> could just validate that it's actually valid JSON, and I don't think > >> we'd need any other validation on it. Then it would be up to the > >> operator to come up with their own versioned JSON schema for the jsonb > >> column for their downstream components to use. Editing JSON directly > >> via TP is not ideal, but I'm sure there could be a way to generate a > >> usable input form given a JSON schema. The schema would be > >> version-controlled and placed down with TP via whatever configuration > >> management tool you're using. Then you can easily add whatever > >> arbitrary data you want to add to a server without polluting the DB > >> with multiple columns that aren't actually consumed by TC components. > >> Columns like all the ilo_* ones, rack, mgmt_ip_*, etc. would be a good > >> fit for that I think. Those columns aren't consumed by other TC > >> components directly and are mostly just informational or consumed by > >> things outside of Traffic Control, so maybe they'd be better off as > >> second-class citizens. > >> > >> So basically this: > >> If the new column is consumed by a TC component for the purpose of > >> control flow, it deserves a first-class column in the DB. If the new > >> field is not consumed by TC components, meant to be consumed by non-TC > >> components (e.g. configuration management), or is purely informational > >> for human consumption, it can just be relegated to the jsonb column. > >> > >> What do you all think? > >> > >> - Rawlin > >> > >> On Tue, Nov 20, 2018 at 9:30 AM Gray, Jonathan > >> <jonathan_g...@comcast.com> wrote: > >>> > >>> DS lifecycle tracking was supposed to modeled via DSR Comments. Also, > >> we do have 3 existing comment fields on a DS. They've all been co-opted > >> for other various purposes already. That's why they use different > names in > >> TP than in the database. > >>> > >>> Jonathan G > >>> > >>> > >>> On 11/20/18, 8:54 AM, "Jason Tucker" <jasonwtuc...@gmail.com> wrote: > >>> > >>> Right, we do... but try reading or writing paragraphs of info in > >> them. The > >>> DB fields may support it, but the UI not so much. > >>> > >>> __Jason > >>> > >>> On Tue, Nov 20, 2018 at 9:27 AM Fieck, Brennan < > >> brennan_fi...@comcast.com> > >>> wrote: > >>> > >>> > We have three such fields for Delivery Services, afaik :P > >>> > ________________________________________ > >>> > From: Jason Tucker <jasonwtuc...@gmail.com> > >>> > Sent: Tuesday, November 20, 2018 7:25 AM > >>> > To: dev@trafficcontrol.apache.org > >>> > Subject: Re: [EXTERNAL] Re: Adding a text field in Servers > config > >> of TP > >>> > > >>> > I'm actually a fan of arbitrary text boxes for more than just > >> server > >>> > objects. I've been hoping for something like this in delivery > >> service > >>> > objects as well, as this sort of field can be used to help > document > >>> > unusual/custom/snowflake behavior which may not necessarily be > >> obvious to > >>> > those who come later with the intention of troubleshooting. > Should > >> be used > >>> > for communicating with humans, rather than systems. In lieu of > >> versioning > >>> > of configs, it could be used to keep a change log for the object > >> as well. > >>> > But, again, that's more applicable to DS objects rather than > Server > >>> > objects, I think. > >>> > > >>> > __Jason > >>> > > >>> > On Mon, Nov 19, 2018 at 9:48 PM Gray, Jonathan < > >> jonathan_g...@comcast.com> > >>> > wrote: > >>> > > >>> > > I'm -1 depending on what the intended use case is. > >>> > > > >>> > > Generic text fields should only be useful to human operators. > >> In the > >>> > case > >>> > > where you intend anything to programmatically access that > >> information and > >>> > > it's generally useful, you're better off with specific columns > >> per point > >>> > of > >>> > > data. This is how we ended up with unparsable, yet critical, > >> data in the > >>> > > comment fields of physical location table when we should have > >> added real > >>> > > columns. The example in the issue is delivery services. The > >> description > >>> > > field that I think is being referenced is one of LongDesc, > >> LongDesc_1, or > >>> > > LongDesc_2 in the database. Columns should have one purpose > and > >> one > >>> > > meaning that is clear to a new developer working in the code > and > >>> > > conceptually plausible to anyone else trying to understand how > >> the system > >>> > > works. One compromise, I'm not a huge fan of, would be to > allow > >> for > >>> > > arbitrary structured data via a column of type jsonb instead > of > >> text. > >>> > > That's not a great answer from a usability or db theory > >> perspective, but > >>> > > it's slightly better than regex parsing. > >>> > > > >>> > > Jonathan G > >>> > > > >>> > > > >>> > > > >>> > > On 11/19/18, 3:09 PM, "Dave Neuman" <neu...@apache.org> > wrote: > >>> > > > >>> > > +1, I am fine with it. That table already has a lot of > >> columns, > >>> > > what's one > >>> > > more!? > >>> > > > >>> > > On Mon, Nov 19, 2018 at 2:59 PM Jeremy Mitchell < > >>> > mitchell...@gmail.com > >>> > > > > >>> > > wrote: > >>> > > > >>> > > > Sounds like server "notes" or a server "description". > >> Seems like a > >>> > > fair > >>> > > > ask. I don't see the harm in adding an optional column > to > >> the > >>> > server > >>> > > table > >>> > > > with type=text for this data. > >>> > > > > >>> > > > On Mon, Nov 19, 2018 at 2:16 PM Anuj Tyagi < > >> tyagi...@husky.neu.edu > >>> > > > >>> > > wrote: > >>> > > > > >>> > > > > Hello Traffic Controllers, > >>> > > > > > >>> > > > > I discussed this with a couple of ATC users. We have > >> multiple > >>> > > > > Description/text fields in Delivery Service > >> configuration of TP. > >>> > > > Similarly, > >>> > > > > We should also have one text field in servers > >> configuration. My > >>> > > use case > >>> > > > is > >>> > > > > to keep the service/serial id of the servers and any > >> specific > >>> > info > >>> > > for a > >>> > > > > server for which no field is available. > >>> > > > > > >>> > > > > I have created an issue on GitHub for it earlier: > >>> > > > > https://github.com/apache/trafficcontrol/issues/2764 > >>> > > > > <https://github.com/apache/trafficcontrol/issues/2764 > > > >>> > > > > > >>> > > > > It's not a major change so shouldn't be a problem. If > >> everyone > >>> > > agrees, > >>> > > > I'd > >>> > > > > be interested to add that. > >>> > > > > > >>> > > > > Thank you > >>> > > > > Anuj Tyagi > >>> > > > > > >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > >>> > >> > > >
