All Posts By

cblum

Sujay Solomon: I am a Mainframer

By | Blog, I Am A Mainframer

In our latest “ I am a Mainframer” interview series, Steven Dickens, WW Sales Leader – LinuxONE at IBM, chats with Sujay Solomon. Sujay has been in the Mainframe industry for 8 years. With an array of experience in technical leadership roles such as z/OS system software development, web development and product management roles, he is now leading CA’s initiative to modernize the Mainframe for developers. Steven and  Sunjay discuss the business processes and business that the Mainframe platform is supporting, Zowe and the future of the Mainframe.

If you’re a Mainframe enthusiast or interested in the space, we invite you to check out our new community forum.

Steven Dickens: Good day. I’m Steven Dickens and it’s my pleasure to host another edition of the I’m a Mainframer conversation series, sponsored by the Open Mainframe Project. As a Linux Foundation project, the Open Mainframe Project is intended to help create a Mainframe-focused open source technical community focused around collaborative engagement on the Mainframe platform. I’m joined today by Sujay Solomon from CA. Thanks for joining us, Sujay.

Sujay Solomon: Thank you, Steven. Happy to be here.

Steven Dickens: Sujay, this is all about why you’re a Mainframer. If you can just get our listeners a little bit orientated and tell us a little bit about yourself and give us some background. And really first off try and understand what makes you a Mainframer and what makes you so passionate about the platform.

Sujay Solomon: Sure. I am, I’m actually a Product Manager now, so I haven’t been writing code for a little while. But what attracted me to the platform was I went to Penn State for computer engineering. And that degree is interesting. It’s somewhat of a marriage between computer science and electrical engineering. You do a little bit of hardware and you do a little bit of software. And it kind of meets in the middle.

Because of that background from Penn State I was interested always in doing and working on things that powered the back end of things. The engine, if you wish. And I, right out of college I actually worked for a start-up where I was designing and building code for microcontrollers. And it just happened to be that that was being done in Assembly language, believe it or not.

And then I saw an opening in Penn State’s career website that said there’s a position for a software engineer at CA Technologies in Pittsburgh. It might involve a decent bit of Assembler for that programing and I said, “You know, I like what I’m doing now.” I didn’t really know about Mainframes but I just went out and Googled Mainframe a little bit. And then I found out that there’s all these very important technologies and businesses today that run with the Mainframe as their backbone. From what I had heard about Mainframes in the past, from movies and such, was that they need to be hacked because they’re very important. Until I did some bit of research I didn’t know what they actually did.

But then again I considered it, I looked at it and I mean it was a very stable platform that had been around for a very long time. I said, “Why not? Let’s go and interview for this. I’ve had my year of fun with start-ups, let’s go and look for something that’s more long term.” That’s how I got started with the Mainframe platform.

Steven Dickens: You started out as an Assembler programmer and that’s what drew you into the platform, is that a good summary?

Sujay Solomon: Yeah, absolutely. It’s the fact that when you’re developing code at that level you need a very clear and good understanding of how the system works at an operating system level. And maybe even at the hardware level. But you still have to have your fundamentals of writing software and developing code in a good place as well. I liked that aspect of it where I wasn’t writing a whole lot of high level, abstracted code and I was doing more coding that was very close to the operating system and the hardware. That’s absolutely what attracted me.

Steven Dickens: Keen to get a view underneath that a little bit. I mean, you obviously learnt Assembler, you came out of college, got into that start-up, were writing that code close to the hardware layer. Tell me a little bit more about that transition as you went from that world to the Mainframe world. Was it an easy transition for you to make? I think a lot of our listeners would be interested to understand how you made that transition.

Sujay Solomon: Yeah. My response here is usually a little bit different from what I’ve heard from others. I actually didn’t have much of an issue. It’s, Mainframe is just another computer. And the architecture that’s followed in the Mainframe platform is well defined and actually one of the common architecture that’s followed even in other platforms. To me, learning about how a computer works at its core was very key at Penn State. And their curriculum was such that they didn’t focus much on specific languages or specific technologies. It was more so concepts that drive how computing works.

