Hello, welcome to Cloud Native Live, where we dive into the code behind Cloud Native. I'm your host today. My name is Whitney Lee, and I'm a CNTF Ambassador and a Developer Advocate at VMware. Every week, we bring new presenters to showcase how to work with Cloud Native technologies. We'll build things, we'll break things, and we'll answer your questions. Today, we have Adnan Rahic here with us to talk about the power of traces, why open telemetry embraced trace-based testing. Now, this is an official live stream of the CNTF, and as such, it's subject to the CNTF Code of Conduct. Please don't add anything to the chat, that would be in violation of that Code of Conduct. Basically, be respectful of all of your participants, be respectful of Adnan and respectful of me too, please. Friends who are joining us live, please say hello in the chat. Tell us where you're tuning in from. It's so cool that this is a global community, and then as always, if you have questions during the presentation, please post them in chat. With that, I'll hand it over to Adnan to kick off today's presentation. Thanks for being here, Adnan. Thank you for having me. Hello, everyone. Hello, community. Super thrilled to be here. My first time joining the Cloud Native live. Let's just get started. Just a bit about myself. I do developer relations. I've been doing it for roughly five, six years now, so I should know what I'm doing. I hope, right? Isn't that always what you want to hear at the beginning of a presentation? You're really building trust right now. Yeah, what can you do, what can you do? Yeah, in my spare time, when I'm not doing developer relations, I like lifting heavy things off the floor and getting punched in the face, which basically translates to weightlifting and boxing. You are building trust in that we believe you're honest. That's the kind of trust you're building. Isn't that the way it should be? It's just cut through the nonsense and just go for the important stuff, right? Yeah, getting punched in the face. Wonderful, wonderful. Yeah, let's do just quickly jump into the rough agenda of today. All right. Yeah, let me pull up the, here we go. So obviously, what we're going to be talking about today is going to be really kind of just based around observability, but not just specifically observability. It's going to be based around open telemetry and specifically I want to kind of demystify the whole thing. So it's quite hard to understand what it exactly is and also how you can contribute to helping the community, but also helping the open telemetry demo, which is also a big, big part of the community. So we're going to basically be going through all of those things and also a key part in contributing. It's not basically not breaking stuff and that's what we're going to be talking about mostly. We're going to talk about how to reliably write traces, how to reliably test them, how to reliably test your system as well. So because when you're using any cloud native tool or any cloud native app and you're building in cloud native, there's a lot of microservices, a lot of things that are interconnected where it's very hard to understand what's happening. It's very hard to test it. Integration testing is a pain. And so yeah, so that's basically what we're going to be talking about in the next hour or so. And I really want to start by starting from the bare bones basics. So let's say what is observability? It's like a buzzword. We know about monitoring, we know about metrics, we know about logging, but what does this specifically mean? The easiest way I would say to explain it is that it's the way you observe your system. So it's the way you figure out all of the unknown unknowns that are going on in your system to help you troubleshoot any problems that are in your system. Now, the way you do that is specifically, it's the way of emitting signals and those signals are the holy trinity or whatever we call them, traces, metrics and logs. Three pillars of observability are traces, metrics and logs. Now specifically for open telemetry, it does support all of those, but the most important thing and what we will be talking about during this live stream will be distributed tracing. So it's the distributed tracing part that we really want to understand. Now, the basics of distributed tracing, it's not really easy to wrap your head around because there are a lot of things like, oh, what is this context thing? And nobody really knows. So they just kind of wing it. And things like that, I want to help demystify. The easiest way of thinking about it is everybody knows what logs are. Everybody knows about logging. Everybody has done logging. If you haven't, you probably should try on a side note. Anyway, logs are quite literally, this is a log line.  It spits out the log and you know what's basically happening in your system. Tracing is very similar conceptually where instead of logs, as in logs, you're generating something called a span. And as it says here, a span is a unit of work or operation. But let's key in this keyword here, distributed. Distributed tracing wouldn't be distributed if you only had spans. The thing with spans is that they connect into a distributed trace. So here's a perfect example. This off N span is just part of this entire distributed trace. And this entire set of spans that are connected to each other is a distributed trace or a trace per se. And this is what the actual power of tracing gives you. You don't have just individual log lines and then you have to figure out what it does and how it connects in between one part of your system and the other part of your system. You're basically getting a waterfall diagram, so to say, off the whole interaction one request goes through within your system and that's the power of it. And yeah, so let's just kind of take a step back. And I want to show you really quickly. Yeager is a tool for distributed tracing and then just to say, whatever it doesn't really matter, which one, what I want to show you here is that this is what you would see in your system if you have something like Yeager installed. And Yeager is basically a tracing backend. It's like a data store for your traces. So all of the traces you generate in your system you put in Yeager and then you can get a really nice waterfall of everything that's happening within your system. So this is a get request. You can see what's happening. You can just open up every single part of the codes that gets touched with this particular transaction and you can see exactly what's happening. So we have a couple of questions from one person asking more than one question. But I guess they're wondering, how do you manage this for Python logging? And then at which point is it best to use this framework instead of a sidecar in a Kubernetes environment? So I guess this is touching on like, are these things language specific and how exactly are our traces collected? That is a lovely question. And the way I want to answer that is to just pull up the OpenTelemetry website. So OpenTelemetry handles all of this. OpenTelemetry is a set of SDKs. It's a set of tools and libraries that lets you generate telemetry in the most efficient way possible. So you can generally slot this in instead of any logging framework or log library or whatever you're using and instead use OpenTelemetry instead. So as you can see here, it's literally a collection of APIs, SDKs and tools and that you use it to instrument or code. So you're basically the same way you would do like Python, library.log, debug or whatever you want to use there that you use OpenTelemetry SDKs instead. Now the best way of explaining that is popping into the official documentation. Obviously in saying, what is OpenTelemetry? So you basically get the observability framework to create, manage your telemetry data, which means that as same thing as you were doing for, let's say your Python logging, you would slot in OpenTelemetry and say, yep, I want to use it for logs. I want to use it for metrics, but most specifically the traces part is the power because with a trace, you can also add in log events to a particular distributed trace. So you can get context to that log. You're not just basically sifting through logs. You can actually see this particular request had a problem and here are all the logs within that distributed trace. And regarding the, yeah, go ahead. What's the benefit of using OpenTelemetry instead of your Python logging framework, for example? Observability, short and sweet. You get an exact map of what is happening in your APIs. So let's say you have an API for a payment. If that, even if you have black box tests for that API, you only really know whether it failed or succeeded because you're looking at the output. If you're set up tracing for that particular API, you can know exactly everything. You can know whether the card is invalid because it's a visa, but you want master card. You can know if it's invalid because of X number of different reasons, which is the power of tracing. You're basically observing exactly what's happening and you can add in even custom spans within your code, the same as you would do with logs, but these custom spans are basically added in to that entire context of that one distributed trace, which represents one API request. And that's basically the most powerful thing that I would say. So it's way more rich in terms of what it collects, but then also it plugs into a lot of different frameworks, not just Python logging, for example, like it can know about your Kubernetes, it can know about other languages. And so it has a standardized way to collect the telemetry data, regardless of where it's collecting the telemetry data from. I want to ask you, Arnaan, we have more questions rolling in. Do you want to go with the questions for a while or do you want to tell your story and then maybe we'll break for questions in a bit? Yeah, let's do a couple of more questions before we jump in because some of the things I want to move on to right now is exactly what you were saying about using different languages and what the SDKs actually entail or what they actually have as a possibility. And I would say that that would be something we can jump into after a few more questions. Okay, sounds great. So Said has a question. Can you add traces to BlackBox application's legacy where you don't have access to the code base?  It's quite literally where the only access, actually the only knowledge you have about the system is what you put into it and what it puts or spits back out to you. So basically the request response. You only know what you have to give it and what you should get back. You don't have any clue what's happening in the inner workings of that system. Excellent, thank you. And then answer the, how can you add traces to BlackBox application? So one thing that I think you could do there is depending on where your application is running, let's say you have it running in Kubernetes. OpenTelemetry does, that even says here on the screen. So OpenTelemetry gives you an operator for Kubernetes. So you would quite literally set up the operator, run it as a Kubernetes CRD inside of her cluster. And then you would specify on the pods you want, you can specify the auto instrumentation libraries, which is basically a super magical way of getting tracing enabled in your Kubernetes environment without writing any code. So this basically no code changes to your code base. This is just configuration changes and something that your DevOps team would do or platform team or whatever you call it in your organization. But apart from this operator for Kubernetes, everything else that I've tried, you basically need to do some sort of configuration changes that are code based. And that's something I'm going to be showing in a moment as well. We still get auto instrumentation, but there are some slight code changes you need to do to actually load those libraries to start generating those automatic traces, so to say. Excellent. So another question, if you compare tracing instead of logging, how intrusive does tracing become in terms of resource consumption? Does it make sense to only do tracing and ditch logging? That's a good question. I would say that back in the day, you would start with logging and then you would kind of add in some metrics and then you would kind of add in some APM and then that would kind of all just mesh together in some weird way. If you're doing it from scratch now, I would suggest starting from tracing and going from there. Using distributed traces can in some sense be equated with the term APM or application performance monitoring, which is something that I'm not sure who coined it, but it's quite common with certain tools like Datadog, Nurellic, all of the big vendors in the space. So you could say that if you're used to having a sort of APM monitoring system, using distributed tracing goes with that logic, so to say. So I would say try doing instrumentation with OpenTelemetry first because that enables you to both generate metrics with OpenTelemetry and add your logs with OpenTelemetry as well. So you're getting a non-vendor login way of generating the telemetry where you can basically choose whatever backend you want. If you want to send it to Datadog, if you want to send it to Yeager, if you want to use Grafana, I mean, it doesn't really matter because the telemetry is standardized and you're generating it in a way that will be accepted into any trace data store that you choose. Amazing. And now we're level, we're back to ground zero with the questions. Wonderful. And with that, I think it's gonna be fine. I mean, I did mention the OpenTelemetry operator for Kubernetes, but generally the thing I also want to mention here is that all of the libraries that the OpenTelemetry project offers, it's, I mean, the languages you can choose from are immense. I mean, everything from C++, JavaScript, Python, I mean, basically any languages that you're using, you'll have the SDK available to generate traces from it.  I mean, I am, but yeah, let's not go into that. I wanted to actually talk about the instrumentation part. So what's the easiest way of getting started with a language such as JavaScript? And here's, let's actually pop into the automatic instrumentation and I'll just walk you through here. You install some libraries, cool. You're Node.js, that's NPM install. It's perfectly, perfectly reasonable. We all do that all the time.  Like, is this real? Is this, you know, is this a hoax? Is it really possible to do it this way?  It looks too good to be true. And this is the part that I want to talk a bit about the way you need to actually configure some code that it's to actually get it to work. And I think the best way of doing that, let me just pull in something and show you. So let's go ahead and open some code. And I specifically want to show you this on the left-hand side, you can see that it's a service called payment service and we have an open, it's obviously JavaScript, it's Node.js and we have a file called open telemetry.js. Now, I have very conveniently just commented this little section out and added that in. So with this, so it's a open telemetry, requires some SDK, SDK node, getting some auto instrumentation, I'm getting some exporters, yada, yada, whatever. And I'm setting my auto instrumentation and I'm setting where I'm going to export my traces. Now, this 30 odd lines of code is going to auto instrument my Node.js app. Cool, that's it. Mic drop, yeah. And you're obviously looking at me, this dude is like, he's freaking, he's lying. There's no way, no way it's gonna be. But yeah, let me backtrack a bit. I've commented this out, there's no open telemetry instrumentation in my payment service, cool. Let me go ahead and trigger an API test against this payment service and just show you what happens. I have very conveniently set that up as well. So let's do, I think it is this one, and it is this one. So I'm just going to trigger an exploratory, what's it called? I'll just mess that up. I wonder if I can turn your name off, your name is blocking the... Oh, okay, let me zoom in a bit more. Okay, your command. So like that, we have the demo running, we have this guy. Ah, okay, it's a, I'm just misconfiguring the test itself, so let me pull up the test and change it real quick, and it's going to work perfectly fine. Let's do like that. You see, this is what happens when you're not prepared for your demo, isn't that terrible? We did promise up top that we would break things. So I'm glad you're... Yeah, also the last slide's the better, right? Yes, yes, 100. Actually, we can probably also just move this up a bit. There we go, great. That's a bit prettier. So what's this is going to do here is that I'm basically just running an API test. Then whilst that's running, let's just pull up the actual test itself so you can see it running. Let's just last run, and then we put that one in. Zoom in a bit on that. So obviously this test here, just, I think this is going to be fine. Obviously this API test here is going to say, yeah, I'm looking for the traces, whatnot. This is, by the way, this is trace test. This is the testing harness that the OpenTelemetry demo is using, more on that in a second. This is going to start running and it's going to fail after three minutes, which is the timeout. It's going to fail because I have no tracing in my payment service. So it's just gonna say, I triggered it, nothing really happened, I don't really know what to do. Well, let's see if my hypothesis is true. So let's move back to our OpenTelemetry file. Let's go ahead and comment in our supposedly working auto instrumentation. Save that file up. Go ahead and rebuild our payment service. So we need to, just obviously need to stop it. We need to rebuild it and restart it once again. This is going to take three seconds. So if we have any questions that- We have a comment too late. No, we can go ahead. What's nice in logging versus OpenTelemetry is that OpenTelemetry defines semantic conventions about attributes, which would be there for a given scope like HTTP. So that's better than full text indexing some logs. I love that. I love that. This is a perfect segue. So just for reference, I've restarted this payment service with the changes. I'm going to run my test again. So let's do just the same API test, pop back into the UI and let's reopen the, obviously last run. Let's reopen this little buddy here. And now if we go to the trace tab, we're going to see the trace. But also one thing that I'm going to talk about here is the question was about semantic conventions. Beautiful question. That's something that was also thought of in the community because one of the big problems when pushing changes is that you break not just the tests or you break, obviously break the code because the tests are passing, but they shouldn't be passing, but also you're not writing adequate telemetry. So you're basically not adhering to the semantic conventions and the rules that the open telemetry community wants you to adhere to, which is obviously first and foremost, we have our trace now, obviously we have our trace band. So that one jumble of 30 lines of code actually made us get our trace back. So with that magic, let's say through 30 lines of code magic, we can actually see our trace. But even more importantly, we can pull up this analysis of our trace and see, okay. So our trace is 83% good, which basically means, yeah, I have some semantic conventions that have failed. I can jump in and say, okay, so this failed. Let me go in and pull up the documentation on how to fix it, which is an amazing thing that our community member just mentioned, which is I actually have some hand holding. I don't really have to make up my own way of doing this. I had the open telemetry semantic conventions that I could follow.  I can see, okay, so here are the rule details. I need to do this one for my HTTP spans. I need to do this one for my database spans. I need to do this one or these two for my RPC span. So it's the hand holding that you really need to improve your software development life cycle. Like it's not easy setting up tracing and writing traces. It's not easy, right? So that's the point of the whole edition of trace-based testing to the open telemetry demo is to just improve the hand holding. And with that, I think we can pop back here to talking a bit about this magical, I'm going to say auto instrumentation. This code that I'm showing right now is part of, so it's called the payment service. It's part of the open telemetry demo, which is just gonna be blunt. It's an amazing demonstration of what open telemetry can do. It's obviously maintained and run by the open telemetry community. And it gives you an overview of both the power of open telemetry and also guides you on how you should be using open telemetry. And I think the best way of showing that as well is to pop into the documentation here and say, yep, let's actually see what features are in the open telemetry demo. And one of the most important features that I would think I really want to talk about a bit is that it features tons of languages. So it doesn't really matter what your background is.  Every single one of the SDKs are showcased in the demo itself. So you can pop in and actually read code and see what's happening. You don't really have to write, or like, sorry, read any documentation and kind of fumble through. You know exactly what's happening if you pop into the code and look at the code and read the code and understand it that way. And I love that. And with that, I think there are a total of 11 languages and there are 12 services. And you can see here that we have the payment service here that we're going to be looking at as well. And yeah, I just think it's freaking amazing. And yeah, with that, I think. We have a couple of questions. Can we get to those? Yeah, for sure. Let me just open up the architecture here so we can walk through, just have that open. And yeah, let's do some questions. Okay, so we have one that is asking, well, first of all, my question is, what is open tracing? And then Rima's question is, is there a way to maintain the compatibility between open tracing where tracing is governed by XB3 headers and open telemetry, where tracing is governed by transparent headers and a distributed environment at the same time? So the short answer would be that open tracing and open census merged in 2019 into open telemetry. So you should just drop open tracing.  Obviously there's a migration guide as well. So it's not that big of a deal. Obviously people have thought about it. People that are much smarter than me have written the guides and actually figured out a way of doing it. Are those guides part of the open telemetry documentation? I am 99% sure yes, but also the quick Google search can say, my great thing from open tracing to open telemetry. And we can pull up, yeah, obviously they have a dedicated page. It's purple even, yeah, yeah, there you go. So obviously they have backward compatibility to some extent and they have language version support. But I mean, if you're quite new to this, if you have existing open tracing SDKs or instrumentation in your code, you should probably consider dedicating some time and figuring out how to change. Otherwise, if you do not, you should just use open telemetry. Excellent. And we have another question about collecting the telemetry data. Can we do tracing with open telemetry as a init container or a sidecar? So I think the logic of collecting the telemetry is a bit different than what people are used to with, let's say, logs. It's a bit different because you specifically need to write the instrumentation in your code or you use the open telemetry operator in Kubernetes that auto-injects these libraries. So I would say that, it's not a easy question. I would say use the specified guides that the open telemetry documentation provides with you. If you're running Kubernetes, as I obviously see you are, use the open telemetry operator. It's dead simple, like I've tried it. There's even a documentation page I wrote. I can also pull that up. I mean, it's, if I don't have, so it's dead simple.  The only thing that you really need to do is that you need to specify in your services. So the deployment that you want to have the auto-injected library, you need to specify an annotation for that. Now it's, they have four, I believe they only have four right now that are available. So you basically, if you have Python, let's say you use Python, you just say Python, inject Python true, add it to an annotation, and you're basically done. It's, I mean, I keep saying it's magic. It really is magic, hopefully it leads me, right? So, I mean, to actually believe it yourself, try it. I mean, dedicate half an hour of your day, try adding it. I mean, it's a CRD. So if you don't like it, you can just delete it.  So yeah. So I think you just had the right thing. What language is this question is, is the Kubernetes operator available for all the languages supported? So these four languages are the ones that are. Exactly. So we can even pull that up in the, that doesn't really work. We can even pull that up in the documentation here. Let's say we want to go to the telemetry operator, that will be instrumentation operator, and we can pull that up and we can see here, Kubernetes operator, we can also probably link this in the chat as well. So people can check out for themselves. It's quite strange that they don't have a list. Oh, there we go. So they have annotations for injection, Java, Node.js, Python, .NET and Go, but Go has some a bit more complicated setup that they need to figure out. And that is pretty much it. Yeah, I need to update my documentation now because Go didn't have that at Go. Cool. Sweet, sweet. Yeah, with that, I think. Yeah, I think we can move back to the, if there's no more questions. No more questions. I'll show that operator. Oops. I think we can pop back into the demo architecture really quickly and just show you here. So you have 11 languages. You have 12 different services. You have a few different things regarding databases, caches, queues, whatnot. And this is a demo, this is obviously the open telemetry demo and it is a perfect demo of what a production system at a corporation would look like. And saying that the open telemetry demo, I think in the last month had 15 or so different contributors that numerous pull requests. And these people are from all over the world. They're from every imaginable time zone that we have on the globe. And how do you sync with that? How do you make sure when somebody edits this guy that everything else just doesn't die? It's not easy, especially if you're writing instrumentation, if you're setting everything up and then changing that.   I mean, that's a nightmare. And then you merge that and then it's broken and it's merged. It's just not fun at all. So I think that was some of the major pain points that the open telemetry demo had because they had black box tests already set up with Ava and Cypress. And it looked fine, but sometimes tracing broke. Sometimes telemetry was just misconfigured. Sometimes tests passed when they shouldn't pass. And that was basically one of the problems that the community wanted to fix. And that was to just stop that from happening more or less. And that's when the decision to introduce trace-based testing came in. And trace-based testing is exactly what it sounds like. It's using distributed traces for your end-to-end testing, for your integration testing. And with that, I think the best way of showing that is to obviously pop in and do some live coding. And that live coding is going to be in the open telemetry demo. And yeah, if we don't have any questions, we can probably pop back in and just pop into the code. A quick question. Oops, yeah. Are traces supported on the database layer with open telemetry? Yep. Yes. Short and sweet. Yep. So if you use Postgres, Redis, whatever you can think of. Yes. So I'm going to show that in a bit as well. So if you're patient for another maybe 15 minutes, I'm going to show some interactions in between a API, so a GRPC API, and some actually a Redis database. So... Cool. Will you zoom in just a tad, please? I will, so let's... Thank you. Nice. Please, probably fine. Cool. Now, so the thing I really want to show from the get go, just to have everybody on the same page, we did look at the architecture overview. So I think the best thing we can do is also check out the actual Docker compose file that is part of this demo. And you can see we have tons of, tons of lines of code, and it's basically, you can see accounting service, you can see all of these services. We're just going to pop down to the payment service because that's the one we will be changing and editing. And then what's happening in the payment service is quite simple. So it's building a file, it's loading some environment variables, and it's just starting. I mean, it's nothing really magical is happening there. What I do want to show, just really quickly, is the actual Docker file that gets, that is used within the payment service. And what's happening here, it's obviously, yep, I'm loading in, that's not the one. Let me just change that up. Mr. Fumblefingers, there we go. So what's happening here is just a note app, I'm loading the source from the payment service, I'm loading the proto file as well, and I'm just running it. Super simple Node.js service. Now, one thing I do want to note with the actual Docker compose file that is quite important for, if you want to contribute to the open telemetry demo, is something called profiles. So profiles in the Docker compose is just a way of selecting which services are going to start by default versus which services you want to specifically tag when you're starting Docker compose to spin them up. Now, the profiles that are named with test, those are going, obviously, they are going to run the front end test, the integration tests, the trace based test, and then obviously trace test server, which is the testing harness that we're using. That was all postgres because it's a requirement, but that's less important. One more thing that I really want to note as well is that I've added in this dev profile to the traces server, just because I want to have that up and running when I'm doing my red green. Actually, when I'm editing code, when I'm testing the code and writing the instrumentation, so that my software relevant life cycle is actually up and running. So I want to do that. So when I actually pop back into my terminal window, I have the demo running here and I'm running it with Docker compose profile dev up. So this is going to start my demo. You can see here, I'm running my open telemetry demo, all of the services are there up and running, perfect. Now, one other thing that if you want to continue contributing, there's a really nifty little file called make file. And in the make file, you have all of the commands set up for you. So if you want to run tests, you can basically run the tests and it's going to trigger all of the test containers. Same if we want to only run the trace base tests, you can do that as well. And then obviously you can also just run start and just run all of the services that way. Now, one thing that I really want you to check out a bit is that this command is going to trigger the trace base test. Now, I do want to show you this really quickly. So if I do pop back over to my terminal and let's say this one, I want to run only the trace base tests for the payment service. So the payment service that we actually checked out a moment ago, this is going to spin up everything for my payment service and it's going to run the trace base tests. And if I pop back here into my UI, I'll see last run. And it's going to actually test suite, is going to start this test suite for my payment service. And you can obviously do that whilst you're developing when you're actually... Oh no, just kicked you out. Oh, sorry, did I die? You just, I don't know. They got you kicked out of the room for momentarily but you're back. Yeah, you were only maybe cut off for five seconds worth. It wasn't long. Well, I mean, that's just, I was talking too much. I'm sure it is. The forces that be somehow restream new, you're paid extra for that feature. Right. And perfect. Now, what did I want to say? Yeah, so the payment service and this is going to trigger all of the tests that are currently in the demo for the payment service. So it's quite simple to actually get started if you want to contribute to the demo. I mean, I would definitely just kind of jest, you would because it's super fun. And also what I want to show as well here is that the way that this, I mean, you can also obviously in the terminal, once the tests are finished running, you get the either passed or read as failed for the test specs as well. So this is just a usual, just the usual way of testing that everybody's used to as well. So it's very natural. One thing that I do want to show though, for this particular step is that the way this is getting run. So let's say, let's actually dig into this trace-based tests container. If we look at it right here, what's happening is that it's loading a Docker file and it's loading some environment variables. If we open the Docker file, let's say, so it is this Docker file, no, it's not, it's this Docker file. Okay, see the only thing that really happens is that it's running this app test, trace testing run bash script. So what's happening in that script is that it's pulling in the CLI to actually run these tests automatically or automated in an automated fashion and it's generating something called a variable set. Now it's quite literally loading in all of these environment variables. Now, which environment variables you're actually asking? Obviously the environment variables for the entire demo and the things that basically, let's say, the important things like the actual addresses for the services and the ports for the services. And this is because we really want to pull that in so we can run the tests. So we're pulling those in so we can run the tests. And then what's happening is that all of these, all of these environment variables are getting loaded into the test files and then the test files are going to get run that way. And with that, I think we can move on to, yes, the important part. It just wants to really remember. Yeah, go ahead. A couple of questions, so is that now a good time?  Okay, we do have someone who wants to follow up with questions later to you. Do you have a good way to contact you? Yeah, for sure. You can either do my email or, I mean, you can jump into the CNCF Slack and just Slack me there. I'm in there, you can probably find me there. It's the easiest way to find me. Excellent. And then we have a question here. Seems like database tracing is clients-based or have the database tools like Redis Postgres, et cetera, built-in server-based hotel support already or is it not required? No, I mean, so the code we added in in the OpenTelemetry file for the Node.js SDKs, it's going to pick up all of the interactions with the databases. So that's the only config you really need. Cool. And then someone asked just kind of generally about Helm. How does Helm relate to OpenTelemetry? Well, I mean, if you want to, that's probably a question for, regardless to the OpenTelemetry operator for Kubernetes. Yeah, I was thinking that too. I'm not actually sure if they have a Helm setup for the OpenTelemetry operator. I would think so, but we'd have to check. I mean, yeah, we can probably check that later on and then just forward that to you. Cool. And those are our questions right now. Sweet. And yeah, so with that, this is just a basic run-through of how you can yourself get started with contributing and also running the trace-based tests. Yeah, one cool thing is as well, if we pull up this. So I did obviously run this test by passing in the payment service. If I want to run all of them, I could just trigger it like that and run all of them. But for the purposes of this demo, I think, I mean, we don't really need to do that. What I think is gonna be more fun if we actually jump into the code a bit more as more specifically jump into the code of the payment service itself. Now we did jump back in here. So let's open up the OpenTelemetry file. So we did jump in here and add in our instrumentation. One more thing I really want to show you before we move forward is I want to explain what the actual code of the payment service does so we can understand what it does and how to write the instrumentation for it as well, which is what we're gonna be doing in the next few minutes. And I think the best way of doing that is first, let's pull up the proto file. So let's do like that. And in regards for the payment service specifically, we have these four things that we need to look at. So the payment service has a charge function. It takes a charge request object and it returns a charge response. Very simple. The charge request has a money amount parameter, also has a credit card and it's this specific object and then it's returning a string. And that's basically it. So just understand what's happening here. And if we pop back into the service itself, let's say first the index file, you can see that's pretty much the same thing that's happening here. We have a charge service handler. We're putting in the call request. So the request object is getting passed into the charge function. The charge function is getting called here. As you can see, charge function. And we're setting, we're actually grabbing the values from the credit card that gets passed in. We're getting the details. We're validating the card. We're throwing some errors if it's invalid. And then with that all done, we specify the requested amounts and we generate, obviously we generate the transaction ID up here. And we pass that transaction ID back to the, as the response here in the index, in the service, and then we're just running a callback. So it's a very simple, very simple little service. What we want to do now is you can see that we have a bunch of code that's commented out. And we're going to specifically step by step add in some of this code to show how the trace changes and how we can change the testing against or actually change the test specs against this particular service. And with that, I think the first thing we can do is just start adding in some open telemetry instrumentation. So just to refresh our memory, popping back into the test suite. Let's do last run. And let's do our, let me just find it. Okay, I'll just rerun the whole thing to not think about it. Let's do like that. Let's rerun our, our tests really quickly. And let's pull up the, this one. And let's pull up the test just to refresh our memory on what the trace looks like right now. So this is only having the auto instrumentation. It's going to pull up a little trace and it's going to show me these two spans. So I have my trigger span and I have my RPC span. And this is, you can see payment service slash charge. Obviously this is the payment service and the charge function that I just showed you in the code. Now from here, I can go in and say, yeah, I want to make sure that my status code is equal to zero. I want to say it should return status code zero. I can go ahead and save that test spec. And now every, every time that this particular test runs, it's going to want my RPC span to return status code zero. Sure, that's cool, but that's not really that specific. We can do much, much better. And this is what I would say that we can do. So the first thing is we can pop in back to the code. Let's say, let's go ahead and add a context where we're getting the current span. So we're basically, we want to get this current span from the context and it's going to equate to this particular RPC span. So if we pull that in, we can then go ahead and say, yep, I want to add some attributes to this span and I want to add a span event, which is, I mean, it's just a fancy word of saying a log, right? So I want to add the payment amount and I want to add some values here. So let's say severity message request. I'll also obviously need to go ahead and kill the span. So I always need to make sure that if I'm starting a span I need to end it. And I also want to add a status to my particular span. Now, because this current service also has a charge function, so this particular function, I also want to pop into the charge function and I want to do the same thing. So I want to go up and again, I'm getting the active span. So the active span is going to be my RPC span and I want to add some span attributes. Let's go in and add some span attributes and this is a kicker. I also want to check, so because we have a valid value here because we're obviously validating the card and then getting that value back, I want to add that as an attribute so I can run our test spec against that particular value, which is actually pretty cool. Yeah, let's close up the span and next thing we can do, I think that should be it. Next thing we have to do is obviously just rebuild our, rebuild our payment service. So let's go ahead and stop it. And whilst we're rebuilding, are there any questions we might take right now whilst we're waiting? We're, no, we're good right now on questions. So yeah, this is actually going faster than the expected rebuilding this. So this is a kicker. So we're basically adding in, it's not a lot of code that I was writing. It's a few lines and a few attributes I'm adding, which is the process of adding this is not very different from the way you would add in custom logging. I mean, you can confirm or deny, but for me at least it's not that big of a difference. And that's what I particularly like. And then let's go ahead and start it like that. And with that started, let's just validate one more time that we're actually running it. It is perfectly up and running. Let's go ahead and run this same test once again. So let's go ahead and pull up our exploratory test once again, and pulling it up in the UI once again. Now, so if I've done this right, if I've done this right, I'm gonna have a few more attributes on my RPC span. Now, it will be pretty funny if this just kind of failed miserably. Everyone's rooting for you. But yeah, sometimes we learn more troubleshooting, I think, than when things don't go right. Yeah, I agree, I agree. Oh yeah, that's moment of truth. Let's see, nice. So yeah, so now we have the app payment amount. We have the app payment card type, and then we also have the card valid. So we have all of these custom attributes. We have them added. Even the span events here, you can see that we have the log. So it's a very log message idea. I can even run some test specs against the events here as well, which is, I mean, it's freaking cool. I mean, if this isn't cool, I don't know what is. And that's the cool part. Let's say I want to actually do a custom test spec against my card valid true. And I'm gonna say it should return a valid equals to true. Like that. Save that up. Let's go ahead and save that whole set of tests. And here's what we get. So now, if this card is invalid, I mean, maybe it's getting that value from the code itself. And it's part of my distributed trace, meaning it's part of my test harness, which means if this changes, I know something's wrong. This is as white box testing as it can be. It's freaking, I mean, it's actually pretty cool. But let's not just stop there. Let's do some more cool things. And what I think we can do specifically is this setup doesn't really give me a good point of view of what's happening. It's just one RPC span. I'm not quite sure what else is happening. I have some custom attributes, which is cool, but we need to take it a step further. And the way we do that first, let's just stop our payment service while so changing some code. And the part of the code that I really wanna change, I'm gonna pop back into the index. And let's just, here at the beginning, I'm just gonna comment out this part and I'm going to put in this part instead. Now, what's happening here? Again, we're doing the same thing. We're getting the active span, which is the RPC span. But we're setting it on the context and we're creating another span called charge service handler. Okay, okay, cool. So we have another span, that's a child span of our RPC span. But also we want to do the same thing for this part of our charge function. So let's say we pop in here, we say, again, in the same type of thing, we're getting the active span, but this active span is not the RPC span anymore. Well, no, actually, no, I'm wrong. It is the RPC span still, because this will create a sibling span with the span that I was just mentioning. So this charge service handler, it's going to be added to the active span, which is the RPC span. And this span, the charge span is going to also be added to the active span, which is the RPC span. So we're gonna have one RPC span and two sibling spans. I might have messed it up, but let's hope I haven't. So if I- Do you have a graphical representation? I feel like you should one earlier, yeah. It is coming. So let's do a rebuild or payment service. So that's what should happen. So if we move back, so we rebuilt it. Let's go ahead and run it up and run a start. Now, if we rerun the test once again, let's go ahead and run our exploratory test once again. Let's go back into, I believe we can also just rerun it here. Let's see what happens. So if I've done this right. And trace test is open source? Oh, yes, of course. It's part of the CNCF landscape as well, which is, I would believe that was one of the reasons why the open telemetry team decided to add it in as a test harness. Cool. I like Kyle's hype. Yes, Kyle's. There we go. And I was right, believe it or not. We're getting two sibling spans that are part of the GRPC, so the RPC span here. And what I particularly like about this is that with this, I can add a, I want to make sure all of my GRPC spans are okay. Cool. I'm just targeting my GRPC spans. But then I also want to target these individually where I want to say, okay, so I want to make sure that my hotel status code is okay here for this one.  But in my charge span, I want to make sure that my card valid is equal to true. Say it should be true like that. So I'm basically splitting up my test specs based on the spans. And this just makes it easier to figure out. And I can actually, by looking at this trace, I know that I have an RPC server running. I know that I have a charge service handler somewhere. And I know that there's a charge function that's getting run somewhere as well. But we can even take this a step further as well by doing it the right way. The right way should be that this charge span should actually be as a child of this span. Because that kind of just makes sense because it's triggered from the service handler. It's not triggered from the GRPC specifically. So let's take another stab at that. Let's do another, to stop the service. While that's stopping, let's just change that up in a second here. Let's comment this back up. And we want to do something that's called start active span instead. So the start active span, what that does is that it gives you this callback function. And everything that happens in between, so in this callback function, is going to be nested within that span. So it's going to create child spans within that nested callback. Let's put that here. And let's move that a bit like that. Let's clean that up a bit more. And we're obviously, let's clean that up a bit more. And also put that there. And if I've done this correctly, you can see that this callback function is again going to, also we need to change this up because we don't really need the context anymore because we're running this function in that callback function within the active span. So what's going to happen now is that this charge span right here is going to be part of the active span, which now is the service handler span. And with that, let me go ahead and rebuild our payment service. And let's go ahead and restart it again and run the same test once again. Let's go ahead and do the upstart and the start like that. So. So exciting. Yeah, I mean, it's taking a while, but we're getting there. So now, if we do rerun the test this time, and this should ideally say, number of spans collected should be four. So just give it a moment to iterate through them. And it's going to show us a nice linear view. So a nice visual linear view of what's actually happening in our code. And then we can go ahead and run our tests against that and add specs logically, I would say, against those spans. There we go. So now this makes more sense now. We have our RPC server, we have the charge service handler, and we have our charge within that. And again, the tests are passing just fine. It doesn't really matter, but I think it matters. Looking at this, this just makes sense now. I have a question and we also have one in chat. My question is you've written all the tests in the UI. Can you write tests with pure code or do you have to interact with the UI? We, yeah, next step is going to be running all of this in the code as well. So just with YAML files. And that's the neat thing here as well. If you jump to the automate tab, you get the text file as well. So you can just copy this and run it with the CLI command.  It doesn't really get any simpler than this. And doing that actually in the UI, and actually sorry, in the CLI and the code editor is really simple. If we pull up the test itself, let's say we do here. So we have the valid credit card. So we want to just check if the card is valid. We have our, obviously we're our proto buff file. So the demo proto was showing a bit a moment ago. And then we have obviously our request. So this is the amount and the credit card we want to pass into the payment service. And we can trigger this and add in our test specs. Now the magic about the test specs is they're quite literally a part of this file. And the way they work is that the selector here is the selector, it works in the same principle as I was showing in the UI as well. Where if you pop into the UI, you can basically go in and say, I want to run a test against, let's say this one. And I can see here span type general name charge. If I copy this over and let's say I add it here and run this test, let's do like that. Let's copy that and put it right here. So let's say it's part of the, let's do like that. Add in another name, should return a valid credit card. And let's say I want to do the span general name charge. You put it here in the selector, span general name charge. I want my attribute, I pulled the attribute as well. I want it to be attribute like that. App payment card valid, should it be equal to true? That works perfectly fine. Let's save that up. And let's go ahead and run this test now instead. If I go ahead and point to that file in my CLI, I'm gonna do like actually let's just delete that part. And let's say it was called valid credit card. Obviously that happens because you're not attentive enough. We obviously need to add in the, it's a list of, let's pop back in there and let's run that again. And this is going to ask me for, this is what I like calling an ad hoc test. So it's going to ask me for environment variables, which is super cool because remember, maybe 30 minutes ago I was talking about the environment, how we're adding the environment in the run bash file. And here's how that gets loaded. So anytime I want to run this from an environment that's already set up, so I can see here the variable set here, I can see, so here's my variable set. I can also do that in the CLI as well where I want to say it is like that. And it's, I think it's, Rars, it's probably Rars. If I mess this up, it's on me. Cool, so I'm pointing to the environment actually the variable set that I have already configured. I can obviously just write a file for an environment for the actual variable set and have it that way. But yeah, let's pop back into the UI so we're not waiting for the terminals to get back to us. Let's do, yeah, here we go. Recent last run. And here we can see right away payment, valid credit card. We're getting the transaction ID back. We have our trace and obviously we have our test. And right here we can see that all of these test specs are equivalent to what we're getting. Obviously we're getting the same back in the terminal, but we're getting the same test specs as we have that defined here in the test file. Which is, I mean, whatever you prefer doing, one cool thing is that when you're running in CI CD, you have all of these, you can generate all of the tests by hand if you want to actually see what's happening. You export the files and set that up automatically to run with the CLI and any CI CD process that you have. Amazing. We have one more question in chat. And then I think we're about finished with time. But let's go, how is privacy handled in OpenTelemetry? Is that left to the trace store or features like masking can be leveraged out of the box? As far as I know, there are, so it's handled in the collector. So the OpenTelemetry collector, who doesn't know, we can just pull that up as well here in the OpenTelemetry documentation. So the collector is basically, it's a piece of software that acts as the middleman in between your system, sending traces and the trace data store. And then you can do pretty much anything in the collector. So you have different extensions, you have different processors that you can add in and the processors are, you can do tail sampling, you can do head sampling, you can basically do a bunch of different things. And for this specific thing, I think it's called masking. I'm not quite sure what it's called. But if you do pop into the collector and then look for that specifically, I'm sure you'll find it. Also, the CNCF Slack has a dedicated channel for the OpenTelemetry collector. So asking them as well is going to give you an answer even quicker. Yeah. Is there anything else you'd like to add to your presentation before we say goodbye today? I mean, I think this is super cool. So I could probably be talking about this for another hour or so, but I don't really wanna waste anybody's time. But yeah, if you have any more questions, we will be, I'm going to try to add this, all of the examples that I showed today and even more, I'm going to make sure to add this to the, so basically just the fork that I'm maintaining of the OpenTelemetry demo. And then share it with everybody so you can try these samples yourself if you want to just get up to speed or if you want to add it to your own project. So here's the GitHub of the OpenTelemetry demo. And yeah, and your fork is... Yeah, I'll just add it in. I can also add it in here. So it's just, I'll actually try to make sure because the official OpenTelemetry demo, they have this little part here at the bottom. So here, so there are different demos from different tools and vendors that maintain their own forks just to show people how it's run. I'm going to try my best to actually get a version in here from the examples that I showed today just to have it so everybody can pop in and see if they want to try it. Awesome. So we have the GitHub URL now to see the demos if you want to get your own hands dirty with everything that we saw Adnan do today. Please, please go for it. This has been super informative and super fun. Yeah, yeah, you're super impressive. I appreciate you sharing your time and your expertise with us. And I appreciate everyone for coming and sharing your time with us. Everyone's time is so valuable. It's such a gift that you're giving us some of yours. So thanks everyone for joining today's episode of Cloud Native Live. It was great to have Adnan Rahit here teaching us the power of traces while open telemetry embraced trace-based testing. I also, as always, really loved the interaction and questions from chat. Y'all are the best. So here at Cloud Native Live, we bring you the latest Cloud Native code on Tuesdays and Wednesdays at noon US Eastern. So we'll be doing another show tomorrow. So thanks for joining us today and thanks for those who watch the recording and we'll see you again soon. Bye. Bye.


