#solum

making structure is not always easy, where ever you send it

I'm not against it, I just want a solution everyone can agree to at this point. heh

hmmm

paulmo, I don't mind a wrapper

And what form would that wrapper take?

(not SecurityContext obviously)

guys, sorry, but I gotta run

well it does matter if you want to support marconi/notifications

mmm

unless you write a log driver

so, sounds like we now have two options on the table

Well darn, was hoping we could finish this today...

paulmo, just the begging

Begging will help? :)

1. go through the logging interface as-is and try to do something clever with a logging formatter or something

if I were you I'd have some other bit of work to do in parallel

kgriffs: 1. = the extra->private example here: https://wiki.openstack.org/wiki/Solum/Logging

so you don't get stuck/frustrated

2. write a new interface that sits on top of logging, potentially other things depending at which point you want to start splitting the streams

2. could equal the bottom of https://wiki.openstack.org/wiki/Solum/Logging

(but I'm not tied to that)

paulmo, can't you take the context you had, and not call it a RequestContext

so LoggingContext?

Heh, I can change a name no problem...

but fills a different role

used for logging, not auth

so, I think part of the confusion we have going on is in the naming of SecurityContext()

yeah

i was thinking of context, like the context that is global to a given request or something

Forget SecurityContext, forget my code, it does not matter to this conversation.

It is just an exapmle that we can throw away.

what it does is categorize data

this SecurityContext is more like... what i was thinking when I talked about "categories" and "metadata"

so, I mean, it isn't bad

I was just confused

(by the nomenclature)

just call it by what it does

If I change the name, everyone is happy with it? *boggle*

Is that the real issue?

paulmo: so the idea is, you construct this Thing that contains everything our log formatter needs in order to categorize, ship to different "sinks", etc.?

paulmo, but not used for auth, just loggin

2 seperate things

I think I get why you called it "Context"

it's sort of the local context for this message

...or something. anyway, naming is less important

… because everyone told me that I had to use Oslo Context and that was the name of the class.

huh

I can change the name to anything… it does not matter

paulmo, we all learning what you are doing and how it fits in

so...

(RequestContext, so I took the Context part and changed the first name…. but anyways)

I feel like we have two Things

RequestContext - has your tenant id, user, app id, whatever

and then you have Category/Meta/Whatever - that is just specific to this thing that just happened

state/some backtrace info

… which would also likely have all of the same data that RequestContext would have and then more

so, each time I log, I want to add more stuff that says "this may be useful for end-users" or "only devops will care about this"

and I can also add a dict or something that contains structured data I can pull out and use for formatting as HTML, loglines, whatever later

… or mark the data for something to log appropriately. Just a matter of when/where.

Yep

paulmo we only add to the loggingCategory what isn't in the RequestContext

paulmo: yeah, I think there's just been confusion from lumping context in with the other kinds of data

Well that is what I was told to do… so I'm confused.

yes, context is in a sense a subset of all the data you want to send each time you log

one option

LOG.error('blah', context=CTX, meta={...})

+1

Yep, longer log cals

calls

(which is viable, don't get me wrong)

personally, I still like using thread-local storage so you don't even have to pass in context=BLAH each time

but, that's just my opinion

guys, I really gotta run

gonna be late

Local storage got me -2ed

later

See ya!

I should go too I guess...

paulmo you feel you have more to work on?

paulmo: too bad. I think that is a problem with OpenStack leaders

Nope

not being as open-minded or welcoming of new ideas, but whatever

that is a different topic

(not all leaders are that way, to be sure)

I'll worry about it tomorrow I guess...

paulmo: let's talk tomorrow

or perhaps just stop beating myself up with this topic and let someone else handle it.

kgriffs: Ok!

I think we have removed a lot of confusion, which will help a lot

(believe it or not)

ttfn

yeah

the chat has been useful for me

Murali Allada proposed a change to stackforge/solum: WIP: Assembly DB schema and object model https://review.openstack.org/69498

Murali Allada proposed a change to stackforge/solum: WIP: Assembly DB schema and object model https://review.openstack.org/69498

Murali Allada proposed a change to stackforge/solum: Assembly DB schema and object model https://review.openstack.org/69498

Murali Allada proposed a change to stackforge/solum: Assembly DB schema and object model https://review.openstack.org/69498

Angus Salkeld proposed a change to stackforge/solum: Add the alembic migration framework https://review.openstack.org/68101

Angus Salkeld proposed a change to stackforge/solum: Add an initial schema https://review.openstack.org/68328

Angus Salkeld proposed a change to stackforge/solum: Connect the plan API to the DB https://review.openstack.org/69855

Angus Salkeld proposed a change to stackforge/solum: Add API resources for Plans and Plan https://review.openstack.org/62549

Angus Salkeld proposed a change to stackforge/solum: Add the plan objects and schema https://review.openstack.org/69308