And that really helped me when I joined CA and we were doing a lot of development and operating systems level things. And it was really enjoyable for me because it was really the concept that I was learning. And then actually putting them to work from what I learned in college was way more interesting to me than what language I was writing the code in.

The transition for me was fairly easy. Especially when it comes to the language. I had no issue with picking up high level Assembler as opposed to writing in the microcontroller Assembly language I was using previously. I did do quite a bit of C-programming as well. Along with Assembler on the Mainframe. And again, both are languages that I really enjoy writing in.

The concepts in Mainframe when it comes to, say, things like cross-memory posting, managing your virtual storage, topics like that, they were challenging but it was also very, very interesting. That’s what drew me in and kept me here is the technical complexity of the platform when it comes to writing very efficient code. And you having full understanding of what you’re writing and how the machine’s gonna actually interpret that and run that for you.

Steven Dickens: I’m just, as I was prepping for this Sujay, was looking at your profile on LinkedIn and looking at the eight years or so you’ve been at CA. Pretty stellar rise through the ranks there from a software engineer through to your current role. Can you just give these listeners a view of what you’ve been involved in, some of those interesting projects. And really a whistle-stop tour through your time at CA. I think the listeners will find that really interesting.

Sujay Solomon:  Sure. Just to go back to your previous question, you asked if moving to the and working in a Mainframe platform was challenging. The technology itself wasn’t really challenging but the expectations in the Mainframe world were quite challenging. I was maybe two weeks into my job and I worked on a performance management product which was quite key at CA. And they had me look into an issue that the customer had opened. And I worked it out, I came up with a fix and I wrote a PTF which you can consider a patch and another technology, right?

And I released that not as a public thing, but as a closed off fix for just one customer. And I get a call directly from one of the Directors of Mainframe in that company and he’s drilling me over intricate details of the fix that I wrote. I certainly did not expect that. But trial by fire like that really put me in a place to understand how important this platform is for people. And the fact that somebody that high up in their organization was technically proficient and looked at a fix and was concerned and then he called me up directly to ask questions about how it was implemented … That opened my eyes as far as how important this platform is.

And going forward I work on other products that even plug directly into the operating system. And if you’re, say, opening up a data set on the Mainframe and somebody else is opening it up at the same time there’s serialization issues that can occur. I actually worked on quite a bit of operating system exits that would handle serialization issues like that.

One of the times we, a large bank in Europe was having some issues with ATMs. And they didn’t really know what the issue was but they essentially said, “Hey, CA. We have your software. IBM we are using your platform. You guys work together to sort this out. We don’t care what the problem is but we need our ATMs to be back and running right away.” That involved being on bridge calls with the customer, with other vendors for many days straight. Across weekends, even nights and then we all worked together to solve this issue because this was a customer who was really dependent on the Mainframe. And as vendors who create software and hardware for the platform we all work together to solve issues like that.

That sort of experience was rewarding for me. It’s solving real world problems that touch people lives every day. It’s just working on the software that runs it.

Steven Dickens: Yeah, and I think that’s obviously a challenge we’ve got as we position the Mainframe out to different audiences. It’s, as you mentioned in one of your statements, the box at the back end. It’s not front and center for a lot of our clients. It’s the box that never falls over at the back of the data center that just runs the business. I mean, have you seen that as you’ve engaged? That critical, sorry, criticality to clients? And if you could maybe give a CA perspective on some of the business processes and business that this platform’s supporting, that’d be interesting, I think.

Sujay Solomon:  Sure. Again, before I got into product management I was engineer. I was working, I was supporting products as a level 2 engineer, but also actively doing development on it. One of the things that I had to do was I was actually on call over, at night and on weekends. So if I was going hiking in the mountains I still had to make sure that I had phone signal and I usually lugged my laptop around in case I got called. And then it has happened. I’ve been at friends’ places at 3 o’clock in the morning and I’ve had to attend calls where they said, “Hey. We’re having a data center outage and we run your software. Again, we don’t know what the issue is, please look into it.”