In 1924, 41 Milford miners lost their lives in one of the worst mining disasters in Minnesota history. Only seven miners survived the accident. The Crow Wing County Natural Resource Advisory Committee toured the newly renovated Milford Mine Memorial Park. Our Locan Gay has more. The Crow Wing County Natural Resource Advisory Committee took members of the community on a tour of the newest features at the Milford Mine Memorial Park. The committee started working on Phase 1 of the project in 2010. Wednesday they celebrated completing Phase 3 of the project, which included the opening of a new bridge. The completion of Phase 3, which is getting people across the fabulous boardwalk, getting them to the actual mine site where there's the main mine shaft, the timber shaft. Among the tour were relatives of miners who used to work in the mine. Did your dad used to work in the mine? Oh, yeah. He was the first one out of the mine when it did that. Seven will come out. He was one of the seven. When I'm walking here, this is sacred ground because I said my father's footprints are all over here. And one of the newest features in the park are these individual plaques that tell the history of each miner that was lost in the mine. It's what we call a memorial wall walk. There's a memorial wall and then there's a walkway that gives you good elevation above Milford Lake where we identify the miners, their families, and the little biography of each of the miners that were lost in the disaster. The Natural Resource Committee is hoping that the newly renovated park will be a place for families to come and enjoy recreation activities and reflect on the history of the community. Well, you know, I hope the school children come out here because there's so much history and there's so many things to see. And as I think Kayuna is reinventing itself with the bike trails and now this wonderful memorial. And Woodford Township, Logan Gay, Lakeland News. The Crow Wing County Natural Resource Advisory Committee is currently planning additional work to the park, such as bathroom facilities and a canoe launching platform. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.


