 So, yeah, the recording is gone. Hi, everyone. If you're watching this recording, today we have a Google Summer of Code related meeting. One of our project ideas is related to Windows services, specifically YAML configuration support that is in support of verification for configuration files. And we decided to have a dedicated session to have a Q&A and to do a deep dive into the project. We have six people on the call, and they suggest to do quick introductions. I could start if everyone is fine. OK, and then I will just go through the list in the Zoom. My name is Alek Minashev. I am a maintainer of Jink Discord and I am a 17-year-old Windows service worker. Now, right now, I dedicate not that much time for that, unfortunately, but I hope to change it during the JSOC time frame. And over many years, I was maintaining Windows subsystems for Jenkins, even though I was running on my course for something like six years. But right now, I'm back to Windows. And I am happy to study new technologies there. And I'm happy to work with the students and the mentors who are interested in Windows service workers, right? So I'm Mike Cerrioli. I'm an engineer currently working at CloudBees. This is the first time I will hopefully be mentoring a project for JSOC. This project in particular is sort of interesting to me because in a previous lifetime long ago, I had some experience in creating Windows services and Windows service wrappers. I don't have nearly the Jenkins knowledge that Oleg has. But I do have some experience in this particular area. So that's one of the reasons I'm interested in this project. Hello, everybody. My name is Markey. I am in Jenkins or Gatman and one of the maintainers. I'm here just to be an observer. I'm Sumit. I am a potential JSOC student. I'm not sure whether I'll be applying to this project or not. But I guess there is something to be learned everywhere. So I'm a pro and observer. And you already have an application dropped. That is true. I will make it later. I'm really thankful for your reviews. And thanks for doing that. I'm Buddhiviratharanga and I'm finally undergraduate of University of Moro 2. And I'm looking forward to participate Jenkins with this project that I like to learn those core concepts of Windows. So that's why I chose this project. And I proposed my proposal. And I got some valuable feedback from you, Oleg. And I would like to really thank you for those feedbacks. And I think that's all. Yeah, thank you. As I said, there are also two other students. This one, we have ongoing discussions about this project. Unfortunately, they were unable to join this session. But we may meet them in charts. So there might be more students. Next time, would you like to introduce yourself? Maybe not. Yeah, so I'll just do a quick summary. Next time, if you want to join later, just do so. So there was a bunch of recent contributions. Thanks a lot to that. So basically, currently I maintain the project in terms of reviewing pull requests. Well, barely reviewing them. But I'm trying to catch up. But the most recent contributions came from next term. And there is ongoing transition of the project to the new state. So you can see that there are major features delivered, including a complete rework to the new project structure, including features like .NET Core packaging, basically native installer, and other things. And there are more changes to come soon. So thanks a lot for next term for the interest in this project. OK, so I think we could have a quick summary just to get everybody up to speed. Hi, Alex. Hi, yeah. Sorry for the wait comment. No worries. OK, so we basically finished self-introduction. So if you would like to quickly introduce yourself, just do that. Then you could proceed with the details. I could briefly introduce myself. My name is Alexander Grigoryev. I'm still a BST student in Budapest, Hungary. And this is my second attempt to take part in Google Summer of Code. Yes. I have overall knowledge in C-Sharp. I could say with your mentors from my side, we could gain some success with a probable proposal. And I also, yeah, I should mention that I also experienced a software tester and manual testing and a bit of automation testing. And the next summer, if the issues with the current global issues will resolve, I will take part in the already open software conference with a special testing topic. Great. Thanks. Yeah, thank you very much. Thank you, too. OK, let's take a look at the project. So yeah, basically the description is similar to what we had in the previous year. So when Alex was participating, the idea basically was migrated. The idea there is to have a new configuration for more support for Windows Service Rapper and to improve analysis of these configurations. Windows Service Rapper is actually a separate repository. Right now it's hosted in IKK's personal account. So Kosiki is the founder of Jenkins Project. He also created a lot of development tools and system management tools, including Windows Service Rapper. But right now, there are hundreds and thousands of users running different projects thanks to the license, et cetera. Here, what we have right now, this project supports only XML. So if you go to documentation, you can find some documentation about the configuration file. Basically, it's XML. It looks like that. Well, it may be a bit longer because there is a huge number of different options. But this format is quite legacy. So it was created in 2006, 2007 when the project started. At that point, there was no YAML. Basically, there was no JSON at that point. It just started. But the situation in the 2020 is quite different. There are new configuration management formats, which are widely used in the configuration management systems. It's not only about Kubernetes, because they also use declarative definitions. And XML wouldn't be that bad. But right now, the implementation of XML configuration management in JSON has a lot of, sorry, in the Windows Service Rapper, it has a lot of limitations. So for example, there is no pre-flight check of this configuration. How it works right now, we have a configurator class which basically reads the configurations on demand. Just a second, I believe it's settings file now. Default settings. Let me find it. A little bit behind. So basically, there is a number of configuration items you have to provide. And once this configuration is ready, I'm going to find the codeplate. But yeah, because all students have already seen that. So for me, it's just a matter of time finding the codeplate. The problem is these configurations that, yeah, this one. So you can see that there is a lot of code there. But basically, many fields are being created on demand by just processing XML. So you will know about the issue maybe in the process of execution. And it would be great to have some pre-flight validation which would happen on a startup, or maybe even when a developer defines the configuration. And it was a second part of the project. So yeah, we saw a lot of validation and validation tools which would help a Windows service wrapper and Jenkins users to properly configure Windows services. So this was the idea. And I guess all students on the call will have already went through that because we've got proposals from everyone. But if you have questions about the project goals in general, it's probably the best time to discuss them. Any questions? Any comments? Oleg, I wonder, could you explain in more detail what kind of login would be applicable for this kind of project? Is it not enough, or could you comment about this part? Yeah. So login, well, it has quite a history in this project. So when I took over the project in, well, it was 2014 or something like that, there was almost no login in this project. So it was just failing when something was wrong and sometimes without details. I spent some time in order to improve login across Windows service wrapper. So now it uses log for net. So if somebody is familiar with Java UT login, it's basically the same for .NET. And there was some system messages being printed in IKEA events, but still loading subsystem is quite scarce. So some main log countries are meeting and especially configuration processing. Because one of the main problems, as I said here, if something goes wrong, as a user, I would rather expect it to get information on start up. It might be as a log message. But it may happen when a Windows service wrapper needs this configuration. And I can provide you a disaster scenario. For example, there is a configuration for failover. Yeah, failoractions. And let's imagine this configuration gets processed when the trigger process failed. So you read this configuration, and then you discover that this configuration is broken. So you can really do failover for the service, and it just fails. And as you can see, here it will just throw exception. So something will break, but definitely your service won't proceed as expected. So for me, one of the topics for login and for verification is to just provide information about configuration issues on start up. And if you hit any non-standard situations near the execution, it will be also nice to get some special details. Well, for me, it's a secondary target in this project, because if the configuration process and gets reworked, the number of these issues will drop anyway. Does that answer your question? Yes, thank you very much. Yeah, so currently, your login system is basically built around a log for net, though there are some exceptions. So for example, a Windows Service wrapper has its own event logger extension point, because firstly, due to historical reasons, and secondly, it needs to integrate these Windows specific components, like events manager. So in Windows, if you're an administrator, you're going to go to system events and discover everything reported by your services, by your applications. So there is some logic, which basically provides this integration, and this logic hasn't been fully integrated with the log for net. So in some cases, you can see that there are two event logging systems. And yeah, we got some issues with complicated log entries, but by now, they should be mostly cleaned up. OK, I have followed up question about this event login. Does the current implementation has its own application log in Windows event log system? Or there is no such system at the moment? There is such system at the moment. So right now, if I recall correctly, it's still being done by manual implementation, though there are log for net appenders, which write to system event logs. And if I recall correctly, I haven't integrated it. I need to double check it because it was a while ago. But I suspect that we still use a manual creative system. And you can see that there are still some open issues of all different components. So for example, STD or STD out. So since we talk about service wrapper, service wrapper still wraps the service. And right now, we don't have a routine for event logs, which could be manageable by users. So this feature request is basically open. I submitted a pull request a while ago, which would make a log in full configurable with .NET. Yeah, I have never finished it. And it was 2018, not that long ago. So if somebody wants to take a look at the logging system, you can just export the existing code. You can export some pull requests and issues because it's quite a popular topic. And it's a good source for initial contributions. So if you want to try out the code base, you could just take a look at the log in. I was asked to mute my microphone, but I couldn't find this option, fortunately. Sorry for getting information out of the topic. Ah, yeah, found it. So you can check out other bits here. So you can see that there is a lot of open issues. One of the reasons that some strap is needed, there is actually a lot of valid requests, especially feature requests, because this project started as a Jenkins service wrapper, but right now it's being used by many projects, and basically each project may have their own pieces. And obviously there are bug defects, bugs and defects which still needs to be triaged. Okay, any other questions, especially from Sumit or Boudicca, if you have something, don't stay to ask. Yeah, I think I had some questions about that. I was looking kind of, I am allowed to get a comment and I got the answer as to this. And I think that's the end. I didn't think okay, I have to know. Mm-hmm. Yeah, right. So regarding commercial libraries, if you consider doing YAML to class mapping in your projects, so here, as I said, we do manual parsing of XMLs. Well, we get DOM, but we do not really convert DOM to objects automatically. But there are libraries in C-sharp, in Java, which actually do such things, and it's a best practice to use these libraries. If you want to explore, there are several options for .NET, and one thing you need to keep in mind, if you explore this area, that right now the project supports .NET to the zero. So .NET to the zero, it's pretty old version. It, well, basically it existed before Nougat, before real packages in .NET, et cetera, et cetera, and before the library ecosystem evolved. So it may be an uphill battle to include libraries, but if it becomes a blocker, I think right now we are open to just say that we don't support YAML configurations in .NET to the zero. And I've already opened the issue, which basically would say that we deprecated. It's yet to happen, but I think that it's something from the table. But if it becomes a blocker for your project and for your discovery, I think it's not really a blocker. Do you have any specific questions about libraries? Yeah, I found this .NET library. And I spoke the project and it's interesting and I try to pass ML into, I try to be serialized, ML side into the time configuration objects, but it worked for me. Sorry, I didn't hear you well. Okay, again, I had some problems with, you have mentioned in the application that I have to, I'm a listener before decalizing the ML into, the ML project. And I got some suggestions to do with this externalization with the JSON schema. And I suppose that in my application, the worker on the types of these converting ML into JSON and getting the JSON schema externally and compare those JSON schema with the schema that you cannot do. Sort of for me, it's hard to follow what exactly you're asking. So if you could repeat it in the chat, it would be great. Yeah, just open to your proposal for now. If you don't mind, I will put it here. Yeah, so I'll find this in the proposal later. If we work on JSON later, yeah, a lot of us will need to work on audio setups because we recommend having regular meetings, usually once or twice per week to help these students about their projects and having a good connection and good order is really important to make this meeting sufficient. Now what is it happens? Yeah, while you write your question, is there anything else, is there any other questions? And yeah, then we will circle back to this project. I have some... I didn't know something about my wife, I think she has done a lot of stuff. So just in the meantime, I'll pose my question. Actually, I'm just not that familiar with this project in particular, but what's just a question that came up in my mind is that like, am I right with thinking that we want to go towards YAML so that, I mean, is there something specific with Windows configuration validation or like, why is the need for this? So YAML specifically is not needed for Windows. YAML rather becomes a common engine for configuration management tools. So for example, if you use Kubernetes, if you want to provision Windows machines and Kubernetes, then Kubernetes is all about YAML. Pretty much the same for Puppet for other systems and just offering a configuration language which is used in this environment. It's firstly, easier for users. Secondly, they can integrate them. For example, your inter-automatic provisioning, inter-automatic versioning systems, and it becomes much more convenient than just XML. And again, I would be happy with XML as is if it was working right, but I would say that the current definition causes too many issues. Okay, so it's basically so that because a lot of systems are already built to use YAML like Kubernetes validation and easier user design, easier to the user. Yeah, it's easier for users. Sometimes it's easier to configure. So personally, I'm not a big fan of YAML for the record because if I use XML, I can use XSD schema which is really perfect for configuration validation. Unfortunately, YAML has limited options. We just discovered it again this year in Jenkins because we had a project related to Jenkins configuration as code. So maybe you have met Slade Nunes in Chats. So he was working on a Jcast developer tools project, basically verification for YAML configurations in the Jcast plugin. Yeah, again, it's YAML. And there were a lot of issues related to the limitations of JSON schema because YAML itself, it has specification, but it doesn't have any validation tools on its own. So they basically use JSON tools because JSON is convertible to YAML on the vice versa. But still there is a lot of limitations. So we completed these projects, but if you ask me whether I'm happy about what JSON schema offers, no, I'm not. But it's still useful for users of Windows Service wrapper. So I think it would be a great addition to the project. And if you see other opportunities, again, what we post on the Jenkins website is a project idea. It's not the final project proposal. So I believe that if you have any viable project idea for Windows Service wrapper, which would be interesting to the community, it would work even if it has nothing to do with original project idea at all. Sorry, there was just one line you said I just missed it. You said XML was good for, you liked XML because you could do XSD. So XML itself is terrible, but it has XSD. Yeah, XSD, so it's a schema for XML and it has great support by tools. For example, if you use Visual Studio, et cetera, you can develop XML really efficiently. And a development tooling for YAML is behind that. It's behind what we had for XML into 2012, into 2015, when I was actively working with the open enterprise system. And now these tools improved even more. So yeah, it's just a reference for what XML has. And for example, if you want to write the XSD schema for the current Windows Service wrapper XML configuration, it's also available addition to the project. And I believe they're receiving a ticket for that. Just second, yeah, provide XSD schema for YAML configuration files. No, yeah, we had some discussion with next turn about the feasibility and potential obstacles. So yeah, XSD may also not cover all cases because XSD is structured format in Windows Service wrapper. That is a lot of flexibility you get because it doesn't have standard XML parts or standard XSD schema check. So it's basically free form development. But I believe that foundation YAML could be developed. Sorry, not YAML, XSD schema. So if you would like to take a look at that, it's also possible the ticket is there. Yeah, you may see that it was open for quite a while, but I believe that is still relevant. Thank you. Okay, thank you too. So any other questions, comments? Alex, you wanted to ask something? Yeah, I'm just making some notes for myself. Could you please tell me for example, if this service will have a separate log file, is it feature could be nice to have or is it not so interesting in this project, in general? It's already available. So right now when you start Windows Service wrapper, there are three files being created. One is log for the wrapped service, basically for executable view trigger, and two other files for wrapper than itself. And if you take a look at the Jenkins site, you can try, for example, installing Jenkins agents as Windows Service. And you can see how these logs have been created. For example, yeah, there is a component called Windows agent installer. And this component installs agents for Jenkins using Windows Service wrapper and other tools. And you can see how logging system works there. Moreover, there is, I believe that even support plugins in Jenkins, for example, we have support core plugin. So basically it's a plugin which allows to retrieve basic information about the system for diagnostics. So to create support bundles, which users use, for example, some new issues in Jira. And here, if we look for Windows Service wrapper, I believe that, yeah, so there's slave logs. We have all terminology everywhere, unfortunately. But here what you can see that there is some magic which actually fetches service logs from Jenkins master and from Jenkins agents. And they use standard tools provided by Windows Service wrapper. So in Jenkins, we already heavily use a logging system to provide diagnostics for Jenkins users when something goes wrong. So you can check it out. Okay, yeah, I just to clarify, you can, so the logs from slave transfer to the master node and you could see them in one place in general. Yes. Okay, thank you. Yeah, we do a lot of such diagnostics with Jenkins because Jenkins is a distributed system and distributed systems are terrible to troubleshoot if you don't have special tools. So Jenkins basically provides this to the endcom its own. And there is Windows Service wrapper, you can connect a log format, you can stream it to Windows system logs. So if you have properly configured the system environment, it shouldn't be a problem even for standard setups because I mean it's kind of just collect the data from different Windows systems, but it's also possible in the Jenkins site. Smaller bit of side question. I have not seen it. Is a deadline for application still 10 days from today or like 26 or 27? Okay, so what I can answer is that we have this timeline, which is considered as official timeline. So it means that yesterday the application period began. It means that now you can go to the Google website and submit your application or application draft. We had students who started reaching out to us a couple of months ago. So basically this is just time for application and that deadline is much 31st. Again, this year we solved the situation with coronavirus, et cetera. All these dates may change. But we are just JSOC organization so we have no influence with regards to that it's up to the Google OSS team. They decide to change the ability of all students and all members will be notified with the same time. But right now, it's in two weeks the application is closed. Thank you very much. Yeah. Yeah, actually I need some maybe usage information about the current implementation. Like on what operating system, Windows operating system Jenkins solution comes most. Like this is Windows server, the latest Windows server or is it Windows 10s? Yeah, this is actually a very good question and actually I don't have a good answer to you. So this project is held under the umbrella of Power Platform CIC. And so let's just go to the CIC page. And here you can see that we have regular meetings and one of the constant action item on my side is to create a JEP. It's Jenkins Enhancement Proposal for Windows Support Policy by the Jenkins Project. So right now we don't have strict policy defined. What I can tell you that we have users running on Windows 7, still we have users running on Windows server, different versions. We have users still running on Ethereum. We sometimes see a 30-bit Ethereum. Sometimes we see requests about XP. And right now, well, if you can run Jenkins there, then it's supported. But we don't have strict policy and it's something to discuss and defined on the Jenkins side. So we understand that it has to change. But yeah, right now this is the current status quo. So we will have something improved and the inputs from Windows Service Rapper actually really important. Right now we have two major components which impact the compatibility. One is Windows Service Rapper because here you have .NET. So in order to run Windows Service Rapper until next time submitted native images for .NET Core several months ago, it was always only possible with .NET Framework 2.0 or above. So we need this .NET Framework. It was one of the requirements. So for example, on the Windows XP Service Pack 3 was possible at the time. Well, yeah, it may sound like an ancient history for you. But when I started working with Hudson and Jenkins, it was mainstream technology. And another project is Windows Process Management Library which is also a project started by Kiki for Jenkins. And apparently it's also used outside Jenkins. So it's a native code for managing Windows processes and it defines our requirements for Windows API compatibility. So these two projects mainly define which versions of Windows we can support. And yeah, the other requirement for recent patients that you should be able to run Java 8 on an operating system. Though right now it's not a big deal even for Windows XP if you can build the OpenGDK property. So that's the current state. No good answer, but if it becomes a blocker, we can make decisions on this front. So if we need to say that we need to support on the Windows 10 or above for Windows Service whatever version, it's something we could do. Thank you so much. It's quite important. Yeah, and I could also a bit follow up. There is some like small problems with the research because I was going to use one of my university hardware machines, but now it's closed for maintenance. Yeah, global situation. And the question about operating system, it's raised because I'm going to create some VMs and test the current solution and propose, I think it will be improvements. Maybe it will be in my project which probably it will be the existence of no schema but I'm not sure as a moment we will discuss it further. Yeah, so I'm just thinking which operating system I should set up and test. Yeah. Yeah, so my recommendation for development purposes is just take recent versions. So if you have a laptop for Windows 10, okay. If you have a server, just whatever server version currently provided by Microsoft because I guess you have educational license for your department or whatever. So you can start from it and use it as an input. And for all the versions, we can stop test automation. Right now there are things to do there. So you can see if you go to the project that's now we use a fair to run testing and for fair we basically run it on whatever configuration which provides us a recent visual studio. So we do not do specific testing for old platforms. I still have old setups which I can invoke if it's really needed. But testing on all the platforms is also a problem for this project and it's something we could discuss. But it's not a problem which would be fully up for students to be solved. And yeah, you shouldn't install Windows XP just to support all versions of Windows in the Windows service wrapper. Does it make sense? Absolutely, thank you very much. Okay, thank you too. Okay, so anything else for today? We have eight minutes left. Even there is no questions. Again, feel free to reach out to us in code. So we have platform C, we have mailing list. I don't hesitate to ask any questions there. Right now as I identified in the GSOC mailing list the responses may be delayed because mentors as everybody else also affected by the current situation in so many different ways. So, but we are doing our best to provide these students. Actually, there is another question. I just maybe just a quick question which I had which I hadn't researched so much. I like, is it possible at the moment to have a master server on Linux and have slaves on Windows? Yes, it's possible. And it's one of the purposes for Jenkins. So Jenkins is designed to run distributed builds across operating systems. It's very common use keys. Ah, so it's irrelevant. Yeah, okay. Okay, thank you. Yeah, thank you too. Okay, Ben, good luck with your project proposals. If something gets delayed, please ping me. I have for all your project proposals in the list and I guess Alex, you are still going to resubmit your project proposal. Yes, I'm thinking that probably it will be a bit different than the previous year and that's why I'm asking about VMs. I could dig deeply and propose something, some several features which could be implemented on the top of other colleagues, YAML configuration or existing XML configuration. We'll see, maybe we will also initially discuss this. Yeah, that's perfectly fine. And again, what we offer is a project idea. Whatever you want to propose, just think it on. It would be interesting to get your insights and in your key, Alex, since you also want to have a mentor from your university, if I understand correctly, it would be important if you establish a contact between this mentor and Jenkins and JSOC team. Yeah, I just contacted him and I expect to receive some answer within one or two days. We met before in person and he generally says, okay, but we are going to schedule like personal meetings, but it's not possible anymore, at least for two weeks, maybe even more. And so we will find like additional options for the situation, probably. Or alternatively, I will be orphaned. Yeah, let's see. So on the Jenkins-JSOC site, everything happens remote. And yet to be honest, these video calls are rather full-back scenario. So we expect the most of communications happen as in front of us in mailing lists and in chats. During our main project, we will still be using video calls for setting up between mentors and students, but it will be totally up to the teams to define the meeting slots and the cadence of meetings. But yeah, please use, I think, communications as soon as possible. And if you, Alex, could invite your mentors to JSOC, Jenkins-JSOC mailing lists, or if you could just start the thread and CC them, it would be the starting point. Okay, okay. So, did I understand correctly? I could invite him to participate as a official mentor of this project idea as well. So why not? So, I will publish, yeah. I mean, you had this, it was additional deadlines for your team as far as I know. So it's not a big problem, okay? So for mentors, that is not deadline. You have deadline for student applications and we had kind of deadline for project ideas. But basically, mentors can join projects at any time. And during the project selection phase, and then probably we will be actually doing a lot of additional work if we need to find more mentors for teams. Because usually, yeah, this year, we have 25 potential mentors right now. We have a lot of students, but when you start mapping students' mentors to projects, you will discover a lot of gaps. That's why April is quite interesting for assessor communities, but it's our job. So, right now, it's not a problem. You can take it offline and take as much time as you need. Okay, okay, I will discuss this issue. I will follow up about this. Okay, thank you. Thank you very much. Yeah, anything else to discuss today? So thanks everybody. And yeah, let's continue the discussion as in front of us. So if there are any follow-ups needed, so yeah, I assume that the next time we have problems with audio. So again, we can use mainly to discuss anything nothing multi-period. And if you have any ideas for Windows Service Rappers, please feel free to submit them directly on GitHub wishes for the component, because Windows Service Rappers has its own set of watchers who may be interested to comment on the issues. So it will definitely help to get more feedback for your project proposals. The last question. Did you, will you like share this video recording on YouTube or where could I find it in other do? Yeah, so we publish all the recordings on the Jenkins YouTube channel. I will post them later. So it may take me maybe 24 hours to get it published. Okay, I will check GitHub platform and okay, thank you very much. Thank you, Tom. So have a nice week. And yeah, again, tomorrow we have online meetup. So if you're interested, feel free to join, but it's mostly introductory one. So next of yourselves, we will have a next week. Make it really common agenda for us. Okay, bye everyone. Thank you.