And you just have to get on that call and get to it because as minutes go by with their Mainframes not working, they’re losing maybe thousands, hundreds of thousands or maybe even millions of dollars in business. With just a few minutes of the Mainframe not operating. That’s the level of importance that the industry has on the Mainframe platform.

And CA absolutely has so much process in place. We have rotations of folks who are gonna be on call. And multiple layers, even, or a certain person who’s maybe in Support gonna get called first. And then if they’re not able to solve it they have multiple levels of escalation and everybody’s number is on file and they can get called at any time. That’s part and parcel of working in an environment and an industry like this where you’re really key when it comes to continuing the business operations. And to me that’s actually rewarding. I don’t see that as a burden. I see that more as, hey, the key businesses in this world rely on our technology being highly available. And we are the people who help make it highly available if it ever runs into issue. That’s very rewarding.

Steven Dickens:  Yeah, I think that’s just part of being in this Mainframe space. There’s a different code, if you will, around what it means to be a Mainframer and what it means to support these clients. It’s good to get that perspective and I think it’s interesting to hear you say, and I certainly feel this way, is we’re supporting these clients. That’s a good thing. You feel like you’re giving something back and there’s … The world runs on these platforms so to be involved in them is a positive thing.

Looking ahead Sujay, there’s some interesting stuff going on right now as we look at the Mainframers and overall platforms. Some fantastic announcements at SHARE recently. Can you just give me your view of where you think open source and the Mainframe platform come together? And really how you see that shaping not only the platform but just how customers are gonna interact with it going forward?

Sujay Solomon: Sure. One of the challenges that we’ve had over the past decade with the platform is since it’s closed source, folks have been able to improve the accessibility of our platform to the level that some of the other platforms have achieved. And that’s starting to become an issue because when you look at, just take for example DevOps tools. Things like, I think they use integration tools like Jenkins or build tools like Gradle, Gulp, Ant, Maven. These are now becoming synonymous with software development. Not necessarily tied to any platform.

You could build software that runs on Windows or Linux or maybe even different distributions of Linux. All of the software that runs on those different platforms can be built using the same build tools, can be managed using the same  pipelines. The fact that it’s a little bit of a challenge to integrate Mainframe into those standard tools that are becoming prominent in the software industry, that is a problem.

And I believe with the initiative that we announced at SHARE called Zowe, our intent is to really, not necessarily solve that entire problem. But kickstart an openness to the platform. And start building some infrastructure that would allow the community of users and customers and individual developers to really start building integration into these open tools that are available. And are becoming very popular with developers in general.

But sometimes I say that we’re trying to make Mainframe just another platform. But obviously we’re not trying to reduce the scalability, availability, security or any of those great aspects of the platform that we have. Just add to it by making it more accessible.

Steven Dickens: Yeah, that’s interesting. I think open source brings a lot to that. I mean, what’s your view on how that community’s gonna build around something like Zowe? Sounds like a strong focus on the technology but if you give me the community perspective, what do you think that community engagement’s gonna bring to a network like Zowe?

Sujay Solomon: Sure. Up until now if you wanted to influence what happens on the platform, there were a few avenues. There is a, within the SHARE organization they have something called SHARE requirements. And then that was one way to influence what goes into the platform. But now with the power of open source, it’s a home for anybody who is interacting with a platform to really start looking at it and saying, “Hey. I’ve got this program that I wrote, this  program I wrote that helps me greatly every day with maybe looking at system on the Mainframe.”

I don’t particularly see this as a business advantage for me, just keeping it to myself. And I don’t even want to maintain all of it myself. Maybe I’ll just up in the open source foundations, GitHub, and a lot of others might start using it. And they may even start enhancing this utility that you shared yourself. And you might reap the rewards of you open sourcing it because others are enhancing it and you’re now able to take advantage of what other folks are building in their tool that you shared.