So floating particles like flower petals, embers and leaves are some of the easiest ways you can make your scene look three times cooler. So I uploaded a pack dedicated to just those two things. Now I do have tutorials on how you can create and adjust these types of particles available for free if you want to check those out. But really the most important part of this kind of effect is the type of textures you use to create the particles. So if you want variety in the designs of your floating particles under the flower petals folder, I have included 22 different designs for the types of leaves you may want and 19 different types of designs that you can use to get different looking fire flakes. Installation is really easy once you download the file. You just copy the effects folder and paste it into your project somewhere in the content folder. So if you think that would be useful for you, you know where to find it. Hope that helps and as always, I hope you have a fantastic day and I'll see you around.


Good morning everybody and thanks very much for joining us today. My name is Mark Fiddler. I'm a senior community education officer with the RTA and I'm joined today by Lynn Smith from the RTA. Morning, Lynn. Good morning, Mark. Thanks for having me again today. No worries at all. So thanks everyone for attending today for our third webinar in our HLA series. Before we do start, I would like to acknowledge the traditional owners of the land on which we are meeting today and also where you are joining us from and pay my respects to elders past, present and emerging. So today's session is focusing on the rental reforms and the topics around repair order processes and other amendments. These new changes will come into effect on the 1st of October 2022 and we'll also touch briefly on the minimum housing standards that are going to kick in around in September 2023 but Lynn will speak to you a little bit more about that shortly. So today we will have a question and answer session before we finish up. We'd love to receive your questions. What we'd like you to do is click on the chat function or speech bubble on your Zoom toolbar. If you can't see it, click on the more and look for chat in there. We'd also like to hear from you on how today's session went as well as any future topics you'd like to know more about. So please keep your eye out for a survey sorry when the webinar closes today. I'll now hand over to Lynn to talk through the rental reforms and the tenancy changes regarding repair orders and other amendments. Over to you Lynn. Great thanks Mark and you'll be back to assist with some question and answer time at the end. So please everybody please do use that chat function. We are today just focusing also just on the topics that we are doing today. So the role of the RTA as an independent statutory authority is to administer the tenancy laws for Queensland. The Housing Legislation Amendment Act 2021 was passed in October last year and it amends the residential tenancies and roomy accommodation Act 2008 which is the Queensland Tenancy Laws. There are four key areas in these amendments domestic and family violence protections which were already in place as of October 2021. Then we have the new laws as of one October which is the framework for negotiating renting with a pet changes to the reasons for ending a tenancy and also to other the repair orders and other amendments and as of one September next year the minimum housing standards will start. So as you can see the image on the slide on the slide there's different stages from the consultation through to the Act being passed. So today we are going to be focusing on repair orders and also some other amendments. So before I do look at the new changes I just want to remind everyone of the process regarding the rights responsibilities under the tenancy laws are still in place. So the less all obligations under section 185 and that is to ensure the premises are clean, fit for the tent to live in, not in breach of any health and safety laws and while the tenancy continues that the owner will carry out those repairs and maintenance. Also too the tenant has that responsibility to notify the owner or the manager of any damage or repairs and that's outlined under section 217. So there is a difference between emergency repairs and routine repairs. So emergency repairs are listed in the legislation and while the list is fairly extensive it does list items such as like a burst hot water system or it could be a burst pipe causing flooding, it could be a serious roof leak, a gas leak or dangerous electrical fault or could be from storm damage. So when you look at the list it is a fault or damage that makes the property unsafe, insecure or is likely to injure a person. So with routine repairs there are things such as like you drippy taps, your stove element may not work or it could be a loose covered hinge or a broken clothesline. So access will need to be given by the tenant to carry out the repairs and the owners and managers need to follow the rules for entry and make sure that notice is given for when a tradesperson is to gain entry. So we also too acknowledge that at times it can be difficult to get a tradesperson on short notice or it could take time and currently we know that this may be the case in some of the trades out there or that there may be delays in getting parts. So respect and good communication is key so keep those lines of communication open so everyone's aware of what is happening and why. So from 1 October 2022 the new repair orders allow an additional pathway for tenants to have repairs carried out. They will be able to apply to the Tribunal if the repairs have not been done and the Tribunal is the Queensland Civil and Administrative Tribunal or QCAP. This will be for routine repairs and emergency repairs. So for routine repairs the repair order is that the process first is that the tenant will have to inform the owner or the agent first of the repair. That could be by way of an email maintenance request or breach notice and the repair if the repair wasn't made in a reasonable time. It is a non-urgent application so they need to go through dispute resolution at the RTA before applying to the Tribunal. Now for emergency repairs this is where the repair is urgent as defined under the Act. Tenants have not been able to make contact with the emergency contact person or the nominated repairer in the agreement. On the repair is not done in a reasonable time. A tenant can then apply directly to the Tribunal for an emergency repair order. That's an urgent application so they do go directly to QCAT and not through the RTA's dispute resolution process first. So repair order is looking to ensure that the owner or the manager will carry out the repairs in a timely manner. So it does not apply to movable dwelling short tenancies nor does it apply to roomy accommodation agreements. So we are just focusing on your general tenancies such as your houses, units, your townhouses and also to your long-term movable dwelling tenancies. So a copy of the repair order will be provided to the RTA from QCAT to our compliance and enforcement team. It is an offence to contravene a repair order and it is a maximum of 50 penalty units and also a weekly offence. If it continues of five penalty units for each week the offence continues and it's not repaired. So an owner can seek an extension of time to comply with a repair order but they need to be doing that prior to the expiry date of that repair order. So reasons may be because of hardship. It could be that there's a shortage of material to make those repairs, remoteness of the rental property or can't find someone qualified to do the repair. So there is information on the Tribunal's website all about the application, fees and everything. So that's QCAT's website qcat.qld.gov.au. So to keep in mind going off to QCAT is self-representation and whether you're applying for a repair order or seeking an extension of time or applying for any other tenancy or bond matter you will need to check your application and any other information that supports your claim and on the day of the hearing make sure that you do have your paperwork and evidence ready for your case. So it is important tonight here to that a repair order when granted is attached to the rental property and not the tenancy. So if there is a new tenant or a new managing agent or a change of ownership the repair order continues until it is complied with. There is a requirement to disclose a repair order to new tenants and I will talk about that shortly. So just to summarise the difference between a routine and emergency repair process. So your routine repairs are non-urgent matters so they must go through the RTA's dispute resolution service first. With the emergency repairs if a tenant's unable to contact the owner or the manager or the nominated repairer that's listed on the agreement or they don't carry out the repair and seek reimbursement they can reply to the tribunal directly. So the legislation does outline the rights and responsibilities for both tenant and the property manager and the owner in relation to the repairs and maintenance. So even application is made to the tribunal they may grant an order and it's in the legislation that it does state that the tribunal must consider the conduct of the owner or the agent, the risk of injury, the loss of amenity and any other matter that the tribunal considers relevant. So in granting an order the tribunal may make a direction about the repairs so it could be that if the property is vacant they may make an order that the property is not to be occupied until the repairs are completed. Repair order may also include what is or what's not to be repaired and by what date. A tenant could also arrange a suitable tradesperson to do the repair or who is to pay for that repair. It could also be a reduction in rent or a compensation amount to be paid. It could also be a suitable qualified tradesperson assesses the need for the repairs or it could be that the agreement ends if the repairs are not done by a certain date. Remember good communication is the key to resolving most tendency disputes and we do encourage all parties in the tenancy whether you're the owner, manager or tenant, talk with each other respectfully, look to work together to find those solutions. The RTI has a lot of resources available on our website about self-resolution tips and also resolving disputes so that includes like a webinar, podcast and other information about how to apply to the RTI's free dispute resolution service. So now let's have a look at the other amendments that are also coming into play. So today we are not focusing on the ending of a tenancy or the framework for negotiating renting with pets and you can find our previous webinar recordings on our website on those specific topics as well as other guides and fact sheets and videos. Okay so the other amendments and we'll just continue a little bit here with the focus on repairs. So for general tenancies an increase from two weeks to four weeks for the cost of emergency repairs. So our current legislation states that the tenant can organise an emergency repair and spend up to equivalent of two weeks rent and have this done and seek reimbursement. As of 1 October 2022 this will change from two weeks to be four weeks equivalent. There is a new section 219A for those who are real estate agents or property managers in the room today or in our online session I should say that the Lessels agent may arrange for emergency repairs to be made. Meaning that managers will be able to authorise emergency repairs on behalf of a landlord-client up to the equivalent of the four weeks rent and make deductions from the rent payments up to the cost of the repair before disbursement of funds. Now we do know for property managers you do need to keep in mind whether you need to amend any contractual agreements that are in place between your office and your landlord clients to meet these requirements as you will need to comply with obviously other legislation requirements. So that could be the Property Occupation Act and as that's not covered by the RTA that's the Office of Fair Trading so you may need to be looking at your forms in relation to that contractual arrangement that is in place between your office and your landlord client. So section 216 has been slightly changed and it now states that the agreement or notice must not may but must state the name and number of the nominated repairer. So you do need to have a look at your agreements and make sure that the tenant knows who to contact in case of an emergency repair and let's face it emergency repairs usually don't happen Monday to Friday 9 to 5 they're potentially going to be happening after hours on weekends. So the main purpose of this is to make sure that a tenant has a contact person to be able to or repairers to be able to get those repairs done if it is an emergency repair and again emergency repairs as outlined under the legislation. So the other changes that's coming through is in relation to the entry condition report. Now we know not just the tenancy agreement at the start of a tenancy is an important document but so is the entry condition report. So currently tenants have three days to return a signed and completed copy of the entry condition report back to their property manager or the owner. Now the new amendments will see that this timeframe will be changed from three days to be seven days. So this is giving the tenant more time to be able to complete the report sign it and return it. This new section will also apply to roomy accommodation as well. There's also been some clarification around that unless a new condition report is prepared for a renewal agreement then the entry condition report for the original agreement is taken to be the report for the tenancy. So that's probably a little bit more business as usual. A new section for roomy accommodation that the provider will need to give a copy of the proposed roomy agreement to the resident before they're committed to that tenancy and when we say being committed that is before they sign the agreement or pay any money. So this is actually probably bringing it into a line a little bit for roomy accommodation to be very similar to what is already in place for general tenancies. So there's also a new section that is to offer a residential tenancy must disclose particular information. So currently the owner or the manager must provide a copy of the proposed agreement to the prospective tenant. There is now a new section to disclose particular information under a regulation. So the regulations have been released as of the 22nd of July and state that the agreement must also show details of any repair orders that apply to the premises or the inclusions. So this will be updated and on the new 18A the general tenancy agreement that will be available as of 1 October. There's also been a few other bond management tweaks in the amendments but another change is the section 136D. So the tribunal may make an order about a rental bond payment having regard to the efforts made by the tenant to comply with the tenant's obligations under section 1884. Now this 1884 section has not changed it still stays and that is the tenant is to return the property in the same condition it was at the start of the tenancy less fair wear and tear. Hence why really super important to make sure that you have your documentation at the start of the tenancy whether you're the owner of the manager or the tenant make sure that you do have that entry condition report. It also goes on to talk about the tribunal may look at the less or intense compliance with the act and the evidence supporting any bond claim. So again really super important to have those entry and exit condition reports and photos as further evidence to help support any claim that might go through to the tribunal. Now I'm just going to quickly touch on minimum housing standards. This was first passed back in 2017 as part of government's previous election commitment. So just to touch on this it does not commence until 1 September 2023 for new tenancies and then it's the following year so in 1 September 24. So for all tenancies so it is giving owners that time to be compliant. Now minimum housing standards the amendments fall into two areas. First is safety and security and the other one is reasonable functionality. So what we do know that some of the items have been listed under reasonable functionality is like since we fairly standard their functioning kitchen and laundry's adequate plumbing and drainage that the properties weather proof and structurally sound. But it's also put some clarification around fixtures and fittings to be in good repair and not to cause injury, locks or latches on windows and doors and that is to help secure the property. The property needs to be free of vermin, damp and mould and also the requirement of privacy coverings so your blinds and curtains. So we will have more information and education in the lead up to the provisions during 2023. So there is time for compliance so owners and managers may want to put a plan in place so that you're right to go as of 1 September 2023. But remember section 185 I talked about originally when we when I first started the session today is that is still in place in making sure that the property is still fit for the tent to live in and that repeats and maintenance are also carried out during the tenancy. Remember this is about the properties that are to be safe secure and functional. So where to next so we will be providing more information education on the tents or changes. So over the past few weeks you would probably see on our website there's been more additional resources added. So all our forms and publications will be updated and will be available as of 1 October and we will also have other educational resources there as well. So we have our webinars, podcasts, videos, fact sheets, quick guides that also step you through these changes. We are also working collaboratively with our key stakeholder groups as well. So the webinar series on the tenancy changes will also include or has also include topics of ending tenancies and the framework for negotiating running with pets. So you can find those recordings on our website. The next part and the final part of the series is your questions answered. So where we will summarise a lot of the questions that Mark and I have seen during the past few months either from our face-to-face sessions that we have delivered across the stage or from our webinars that we have done in the past. So we will be able to address a lot of the common issues or common questions that's been asked and some of the tricky ones as well and also keep in mind a copy of today's recording is also going to be available on our website over the coming week. Now Mark I'm going to come over to you because I know that I can see my screen has just been ticking along here with a lot of questions. Thanks very much everyone for submitting your questions into chat. If you still have questions continue to do so but we'll start to have a look at what has come in. So Tina has asked tenants have reported a problem with the dishwasher. So why do your repairs been organised immediately? However due to a labour shortage the repair is scheduled for three weeks away. Do tenants have a right to demand a rent reduction and if they do what would be the reasonable amount? Okay thanks for your question Tina. Look there is a part of the legislation that does talk about if a service or an item has actually been removed then the tenant would be right to request like a reduction rent until that item is actually reinstated as such. What is a reasonable amount? We probably couldn't tell you what that might be that would be between you and your tenant to negotiate something that is reasonable but yes if it is going to take a while to get something repaired we do recommend getting an early and communicating and negotiating something between yourself obviously as the manager or the owner and as well as the tenant. If you can't resolve something then obviously the RTA's free dispute resolution service can possibly help you. Excellent Lynn. Now Dale's asked around if this only starts from the first to the 10th 2022 will it not retrospectively apply? Now I'm assuming that he's talking around the transition periods and would you like to provide a little bit of information on that? Well the transitional period is also noted there in relation to particularly if there's any notices and things that's been started under the current legislation versus the amendments that come in as of 1 October and you can find information on that on our website as well but I'm not sure whether it's retrospectively in relation to a specific section there so a specific topic or anything I'm not quite 100% sure on that Dale sorry but honestly everything will start from 1 October so in relation to repair orders you can ask for repair order now if you went in and applied to QCAT they it's not going to start until after 1 October. But they will apply to tenancies that have started before that date? Oh sorry absolutely so if you have a current tenancy in place absolutely. Yeah and that goes on. Caitlin's asked a question around do existing lease agreements need to be amended to show emergency repairs or would a bulk email to all tenants advising that these changes suffice? And this is what we haven't had before. We haven't actually had that question before so I do thank you for that question. Look I suppose it does talk about in the legislation it does say that the agreement or noticed must state so potentially we could say that providing the tenant knows where to contact and everything like that that's the main the main purpose of that so making sure that they are aware and if you have evidence to say well we've actually ensured that that has occurred then potentially you could be looking at compliance with the act in that way. Robin popped a question in around a tenant locking themselves out of the property and is it considered an emergency? I would suggest Robin in that situation that that's the tenant's responsibility because the house is still in functioning order they've just not used it properly so in that case generally the the tenant is responsible to provide themselves access back to the property in those circumstances whether that's getting in touch with the agent or finding themselves in locksmiths to do that. Giving an entry notice for a trade to attend to property within a two hour window generally not possible the two hour window sectional legislation yeah doesn't apply to trade to people because of that exact reason that's been stated there they're busy and hard to get. So Wendy just to be very clear that two hour window is in relation to routine inspections so if you are going to the property as a managing agent or an owner and instead of putting a specific time down you have the option of putting down as example nine to eleven that two hour window does not apply for tradespeople but what we would do is obviously always recommend you trade and obviously yourselves talking to the tenant and letting them know that the reason why you're giving a longer time or that giving a day is to make sure that they're aware of the reason behind that again shortage of tradespeople or that they can't nominate an exact time. Rachel has asked Lynn where is the repair order listed and if I take on a new management can I see if there is a repair order? The repair order is not going to be listed there's not such like a database so I think that in relation to that you are just going to have to ask and hope that your new land law client is going to be open and truthful with you about if there is anything that's outstanding. Excellent what happens if the tenant does not return the entry condition report within seven days? Same as what we currently have in place obviously if the tenant doesn't return the entry condition report you might do a follow-up with them it's obviously and everyone's best interest that they do complete it and sign it and return it if they don't it's still deemed to be that the entry condition report that's been completed is still a condition report for the property. Okay penalty points will this be applied to the owner or the agent if the owner hasn't agreed to repairs what would you suggest? Look I suppose it really comes down to if there's a complaint made and obviously to the RTA would be looking at obviously all the information that's required we can never make a comment on our investigations what the individual compliance and enforcement member does but at the end of the day obviously you would be looking to make sure that you've obviously requested that information from the owner and so forth and follow it down those path and obviously good communication against key and also to reminding people of their rights responsibilities under our legislation. It could also go back as far as the dispute process sorry the QCAT process and who the repair order is made against in that situation. Absolutely so just looking through there's number of questions have come in which is good. Instead of entry notice to tenants are there any mobile text for tenants legal as notices? No. Under the Electronic Transactions Act texts are not and certainly from the aspect of the 18A which has on the front of it how can you issue your notices or however the parties agree to receive notices post or email are the options there. So what else? How do we deal with broken letterboxes which are constantly being vandalised? Well I agree we have to give them a letterbox do I really have to put a new one in every two weeks? That can be a tricky one because generally the tenant's not the one that's going to be responsible for the damage to the letterbox but you might need to look as to whether there's an option to put it in a different spot or build a big solid brick one. Yeah and again we can't make obviously comments on individual situations but bottom line is obviously it's been vandalised it's a police issue as well and maybe talking to like it wouldn't be just one letterbox I'm assuming it's multiple letterboxes about what's actually happening in that particular area of the situation. There's a question here Lynn this year contractors are very busy in Queensland and we have sort of touched on that issue a little bit. The timeframe is out of control can a manager waive the liability if the repair takes so long and the tenant lodges any complaint breach notice or a form 13 to the manager? I think. Well there's no waving any liabilities I don't think really I think that's probably out of the equation so you're saying that. Yeah and I was just going to say I think this question has come up a lot around the difficulty in getting tradespeople we are aware of the issues. The communication is your key here. What we're finding through the contact centre and the calls that are coming into the contact centre is the tenants are well aware and are generally happy to work with the agents in those circumstances or the owners as long as they're communicated with and they know what's going on. As far as the liability yeah we can't really comment too much on that but certainly we can recommend and what we know is communication is really a key. Yeah another one before we finish I know I'm conscious of the time I can see that there's a lot of questions in there that we are not going to necessarily get to. So if we don't get to your question today again feel free to either reach out to our call centre or potentially there will be another lot of resources being released over the next few days and weeks that will be available also on our website. Yeah sorry in relation to that as Lynn just mentioned if she wants to flick the page over. Sorry that's all right so there will be a lot of information you can see the links there on the on the screen you can follow us on LinkedIn as well as access our podcasts and webinars now this webinar will go up hopefully by Friday so you'll be able to go back and have another listen along with the other that we've done in this series so yeah we'd encourage you to jump onto our website and and check it all out but at this point I will thank Lynn for your time today and for the information that you've presented as a part of this series. Thank you Mark and as I said remember there is a copy of the webinar and our others will be up on our website shortly so at this stage thanks very much for coming along today and we'll see you hopefully in our fourth webinar of the series which will be the final one. Cheers.


