#solum

oslo messaging serializes the context

of this single call a solum dev can make and then behind the scenes we can send something to oslo messaging or we can log it or we can write it to a DB, whatever

it should grow

it shouldn't grow

contextual info could be attached to messages before they get put onto oslo messaging

kgriffs, I mean oslo rpc uses the context for auth

that being said, why are we sending events through oslo messaging? I guess it's the "event" word we've been using

and sends that to the other end

asalkeld: oic

well, that is another use for sure

kgriffs: The storage, method of getting it to the user, whether it is a log or notification is all details I think… my concern is how do we tag the information in the control plane to enable filtering on the back end?

that may be the disconnect - i was purely thinking of the context in terms of metadata that is along for the ride

it seems we are mixing two things here logging context and auth

not convinced they are the same

Again, just ignore my code for a moment, what is the proper way to solve this?

heh

just don't have it

be agile

No log/notification to solum users?

add code when you need it

Georgy Okrokvertskhov proposed a change to stackforge/solum: Add trusts to Solum https://review.openstack.org/66738

I mean the logging context

so we start logging stuff

then: ooo we should log this all the time

then we have a better idea on how to solve the problem

now it's pie in the sky stuff

Does everyone feel that way? I'll happily drop this topic and wash my hands. :)

what is the proposal

I did not exactly follow

paulmo I hope everyone doesn't, it's much more fun when there is disagreement

:)

I think Angus is suggesting that we push off any concern about logging to users until later when it becomes more of a pain point (is that the right paraphrase)?

(control plane data that is)

asalkeld: is that is what you meant, I would have to disagree

I don't see a reason to blindly copy RequestContext from Nova. We don't use oslo.messging now so Serialization is not a case.

no, I mean add code infrastructure when you need it

Perhaps you could articulate your stance a bit more?

sorry fingers are a bit painful and slow

thats why I prefer voice calls :-)

I am just saying add generic code when you need it

if there are a bunch of you guys that want to try something else and want to burn time on it, I won't stand in the way any more

for me, it would slow development down

I think we are all trying to do the right thing… unfortunately you are the main source of the "OpenStack way" for me so please don't take this as ganging up or anything… just trying to understand.

and makes moving between projects a bit of a pain

asalkeld: well, it comes down to what features we want, wen

s/wen/when

asalkeld: I am not sure that it will slow doen the development. Better design now faster development later.

logging is basic to get right in the beginning

if we want the feature to give app devs a view into some of these checkpoints/events/reports/whatever then we need to do this

if we want to wait, then we don't need to do this now, but that is a roadmap think IMHO

otherwise we will be promosing technical debt

There are patches that require some kind of context

roshanagr1: could be; it would be a pain to have to go back and redo everywhere we log, but not intractible

openstack is moving to this feature via ceilometer

My goal is to make sure we make this decision with open eyes (whichever way it goes) and with an understanding of technical debt if any we may incur.

Some of them related to data model

asalkeld: ceilometer is going to archive a stream of events?

that are generic?

kgriffs, yes

ah, ok

I think you guys (esp. rackers) need to talk to sandy walsh

gokrokve_: In Solum?

well, we can leverage that.

kgriffs: agree

I did speak with Sandy before

but we still need to decide up front on our interface

paulmo: Yes

paulmo, and what did he suggest

I put some notes here: https://etherpad.openstack.org/p/solum-scratch

paulmo: My patches for Keystone info require something to fill with auth data

Am I thinking about this totally different from you guys?

I'm trying to find my notes but we didn't believe that what he was working on would be very valuable for us… I don't remember the details right now.

I was thinking that we log to syslog and rsyslog pushes it out to whereever

(kind of like the meniscus model would have been)

ah

well, it is just a matter of at which point you split the streams

One way is to structure the log data and there is no need to split the streams.

Another would be to place the user logs in one location and operator logs in another.

I wrote up a bp for heat once

paulmo: well, you will at some point need to split streams and archive them differently

you will have different retention periods, etc.

and you may want to do some pre-processing to get them in a form closer to the way the target user will consume it

Yep. I don't think we have any problems around doing that part though.

The issue is marking the data as to what type it is and how to treat it to start with (in my mind).

paulmo: yes

interface-oriented design

we can work out what happens under the covers in an iterative fashion

There may be better/other ways… love to hear them :)

agile, YAGNI, etc.

That's why I've been bugging angus so much about this… he knows a lot about OpenStack

(sorry angus!)

so, we need to see if we have rough consensus on defining a single "report" interface that let's us categorize things

I think that sounds like a good way to put it kgriffs

and we can work out how to make use of that categorization and stuff in future iterations

one option is to use marconi to send the user messages to

Exactly! That is just details...

asalkeld: Now you are just trying to get kgriffs brownie-points haha

(doesn't have to be "report", i am just using that to help clear up confusion around nomenclature)

asalkeld: :)

yes, well

funny you mention that

did you read that link I posted

the ceilometer guys were considering using Marconi to surface events to end-user

since oslo messaging is more of an internal bus

I didn't get a chance yet… text is flying here heh

I am going to quit on that happy note :-)

read the last bit of: https://blueprints.launchpad.net/heat/+spec/use...

bye , have a good evening (and good morning to Angus)

asalkeld: just starting skimming it - interesting stuff

see you roshanagr1

marconi is useful for "i want to subscribe and be notified when things go bloop"

but you also want to log in a day later and look for a sequence of things that happened after the fact

anyway, getting a bit off onto a tangent here...

Apologies if I'm being dense but I'm not sure why we keep circling back to the method of exposing logs/notifications or how we store them… isn't the real issue how to tag them in the first place?

(the rest is "easy" right?)

also this *could* be like the request_id and all services send to the users queue

paulmo: +1

I don't care if the body of that function is "pass" for the first iteration

Marconi, ceilometer, carrier pigeon… I don't care. :)

just so contributors can start getting in the habit of using it

Yeah, tagging the information while developing so we don't forget what is what…

that's my $0.02, anyway

think composition, not extension

we have this reporter thingy

Now we can go low tech and require specially crafted comments to indicate the confidentiality of data in the code… that works too.

well I'd suggest the secrurity context without the public part

and it composes oslo logging, oslo messaging, anything you like underneath

Don't even worry about security context, start fresh, how should we do this.

context is just a possible means of supporting this other stuff

well you could use the users role to match up with the class of info

I think the real question is do we want this reporting interface thingy

asalkeld: that is a good point - it gives you more metadata to draw on

if we had a log formatter for operater and user

we could just use the log api

so based on the role the formatter adds the info or not