That is really what we want to build and promote and nurture. Is build that community around the platform where folks feel comfortable sharing their tools, sharing their ideas so that the platform as a whole can grow. Without having to go through a lot of process and influencing say just a couple of vendors and improving it.

Steven Dickens:  Yeah. And I think I certainly get the perspective that that kind of crowd-sourced community development is where the industry’s going. We’ve certainly seen that explosive growth of the model for how code is developed. And it’s really interesting for me to see that increasingly coming to the Mainframe platform. As you say, not moving away from the performance availability, security, but adding to the platform. And just making it not only able to play nice with others as part of a DevOps type framework. But also just harness the community, harness that crowd to develop on the platform.

One of the questions I’m gonna ask and get you ready mentally for this Sujay, so this one’s gonna challenge you. Where do you see things 18 months, three years, five years out for the Mainframe platforms? You look ahead and into that crystal ball, where do you see the platform going?

Sujay Solomon: Well, seems like things have come full circle. When I was in college, mid-2000s and maybe even before that, there was a lot of talk that Mainframes are going away. We’re gonna try to migrate everything to the cloud. That sort of thing. But what I’ve noticed recently is actually kind of a reinvigoration of interest and commitment to the platform from a lot of companies. Because they seem to have realized that there’s quite a few aspects to the Mainframe that are, that really cannot be replaced by anything else.

There’s also a lot of investment that has gone into the platform. There’s, I mean, think about the 30, 40 plus years of business logic that’s been written and enhanced and refined over these years. Why rewrite that? Why move that somewhere else if you can make what’s on the Mainframe highly accessible and open? So that you’re not inhibited by the platform when it comes to innovation. That’s key, is that we need to be able to drive innovation on the platform. It can’t just be a platform that is kept maintained well. It’s gotta be a place for innovation. And I believe that that’s starting to happen.

Today I think folks at larger organizations are just accepting and realizing that the platform is not going away. And they’re starting to reinvest in it. I’ve even heard that some of them are even moving non-traditional workloads. Things like Java workload or an OJS workload from other cloud platforms into the Mainframe platform. I think next year, or maybe a couple of years from now, we’re gonna see more of that. Where maybe there’s an application that’s running somewhere in the cloud that’s not meeting SOA. And the data that that application interacts with is actually on the Mainframe.

Those types of applications, if we make it simple enough for, say, a web developer to deploy a web application to the Mainframe. The same way that they can use something like a COI to deploy to another cloud platform. As long as we make it as simple and as accessible I believe Mainframe is now gonna start taking a spot when it comes to enterprise architecture where they consider different deployment platforms. Mainframe needs to be considered as one of the options there and I believe that is starting to happen.

Steven Dickens:  Yeah, I think we share a lot of the same views, Sujay. I think I see an exciting future ahead. And some of the work that you guys are doing around Zowe and the open source collaborative piece is only just gonna help that.

One final question as we look to wrap up our time today. The format of this is I’m a Mainframer. What would you say to yourself back as you were leaving college, if you could do that, around the platform? How would you energize the college kids graduating this year to get into the platform and follow your path and become a Mainframer?

Sujay Solomon: That’s actually a tough one. I really liked what Penn State did for me. They did not teach me a hell of a lot about specific languages or specific platforms. I learned concepts. Just normal programming concepts, computing concepts, hardware concepts. And I was able to take those concepts and I picked a platform that I thought was viable and long standing and that had an important place in today’s businesses. And for me there’s really nothing better than Mainframe data when it comes to longevity and stability and importance in the real world.

I wouldn’t get too caught up with the different languages. They come and go. If you look at UI frameworks there’s flavor of the year, sometimes even flavor of the month, frameworks that come and go. I would focus more on, if you’re learning the infrastructure of a platform, the skills all transfer over. I’ve myself gone from doing heavy duty Mainframe system level Assembler fee development. I’ve done some JavaScript and Java web development. The transition between the two really wasn’t bad for me.