Hello everyone, welcome back to another Adobe Photoshop 2020 tutorial. In this one I'm going to show you how to make people look shorter or taller either by themselves or in this situation compared to each other. We're going to be using a new feature called the Quilt Warp Tool and it's friggin amazing and I found a pretty cool way to make this happen. So just work with me on this let's roll. All right the first step here is I've added in a picture of these two newlyweds and they're pretty close in height but in this one I'm going to increase the height of the man and then I'm going to decrease the height of the woman or maybe I'll increase the height of the woman and do gears to short of the man though the height of the man it doesn't matter we're just looking at the technique. So first step we've got an image loaded up the second step is I am going to double click on it and this way it becomes a layer that's not a locked layer and you'll see here that we've got the bounding box around it and we can begin work. Now to do this correctly you want to go up to edits you want to go down to transform and then you want to select warp. Now you'll see here that we've got this cool warp thing going on but what we want to do is a custom warp and right here it allows us to split the warp vertically and we're going to do this and watch what happens when I click it you're going to see that when I hover over I now have the ability to warp on any vertically on any components so I'm going to stick this right on the guy here right in the middle just like that. Now I'm going to go up here and do this again again this is split the warp vertically click it and then I'm going to put it in the middle here of this lady now I can't remember if I was going to make the lady taller and the guy shorter or vice versa let's make her taller. Now watch how this works now we've got these two split warp verticals now you'll see here that there's a little a little point here that we can click on and I'm going to gently nudge this up and very subtly because I don't want this to make it look like anything weird happened and maybe I'll move this down a little bit so it's nice and subtle and then for this guy here I'm going to click on his I'm going to remove I'm going to just push him down a little and let's push this down a little here make it nice and subtle I don't want any weird action going on here and then you're going to see here that in literally like 30 seconds when I click out we've made these people the same height pretty much and we did it without any weird action in here so it doesn't look like there's some weird aberrations in here some distortions it looks as natural as it can get they're now practically the same height we did it in seconds guys this this tool this little tool that I showed you here is the way to go the warp quilt warp um add in the vertical lines and then just slightly adjust them and you can adjust the height of all your people piece of cake guys I hope you enjoyed this tutorial I got a lot more stuff coming up and I'll be back soon


