Tech Session: Container Operations

Hello. And welcome to today's Tech Session on containerization. Today we will talk about how the containerization project is going. What it looks like right now and what will happen going forward. We will talk a little about questions and answers, experiences, and we will finish with a networking session for those who are interested in that. My name is Daniel Sjölin and I am Lead Software Engineer here at Sitevision. I work with the Sitevision platform and I am truly passionate about developing the platform so that it is relevant today and tomorrow. With me today I have Anders Larsson, who is Senior Product Specialist and works in our support team. He receives many of the questions that come in about containerization and he is deeply committed to making this really good for everyone. This session is being recorded and we will send it to you afterwards. At the end, there will be a networking session for those who have registered for it. So those of you who have registered, just stay after the Q&A and we will run it then. Throughout the session, feel free to ask questions in the chat, because after the presentation we will run a Q&A where we gather your questions and answer as much as we can. Anything we cannot answer now, we will gather and answer afterwards. So, let's get started. The presentation itself is recorded, so we will see you again afterwards for the Q&A. Because it is happening soon. Now we are almost there. A year and a half ago, in January 2025, we released Sitevision as a container application for the first time. Back then it was an early alpha release and, honestly, there was not a great deal that worked well there. But time has passed, we have continued working very hard, and now we can say that we are in a clear and distinct release candidate phase. We have three services: Sitevision Core, Cassandra and Document Converter. And all of these are running fully in our test environments. We test-run, test, follow up and verify. And we can say that in November you will get access to version 2026.10.1, which will be the first version that is production ready for Sitevision as a container application. This version marks the start of something new. A transition period that we have talked about many times. You may have listened to me when I have held webinars, spoken at Sitevisiondagarna. And each time I have stood there talking about this transition period. The time from when Sitevision is ready to be operated in containers until it will no longer be possible to operate in the old way. This period will begin soon. 2026.10.1, that is when we have a production-ready version. And that means you can start operating Sitevision as a container application. Already six months later, 2027.4.1, we will release the final release in the traditional installation formats, RPM and EXE. Previously, I have stood here and said that we will only release security patches during this transition period. But we have listened to what you have said and concluded that it is just as well that we run RPM and EXE all the way. So you will receive full versions throughout this entire transition period. But when the period is over, when we have released the final version, nothing more will come. So you now have a period in which you need to make this transition. In connection with this October version, we will also change the schedule for how we release releases to those of you operating on-prem. You will get the same schedule as we have in Cloud. That means that we will, instead of you receiving four versions per year, release much more often. For most of the year, new releases will come every three weeks. You choose yourselves how often you want to upgrade, which versions you want to join, whether you still want to upgrade only four times per year or whether you want to join every release. My personal opinion is, of course, that it is best to be on the latest version and stay up to date. And today it is September. There are two months left until you get this production release. So what should you do during these two months? Well, partly you can prepare things I have talked about before. Test-run. Test an upgrade, not just once, twice, three times, many times. Make sure this process works. Make sure you have a staging environment where you have imported your production database and test-run the transition to containerization over and over again. I myself would not feel comfortable trying this for the first time on a production database. This work is not very difficult to do, but you need to get it right. In addition, I think you should start planning for upgrades going forward. Once you have made this transition, when you run containerization, new versions will come all the time. Here, I think it is important that you plan to upgrade each service separately. This is a major improvement compared with what you can do today. So, when we release a Cassandra version, then only Cassandra is what you should upgrade. You do not need to shut down Sitevision. Keep all your Sitevision nodes up during that time. Shut down the first Cassandra node, update it and start it. Do the same with the next node and continue like that through the whole cluster. And you need to think in exactly the same way when upgrading Sitevision. Many versions of Sitevision will come, and they will come often. It is a major advantage for you not to shut down Cassandra in connection with this. Now I am upgrading Sitevision and upgrading it separately. And since you are doing this work now, setting your processes, setting your routines now, it is now that you need to plan how to handle the different services separately. Something else you can do is prepare your existing production environment. When you make the transition from the old to the new, you need to make sure that you are on the same version of Sitevision. So you need to make sure to keep your production cluster updated. Make sure to get it up to the latest version of Sitevision. And we at Sitevision, we are passionate about making the product easy to use. It should be easy for editors, for administrators and for you as operators. Now we are making some changes, but we always work hard to make it easy to upgrade. We want it to almost always be possible to upgrade from any Sitevision version to any other Sitevision version. But sometimes we need to introduce something we call landing versions. And that is only so that we can ensure that certain things have happened at the right time. Historically, there have been a few landing versions, and this year there have been two new ones. 2026.04.1 and 2026.08.1. When you upgrade, you need to land on both of these versions. And make sure to do this. Plan to carry out upgrades as quickly as possible so that you are ready when we release Sitevision as a container application. If you are on a very old version of Sitevision, then check My Pages to see which landing versions exist. Follow the instructions there and work your way up, making sure you are on the right version. Ultimately, you need to have installed the same version that you intend to use when you move over to containerization. Whether that is 2026.10.1 this year, or whether it is 2027.01.1 if that is when you move over. Make sure your old database is on the same version as the new one. And what happens going forward? We are making a start now. We are currently doing stabilization work, where we make sure all customers move over to operating in the new way. But after that, after that, we will want to benefit from this. There are many things that open up possibilities when we move over to containerization. Partly that we operate in containers, but also that we have the ability to split the application into several services. We have many major upgrades underway. Java will be upgraded, Cassandra will be upgraded, Tomcat will be upgraded and many, many more. You may notice this in some cases, and in other cases upgrades will happen and you will not notice that they happen. When it comes to Cassandra, we will provide new instructions further ahead on how that should be done. And more than that, we will break out more surrounding services, meaning services. Today, we have Sitevision Core, which is the large service. We have identified a number of things in there that would probably benefit from being in their own service. There is also new functionality coming that fits better in its own service than inside Sitevision Core. Which services they will be, we cannot say yet. But we can say that it will happen. So for your part, it is important to keep in mind that this transition we are making now is not a one-off event. You need to be active. Read release notes, changelogs and see what is happening. Has a new service arrived that we can try? Or has a new service arrived that we must run in order for the application to work? Take that with you. It is not a static change. It is not the case that as soon as you have moved over to containerization, you are completely done. Rather, operating Sitevision is an active role, keeping track of what is happening so that you keep up. And with that, I will hand over to Anders Larsson. Thank you. Thank you, Daniel. As mentioned, the transition to containerization has begun. But it looks different for every customer, which you notice when we in Support are in contact with our customers and partners. As Daniel has already touched on, this is a project for every organization to prepare for. And I will continue talking a little about the preparations. The important thing is not to regard this as a regular migration where you move the application from one environment to another, but rather as a step-by-step transition of the operating model. The important thing is that you have the right expertise, that you have clear responsibilities, functioning working methods and that you handle the different parts correctly. The first thing to do is to map things out, that is, start orienting yourself in this. Where are you today? What requirements do we have, what competencies do we have internally? This is the stage you should already be in. This is the stage you should have been in for a while, because you have been able to prepare. The next step is to move into the test phase and review the preparations, what needs to be done, set up test environments, start testing. This is also a phase where you can start moving production data to another environment, a container-based environment, and see what happens. This is not only important for you, it is important for us too. We may have missed preparing something, and then we will notice it here. And above all, questions are created. A huge number of questions are created internally with you here. What, what have we missed? Why does this not work? How do we move forward? These questions come in to us, and this can help us continue developing the documentation, which is so incredibly important. The migration, there is no production-ready Sitevision version yet, but it is extremely close, as Daniel mentioned, it is not far away. And based on what you have tested and what you have mapped out, you can start preparing your actual production environment for the migration. As mentioned, we are not quite there yet with the actual version of Sitevision, but you can start preparing for the migration. Then you enter the management phase. The migration is complete. You make sure that monitoring works, ensure that operations are working, you have routines in place, monitoring, yes, that whole part, and all of this should already have been prepared during the mapping phase and the test phase, so there should be no question marks when you reach the management phase. You have already fixed all of this. Customers who are on-prem are now essentially facing two choices. Either you decide to operate it yourselves, that you have the capability and the expertise internally to do so, and then you do that. to do so, then you do that. Or you look at another solution with Sitevision Cloud. So when planning your continued journey with Sitevision, as mentioned, there are two operating choices. And which choice suits you best depends on your organization. What competencies do you have? What are we prepared to invest and commit to this in order to build up what we need to operate, continue operating our Sitevision environment. The first option you have is to move to Cloud. You realize: no, we do not have the knowledge we need, and hand over operational responsibility to us here at Sitevision. We then take responsibility for the underlying environment, maintenance, upgrades, while you as a customer can focus on actually using the application and reviewing the organization's needs for the application, what you need. But you hand over all responsibility for the operational parts to us here at Sitevision. The second option, and perhaps what many of you are here for today, is simply to continue on-prem. We want to have this control over our environment. We want to build up a capability, knowledge, and run a container-based platform. As I talked about earlier, that includes monitoring, backup, security, incident management and upgrades. And you have already specified requirements for this internally during this requirements phase, where we list what we need to get this up and running. But if you are unsure about your options, what suits us best? But we need support, we do not have the expertise available. Then we, or I, recommend that you have a very early dialogue, you should already have started there, with your Sitevision partner and explore what they can help with in this project as it stands. You need to do a preliminary study, or can they help with preliminary studies, expertise, assessment, implementation, ongoing operations support. What can they offer you? So start now and talk to your partner. Where do we stand with this? What do we need? What is missing? What do we need to strengthen? What should, what should... What do we need in the organization to get started? So my strong recommendation: talk to your partner. That is the best place to start right here and now. And I also want to recommend Soleil's webinar on 9 September, where they will talk about containerization and containers for Sitevision. For customers who are planning self-managed operations, there is also a self-managed operations channel on My Pages that I recommend. We will gather information there. We can do that together, I should say, we can gather information, experiences, relevant updates and you will also find the link to Soleil's webinar here, which Fredrik so kindly posted. But to you other partners, I also want to... Another recommendation is that you start using the self-managed operations channel. Link to webinars you have, set up webinars, link them there, get people engaged, or if you have some other type of knowledge-raising initiative, use our self-managed operations group. That does not only help you, it also helps us and our customers. And you get clicks too, so to speak. That is great. And you customers, you can also take part, not just partners, you can join in too. Ask questions. If you have got stuck on something, ask a question. Or why not, if you have had a challenge that you have overcome? Write about it, write a short post, oh, we got past this challenge, we solved it in this way. Then perhaps there are one or two other customers sitting in exactly the same phase who have not managed to solve it, but you help them move on to the next part of the project. So do not be afraid to write. Better one post too many than one too few, just to create some engagement. We have been in contact with all our on-prem customers. We have talked to 100 percent of our on-prem customers about containerization and talked a little about their plans going forward. And that includes people who are CS contacts, and also at development level, we have talked about this. So everyone has received the information. And we see two very equally sized choices. 36 percent have chosen to move to Cloud, while 35 percent plan to operate it themselves. So that means that 71 percent have now chosen a path forward, a main direction for where they are going. This is important to us, we need to be able to support all customers, those who do not want to operate it themselves and those who want to operate it themselves. So this is very important for us in order to build up capability within containerization. The remaining 29 percent have not quite made a decision. For that group, the next step is to understand the two options and what they provide and what responsibility you take on, and which com... Competencies are required for each path. There is not long left until April next year, when we stop distributing RPMs, EXE files. So this is a critical time to start choosing the path that feels right for you. You do not want to be too late to the game and end up in the orientation phase next summer. Because by then we will have stopped distributing it. We in Support, or my support colleague Mattias and I, have handled more than 70 cases. When this is shown, there may be more, there probably will be more. So that is a figure showing that there is a need for guidance, documentation and knowledge transfer, and there again comes My Pages and the self-managed operations channel. A perfect place for knowledge transfer between customers and partners, to have a dialogue. We at Sitevision CS are also there reading. It is great for us to get your impressions. The transition to this container-based operation also brings changes when it comes to the local development environment. It will be a little different when you start it. Personally, I think it is much easier now. It takes two minutes to get started. But I want you partners who have not started to test it. Start testing, develop locally, test our step-by-step guide. The guide is very simple. Try creating WebApps and just deploying WebApps, even if you have large, advanced ones, but you know, you might find a bug that we have not thought of. So it is really good if you get started with using our container development environment with Docker. What do you need to get started? Well, My Pages. You need access to My Pages, and you have that. There we have the complete documentation, we have the Compose file and information about current releases. Parts of the documentation are of course also available on the Developer website, but the complete documentation can be found on My Pages, and it is also up to date. The next step is that you need access to our images, and you get that via our image registry Arty. And that is where Docker, at least, fetches the Sitevision and Cassandra images that are needed for the environment to get started. So to be able to create this account, you need to be a partner or have authorization as an operations administrator. Operations administrators are primarily used by those of you who are responsible for operations in your organization and need access to Arty to get hold of our images to install in your environments. If you lack authorization, if you know that, well, I am an operations administrator. I do not have access to Arty, I cannot see how to create an account. Do this, contact your internal CS representative, so yes, check internally first of all so that they can help you move forward. Because it may be that you need an account, or it may be that you just lack authorization. Back to the developers. Now we return live. Follow the Docker guide on My Pages. The prerequisites are that you have Docker Desktop installed, that you can start it and that it is started, and that you have some basic knowledge of Docker commands. Check our guide. It helps you through the whole flow: logging in to Arty, downloading the Compose file, creating volumes for data and finally just starting the environment. Very simple, as I said, it will take you two minutes to get started. After that, you have a working Sitevision and Cassandra environment up and running that you can use for development and testing. And there is also information about how to update or keep the environment continuously updated so that you can always take the latest release. And since we are also changing to every three weeks, that is great. Really fun. For organizations that need to manage perhaps more users, there is also support for automatically creating Arty accounts via API. You will find that documentation together with the module that creates Arty accounts on My Pages. So go to that page, and there will be a guide on how to do it and which roles you need in order to get access. If you, as partners, have not got started and tested, I will say it once: I recommend that you get started and test our container solution too. Do everything you can with it because... It helps us too. If you find something, that helps us help you. So that is a dialogue we can have back and forth. Great, so get started. A developer license is still required, we are still talking about Sitevision, nothing has changed regarding licences. You still need a developer licence in order to develop, otherwise you can only start Sitevision and have very limited access to what you can reach. Finally, we want to highlight three areas that recur in our dialogue with customers and partners. Documentation, training and security-related questions. If we start with the documentation, it has been updated and we keep it continuously updated to adapt it for the container-based solution. At the same time, it is important, or I want to be clear about what the purpose of the documentation actually is. It should describe Sitevision, how it should be installed and configured in a container environment. It is not intended to be a basic training course in Docker, Kubernetes or containerization in general. There, you need to take responsibility for obtaining the knowledge you need. So to use the documentation, you need to have basic knowledge of the container platform you have chosen. Because there we... We find it difficult to... We cannot create a guide for every possible path, there are too many and it is... I do not think, I do not think you want us to sit and just document all day. I think you want us to move the product forward. As mentioned, if that competence is missing with you, build it up internally through training, talk to your partner, back to that. Perhaps together you can find a good foundation to stand on together. As mentioned, we are working on the documentation all the time based on the stage we are in, as well as the feedback we receive. Right now, we are getting many questions about upgrades and restoration and things like that, and we are working on the documentation. It will be clarified, but it is also important that you get back to us and keep bouncing things back to us. When there is something you think, I do not understand this, this is missing, then we can review it, is this something that should be included, and if it should, then we can spend time making it clearer for you to get started. Training, when it comes to training, the idea is that we have roughly the same limitation as with the documentation. We are not planning, we are not planning any general basic training in operations and container platforms. And if we were to create a training initiative, it would primarily be about Sitevision and how Sitevision works in a container environment and what you should know about installation, upgrades and management. But we will not create a training course that takes the whole concept of container platforms and tries to teach it, it becomes too broad. But at present, there is nothing on the table regarding training, but it is good for you to know, at least. The documentation is the source for now. The third question, a very important question, security-related, CVEs. We are noticing now that we are getting more and more questions in this area, and the reason is also that container images are much easier today to vulnerability scan. Which makes it clearer when there are dependencies and potential vulnerabilities. They also become very clearly visible to you. But a finding in a scan does not automatically mean that the vulnerability can be exploited by anyone in the current environment you are running in, or rather, you need to make many other assessments around it. What components are involved? What versions are they? How are they used in Sitevision, how is it exposed? And then we need to investigate what measures are required if we have a CVE linked to a component. But we always take that kind of thing very seriously, and you can count on that: if a critical CVE comes up, we look at it. We also have an ongoing project around how, going forward, we should assess or handle and communicate information for relevant CVEs. We do not have all parts in place, but our ambition is still to be able to share more information about the working method at a later date. And that is about informing you about CVEs so that you can feel secure with Sitevision and how we handle security-related issues. So, now we can start looking at whether any interesting questions have come in for us to answer for you. Yes, thank you for that, Anders. And now we are back live. A few questions have come in and it is absolutely fine to continue writing questions. And I thought I would take these questions that have appeared. The first question that came in was about probes for Cassandra. Whether they will be able to become as good as they are in Sitevision. I read this question and feel that I can interpret it in two ways, so I think I will take both ways and answer both. Either the question is asked because someone wants an HTTP endpoint, just like in Sitevision. And that specific thing will not be relevant. It will not open an HTTP server in the Cassandra service. Instead it... The only entry points there are the CQL protocol and JMX. So that will not come. But it could also be that we are actually wondering whether you can get these three common probes that are usually used in Kubernetes. And for Cassandra, it is not as easy to find what distinguishes these three. We can continue to look again at whether there is any reason to distinguish them. But today there is a shell script inside inside the container that you can call to perform your probe. And then you handle it in roughly the same way regardless of whether it is startup, liveness or readiness. It becomes the same thing. Either Cassandra responds, or it does not. And if it does not respond, then there may be reason to restart it. So that was the first question. The second one that came in was about... And now I need to see, right, what is upgraded first. Here too, there are two different ways to look at it. Either it is the transition from the old to the new, from container... Or from RPM/EXE to containerization. Or the question may refer to when you have already moved over and you are doing these regular upgrades. And we will take that case first. That is, that you are upgraded, you are running containerization, and new versions of Sitevision or Cassandra arrive. And in that case, I would say it does not matter which one you take first. The Cassandra we release today we package as a major one. And as long as we remain within major one, it does not matter which one you upgrade first. Because we make sure to keep the APIs between them safe. So it does not matter. The important thing, or important, a major advantage is if you do not run both at once. Both systems will be better off if you take Cassandra first and then Sitevision, or vice versa, first Sitevision and then Cassandra. So that only one of them is working on an upgrade at a time. I would say that is an advantage there. Going forward, we will make larger upgrades of Cassandra, and then the order will of course be important when we increase the major version of our service. There, we will come back with exact instructions on how such an upgrade should be done. Because we will move up many versions and it will be a special procedure. But we will inform you about that well in advance, and there is nothing special you need to prepare right now. What you need to make sure to prepare right now is rather being able to upgrade your services separately so that you do not have the same lifecycle for them. But this question can also be seen as being about the transition from RPM/EXE to containerization. And there it is a little harder to give an exact answer. Because it depends on how you do it, in which environment and what prerequisites you have. Some will simply upgrade on the same machines. Do a rolling upgrade. You shut down your RPM installation and then start the new one. Strictly speaking, Sitevision needs Cassandra to get started. But the Sitevision process is smart enough that it stands and waits if Cassandra is not up. So you can start both at the same time in this case. Cassandra will do its work to reconnect to the cluster again and be the node that it was before it was shut down. And as soon as it is ready, Sitevision can move on and do its work. And here you follow the upgrade guides that we have documented. I can imagine that we will soon review them as well, to make sure they are current and that they are easy to follow. So that does not really matter much either, which one you take first. If you do a completely different type of operation instead of upgrading the cluster on the same machines. Perhaps you move from your native Linux machines and move into a Kubernetes cluster instead. Then you follow a different flow, and then it is not a rolling upgrade. Then the same applies there, that you need to follow the guide and see which order to do things in. I hope that was a good answer to that question. Then there are some questions about simplifying deploys and things like that. Then we will look at the first one, when will you be able to deploy Sitevision with a licence so you do not have to go into the interface? This is something we want to do. It is something we have chosen not to include in the containerization project. Instead, we have placed ourselves at a level where we change the packaging and change how Sitevision starts. But we have not included all these improvements that we see we want to make that relate inside the Sitevision product. So at present, and when it becomes production ready, the same procedure applies: you need to go into the interface and upload this licence. But once we have this in place, this is one of the things I see that we want to improve. We want to make it easier to get copies and environments up, or deploy a new environment without having to go in and click so much in the interface. Preferably not at all, but we will see how far we get there. But that is our ambition at least, that... That is the direction we want to move in. To improve and simplify this. So when? I will not be able to give a version for when it is ready, but it is the kind of thing we will look at once we have containerization in production. A question has also come in about session replication. That is also something many people are asking for. The user's session is bound to a single node, and if it is shut down, you are logged out. And this works the same way as it does today in Sitevision in RPM and EXE. That too is one of these things that we see we want to solve. It is not something we have included in this project, in this transition. So it will not come right now. But it is also the kind of thing we will look at once we have this in production operation, because that is a very much-requested feature. Both for you and for us. More questions are coming in. Now let's see, are there any plans to gather questions and answers that have come to Support in the self-managed operations channel? I do not think we have any plan to publish specifically in the self-managed operations channel, but we do have Anders Larsson and his team sitting and going through all these questions that come in. Looking for patterns, seeing what common questions are coming in. And this is posted in the FAQ on My Pages, so we handle questions and answers there. So if you have not been in and read the FAQ, do so. Let's see. Now many questions are coming in. Let's see how I can look at them now. If we have Sitevision and Cassandra on the same cluster, how can we handle that in the best way? Separate worker nodes for SV and Cassandra. Here it sounds like it is Kubernetes or OpenShift. I myself do not have full control over Kubernetes specifically, but we have some internal test environments for Kubernetes, but nothing that we operate ourselves on. There are some examples of how to get started, and I know that there are actually many of you on-prem customers who are already up and running and running Sitevision and Cassandra in this way. So this is a question that I think fits very well on the self- managed operations page. Ask the question there, collaborate with other customers who operate in Kubernetes or OpenShift to get experiences there and see what what is best. If there is a more specific breakdown of that question, you can send it to Support. But I think the best thing here is to collaborate with other customers operating on Kubernetes/OpenShift and who have already thought already thought about this. There will also be an opportunity to ask this type of question in the networking session that will take place soon. And then there are questions, will you release installation and upgrade packages for both Kubernetes and OpenShift? Or have you chosen a primary operating platform for on-prem operation? No, I have not chosen a primary operating platform. We have chosen to package our images as OCI-compatible. But a reference example is Docker Compose. There is no requirement to run Docker Compose. There is no requirement to run Podman or Kubernetes or OpenShift or whatever you choose. Instead, we choose to package our product in a way so that it will work in all of these different ones. But then it is up to the person operating it to be an expert on their own container platform. It will be unsustainable for us to provide exactly this is how you should operate in your environment. So we have chosen to take that approach, that approach, to avoid making a hard choice for customers. We think it is better that you as customers can actually choose for yourselves what suits you best. If you have an organization that is very skilled in OpenShift, there is no reason for us to force in Docker or Podman. And conversely, if there are customers who operate everything in Compose, there is no reason for us to force in Helm charts/Kubernetes. So we release reference examples and then you translate that yourselves into your own environment. Here comes an interesting question, is it possible to run Sitevision in a Kubernetes cluster but continue running Cassandra outside that environment on a Linux server with Docker and Podman? And this was something that was absolutely not possible when we released our alpha versions or beta versions. But it is possible now, and it is actually a very interesting way to operate. This is very interesting. If you put Cassandra in its own cluster outside Kubernetes, you have good opportunities to optimize it as much as possible. At the same time, you use scaling functions and such for Sitevision. So that is fully possible. We have requirements, technical requirements for access between the services. All Sitevision nodes must be able to contact all Cassandra nodes. But that does not mean that Cassandra needs to be publicly exposed to the internet. We do not think so, instead only Sitevision should have access. So all Sitevision nodes must be able to contact all Cassandra nodes on the ports that can be read in the README file provided. I even think we have a separate page in the documentation on My Pages that describes which network requirements exist between them. So, yes, it is fully possible to run it that way. In the same way as if you have... If you choose Docker or Podman, there is nothing saying that Sitevision and Cassandra must run on the same machine. You can put Cassandra on another machine in its own Docker cluster or Podman cluster. You can mix as much as you like here, as long as you get it working well and Sitevision can contact Cassandra. Good. Then I think we will round off this Q&A. There is still an opportunity to send in more questions. As long as this chat is open, just continue asking questions. If you have more questions afterwards, just contact Support. Support is our primary contact channel here, and we follow up all questions that come in. Those of you who will take part in the networking session now, you will leave this meeting. Then follow the meeting link that you have received in your invitation. And we will see each other there. To the rest of you who have been with us so far, I just want to say thank you for today. I hope you have received useful information here, answers to some questions, and that you are interested in the webinars that our partners will be holding. So thank you for that. And those of you in the networking session, see you soon.