That would be my advice, then, to keep your options open. Look at the platform and try to understand why it really is, plays such a key role in today’s economy and in various industries. And the skills you learn there are transferable to any other platform if you ever get bored and you wanna move around like I did. Options are always there for you.

Steven Dickens: That’s fantastic. I think that’s really good coaching. I think the Sujay of 22 years old would have appreciated that type of insight. Thank you for that.

Sujay, this has been fantastic today. Really good to get your perspective, really good to get a view of where you’ve grown as a Mainframer. Your initial experience at the platform. Your perspective of where we are right now with some of the things that are happening. And just that looking ahead and that view 18 months, three years out of where the platform’s gonna be. Thank you very much for your time today.

Sujay Solomon: Thank you, Steven.

Steven Dickens:  This is Steven Dickens signing off. You’ve been listening to the Open Mainframe Project I’m a Mainframer podcast. Please look forward, please look for us and join us next time.

 

Alpine Linux 3.8 announced with support for z/VM and KVM on s390x

By | Blog

Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox. Adding support for 64-bit IBM z Systems (s390x) was one of the first Open Mainframe Project Internship Program projects from the class in summer 2016. Tuan Hoang, now a graduate student at Marist College, did the initial work during the internship period and continued his work over the following months, concluding with the release of Alpine Linux 3.6 last spring. Alpine Linux is one of the open source projects that is part of our supported projects program, which helps open source projects with the needed infrastructure and resources to support mainframe architecture in their projects.

With the latest Alpine Linux v3.8 release, support for ISO image installs on s390x has been added. The enables the use of KVM in addition to z/VM for provisioning and management of Linux instances. For more details click on this check out the full announcement on the Alpine Linux site.

Other new features for Alpine Linux 3.8 and noteworthy new packages include:

  • Support netboot on all architectures
  • Add arm64 (aarch64) Raspberry Pi image
  • Add support for Raspberry Pi 3 Model B+
  • Support ISO image on s390x (KVM installation)
  • End of support for hardened kernel (unofficial Grsecurity)
  • Support for Crystal language
  • Significant package updates
    • Linux 4.14
    • Go 1.10
    • Node.js 8.11 (LTS)
    • Rust 1.26
    • Ruby 2.5
    • PHP 7.2
    • ghc 8.4
    • OCaml 4.06
    • R 3.5
    • JRuby 9.2

You can learn more about the work Tuan has done on this port during his session in August at Open Source Summit North America 2018 in Vancouver entitled Bringing a New Linux Distro to the Mainframe – Story of How Alpine Linux was Ported to s390x – Tuan Hoang, Marist College

Open Mainframe Service Broker Project

By | Blog

The Open Mainframe Foundation sponsored a Virginia Commonwealth University (VCU) Capstone Senior Design project to build a Service Broker using Docker on the Linux One Community Cloud. The project was made up of three VCU students, Jacob Roberts, Kevin Richmond, and Justin Gardner and mentored by Leonard Santalucia (Project Sponsor) and Robert Dahlberg (VCU faculty advisor.) It was a two semesters project spanning over 9 months (August 2017 to May 2018.)  The final result was a functional proof of concept capable of launching and managing micro services using Docker containers.

A continuous integration framework is key to doing agile development.  Without the ability to dynamically add or modify application services, Agile development is just a project management concept.  Service Oriented Architecture is a software development methodology where application services are broken down into small parts (micro services) which an application communicates with through a service broker to perform general functions. This project containerizes these micro services using Docker, an application can call these micro services managed by the Docker service broker.. The interface to the Docker service broker was created in a web application with both an administrative and standard user interface, allowing an application to call services and an administrator to launch, remove, and manage Docker-ized micro services.

The Docker service broker enables administrators to create an environment of Docker micro services, and to organize them into groups.  These Docker-ized micro services can be started as a group for use by an application (or applications).  The groups of Docker micro services can be started as multiple instances, for instance as a production, QA or multiple development environments.  Each instance of a Docker micro service can be dynamically updated with a new or replacement micro service by adding a new micro service Docker container to the group or group instance or deleting an old micro service Docker container and replacing it with a new one.