I did my undergrad studies at the German University in Cairo, and in an undergrad school basically you have a set of methods that you use. This is the to-go methods whenever you want to tell a story, whenever you want to solve a problem or whatever.  In my studies, so there were like all this different way of approaching, different way of telling, different way of discovering and touching your design ecology and understanding your design ecology in a non-traditional way. And this sort of really helped me break up with my comfort zone. I get my students to production pretty quickly. I don't wait till they are done with all the research and then they find their stories and storyboards and everything look perfect and then say, OK, now it's time for production. If you're finished first with all your research and studies and interviews and surveys, you have all the results all at once and then you sit and start to figure out what would you do next. Sometimes you have ideas and you think you develop ideas but you never get them into production because they are more cops or prototypes early enough. After you're done with your research, you think that this idea is the one that will work and once it gets to production, you see that it just doesn't communicate whatever you want to communicate. So you hit this lock in a way like late in the process. You should hit it much early. All students right now have access to Linda and the reason why Linda is very important is that I think at this stage you have to build up, like students have to build up their self-learning skills in a way. Yes, we're there for them now but they'll eventually graduate and they have to figure out how do they update the knowledge themselves. I know that whatever I told myself I've never forgot and if I forgot it, I know how to look for it again and this is important. I also encourage students to use Behance and Behance works for them as a platform to document their work and they're ready to present whenever they want in class. They just stand there and say this is what we've done, this is what I've done, this is how I proceeded and you can easily see whether they're progressing or not because everything is sort of in a sequence. I would also say tell them how the rule function and let them practice the rule once and then let them break it and then bring them examples from something like edbusters, see how they're just breaking all these rules and let them experience that.


People like McDonald's. I'm going back. In fact, they use downer cows. I don't know if you know what a downer cow I used to work on farms in New Zealand, you know, my first business was the modern farm system is so bad for animals Okay, that milk cow specifically they push them so hard to produce milk the cow just basically Starts it's almost like fainting.