There are 3 components to the project: (1) The front end, which includes both the administrative panel and the standard user panel, (2) the API, which controls interactions with the database, and (3) the worker, which launches and performs actions on the Docker containers.

The front end allows the administrator to view and manage micro services and groups through the Docker service broker.  The administrator can view which service broker environments are running and the status of each micro service, including which port is the service is communicating.  It is a Vue.js application with segmented parts for administration vs standard user interfaces. The application displays some great features of Vue.js like components and a reactive UI. The functionality is provided to the back end through a REST JSON API which is implemented via the use of the axios library.

The API translates service broker calls on behalf of the administrator(s) and applications requesting micro services (i.e. worker containers).  It processes configuration definitions and service calls to the service broker and micro services.  The API is built on Node.js and also makes use of the axios library for parsing and simplifying JSON API interactions. The API manages interactions with the database for both the worker and the front end. When a service is launched, for example, an entry is placed on a queue in the database with the state “initializing.” The worker then claims that entry and performs the required activity.

Finally, the worker simply queries the API for any services in the “initializing” state and then performs the desired action on the local system accordingly. The worker (micro service) performs the specific function requested by the application through the service broker.  The worker was designed to allow a server that implements the Docker instances to be different from the server running the API or the front end.

You can find the Github repo here: https://github.com/openmainframeproject/docker-service-broker

What’s it like to be a Summer Intern at the Open Mainframe Project?

By | Blog

Check out my Summer 2017 Wrap Up!

I am Amit, from Gorakhpur, India a final year Computer Science undergraduate from UIET CSJM University working in Open Source technologies since 2015. I want to share my experience of working as a summer intern at the Open Mainframe Project.

The Open Mainframe Project summer internship program is an integrated experience that brings together students from different background and around the world to work remotely with some awesome developers on a wide range of projects and initiatives related to the mainframe, blockchain, cloud computing and data science. Over the last 2 years, more than 15 interns have joined the Open Mainframe Project Internship Program to conduct projects across multiple ideas, gain exposure to new areas for exploration and study, expand networks, and then present their work at open source conferences around the world. This 10-week intensive paid experience for students from a wide range of backgrounds and areas of interest, ranging from undergraduate to PhD level, is one of the main ways the foundation demonstrates its commitments to Open Source, diversity, and network-building. The length of time and intensity of the experience allows interns to form lasting bonds with each other and with the Open Mainframe Project.

What exactly is the Open Mainframe Project?

The Open Mainframe Project or OMP, is a project hosted by the Linux Foundation that allows students to work remotely. The summer internship program offers student developers stipends to write code for various open source software projects that target the mainframe, letting students engage with technologies such as cloud computing, blockchain and data science. On successful completion of their project, every Open Mainframe Project intern has a chance to present their project work at Open Source Software Conference and a stipend of $6000. Oh yes, a gift (presumably of high value) is also provided on successful completion.

Prerequisites for getting through.

Knowledge: One has to have sound knowledge of the field. The mentors are currently working on the latest technology, so we can’t bluff having knowledge.

Open Source Experience: Having open source source experience is one of the key points in getting selected. One needs to be a student through the Open Mainframe Project selection period, which is announced (mid April), so I was eligible for the Open Mainframe Project since I was still in school.

Internship Experience

What I have really enjoyed this summer is the openness of the other developers to share their knowledge and experiences during weekly CloudStack for z/VM meeting. Ji Chen is one of the most awesome (really really) and helpful mentors. Emily Hugenburch and John Mertic are the most helpful and noble people on earth I can say! They are very humble and down to earth and offered support in every way they could. Each mentor and intern here has a technical background, and it was quite a good experience throughout the internship tenure. Everyone here is so open and eager to learn from each other, and that is truly a huge win for everyone. My project was to define the benchmarks and criteria for what cloud on z/VM looks like which help understand how the mapping of commands between OpenStack and z/VM works to enable better solutions. Apart from this, my project involves thorough study of OpenStack functions in the hypervisor matrix and also got a chance to interview few OpenStack customers from MITRE, LinuxOne Community, NCAT and ADP to understand how these customers employ OpenStack functions in their daily operation and about their expectations over these functions to be an end user or administrator function. The work isn’t a piece of cake, but most people, with decent efforts, can deliver what mentors expect. It’s necessary to stick to the schedule decided mutually when submitting the proposal. Thanks to Herbert Daly who interviewed me for Open Mainframe Internship program. There is a community bonding period (where Intern and mentor get to know each other as well as about the Internship program and review the Project objectives/goals) followed by mid-term and end-term evaluations. Mentors evaluate your work with weekly reports followed by monthly and final reports, to make sure work is progressing towards the project goal. Even the best and most friendly mentor will fail you if you don’t live up to their expectations. We have weekly Go To Meetings, apart from project progress we elaborately discuss about project on the Open Mainframe Project Slack Channel.

Being open source, the doors didn’t close for me after my project was finished. I might not have as much time, but I really hope that I’ll be able to keep a modicum of involvement with this amazing organization in the future.

Technical Insight

I had a chance to interview a few OpenStack customers during the Open Mainframe Project Internship as my project also involved collecting information about OpenStack functions in the hypervisor matrix. Some of the questions I asked during the interview are given below:

  1. What are the daily operations in your work?
  2. What support matrix features you need like create, delete, start, stop, migrate, actions, monitor and healthy checks etc?
  3. What are the important functions (to be an end user or administrator function)?

It gave me an immense learning experience to interview OpenStack customers.  For example, some customers rely on their own monitoring function and work with other toolchain providers who address the support matrix features more or less. Other customers are using a customized version of the z/VM platform which uses their own actions (for performing some specific tasks) like Manage Expirations which deals with managed Linux lifecycle, Manage Quotas which deals with the CPU and more options like showing consoles and logs. I also got to know  how other OpenStack/zVM developers are employing OpenStack functions for their own specific tasks and how they are actually making an impact to the community.

Clearly this isn’t the end for CloudStack on z/VM. As for any other IAAS provider, it’s going to grow and there is much more work is left to do. As a developer this project allowed me to explore OpenStack functions in different hypervisors. If you’re interested in contributing to OpenStack, take a look at a related OpenStack gerrit issue, instance live resize. For the initial iteration, it would be restricted to live resize on the same host and with existing flavors, i.e. you can’t pass random values like CPU/RAM/Disk for the resize. You can also look for additional requirements (actions which are not available in OpenStack) from other IAAS providers like Rackspace, VMWare, AWS etc.

How exactly is remote internship different from the usual internships?

I can work anytime, anywhere! It’s completely up to me, I enjoy the flexibility. Of course the initial period is tough. Coming home after a tiring semester (in my case a nostalgic good bye to college-life), one would prefer to lay around and kill time watching TV series, visiting places, or hangout with friends. So it’s tough to concentrate and work with dedication from home. However, in a span of 15 days, all was set and I was up to speed and managed to recoup lost time.

All in all, I had great fun and will continue contributing even more. This is just the beginning!

Interested in joining the Summer Intern Open Mainframe Project? Learn more here.

Follow the Open Mainframe Project on Twitter @openmfproject for the latest interviews, or subscribe to our quarterly newsletter at https://t.co/Cq8V52lOeU.

Blog post by: Amit Kumar Jaiswal, CTO, Quanonblocks LLP. Amit is an open hacktivist and a recent summer student with Open Mainframe Linux Foundation Intern. Community is everything that matter to him, loves to give talks and sessions varying from Programming stuffs to Community Ideas.

He is a recent Computer Science graduate from UIET CSJM University, Kanpur, India and passionate about Data Science, Cloud Computing and Cryptocurrency.