> Container orchestration exists because some of those containers (or the > hosts they may run on) may have a problem.
Containers is just one of multiple solutions to a problem that most people don't grasp. Ask yourself what problems does Kubernetes containers resolve. The problem exists on all of todays computers and it's only going to get worse. The fastest CPU's can get past the 6Ghz speedlimit. Since CPU manufacturers can't get past 6Ghz, they created CPUs that can run concurrent tasks / threads using what they call cores (z16 Max200 has 256 5.5Ghz cores with 200 available to the customer). In theory it's a 1,408Ghz box. If there is only one task / thread, then it can only use 1 core making the other 255 useless making it a 5.5Ghz computer. This problem exists on all multi-core computers regardless of the number of cores but multi-tasking is insignificant on a 4 core PC but a huge problem for an HPE Cray EX235a with 8,730,112 cores. The problem has nothing to do with the OS. There are many solutions to help programmers with multi-tasking (and multi-computer) to better utilize core usage. Kubernetes containers provides a lot of functionality for a multi-computer solution but is it the best solution for a Cray? Maybe Google's Go language using GoRoutines a better solution on a Cray. On Tuesday, July 18, 2023 at 11:57:49 PM PDT, kekronbekron <000002dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > There are a lot of very wise an experienced folks who have quite clearly > stated that conatainers are critical to the future of z/OS. And I don't doubt them, and surely my knowledge is far more limited. What portion of it (containers being critical to zOS's future) is because zOS has to play nice with the rest of the industry vs. zOS containers offering something uniquely powerful? > I don’t have a a problem with that (zOS Operator for Kubernetes etc.). Neither do I, people & companies end up doing what they have resolved to anyway. What makes me sad is that a solution such as this brutally hides all the intelligent things that went into zOS over decades. Unless zOS's python can get *real* hooks into the guts of zOS, the abstraction of using Ansible to use python to issue zOS commands is... convoluted. I don't know how it's acceptable to use 100 lines of YAML and Jinja and whatnot, to parameterize a 10-line JCL. What happened to ISPF skeletons and REXX, and provider abstractions to already existing interfaces? The other part is about messaging. zOS or mainframe are modern enough. Maybe I'm interpreting material wrong, but showcasing Jenkins and 10-year old distributed tech/techniques as modernization... I believe we can do better. - KB ------- Original Message ------- On Wednesday, July 19th, 2023 at 10:37 AM, David Crayford <dcrayf...@gmail.com> wrote: > > On 19 Jul 2023, at 12:44 pm, kekronbekron > > 000002dee3fcae33-dmarc-requ...@listserv.ua.edu wrote: > > > > The "gift" is not containers but container tech... layering. > > Just lifting and shifting distributed tech onto mainframe, with no > > consideration of the extreme complexities is very wasteful. > > Container orchestration exists because some of those containers (or the > > hosts they may run on) may have a problem. > > How likely is that to happen on Z? > > I know there's also the thing about service boundary, isolation etc. but do > > we really need all of that, totally ignoring equivalent patterns that > > already exist in zOS? > > > There are a lot of very wise an experienced folks who have quite clearly > stated that conatainers are critical to the future of z/OS. > > > Yes, zCX lets you treat a container as just another address space. > > But at the added complexity of container-related setup itself that needs to > > happen within/across zCX. > > With native containers being controlled with systemd (which will be > > possible if LSS exists), we needn't touch kubernetes with a 100 foot poll. > > Just because everyone is jumping about K doesn't mean it makes sense as a > > universal solution. > > > > Anyway, there's already a lot of work from IBM indicating that zOS will > > become just another dumb box that's controllable by the kuberlords (not > > using this term in a derogatory manner, just referring to container people, > > usually distributed folks). > > > I don’t have a a problem with that. I recently saw a demo from IBM where they > spun up a z/OS system running on OCP on Linux for Z. IBM has written a large > collection of Ansible modules to do useful things like define a DB2 system, > IMS system gens, CICS stuff etc. I was impressed. We have Ansible where I > work and can stand up development z/OS images on z/VM. Very handy if you > doing systems level programming and don’t want to hose the LPAR you share > with your team. This new stuff was next level. > > > - KB > > > > ------- Original Message ------- > > On Wednesday, July 19th, 2023 at 9:39 AM, David Crayford > > dcrayf...@gmail.com wrote: > > > > > > On 19 Jul 2023, at 9:52 am, kekronbekron > > > > 000002dee3fcae33-dmarc-requ...@listserv.ua.edu wrote: > > > > > > > > Here's a dumb and bold prediction - the guts of RHEL (CoreOS) will be > > > > laid bare within zOS. > > > > > > Nice idea, but I doubt it. > > > > > > > USS becomes LSS. zOS native containers are actually normal containers > > > > that you see in the linux world. > > > > DSFS and zCX end up helping to blur the boundaries between zOS and LSS. > > > > > > Containers on their own are of limited use. You really need clusters and > > > orchestration for it to be useful. We have z/CX Foundation for Red Hat > > > OpenShift which requires 6 zIIPs just to idle. I’m sure it will get there > > > in the end but it’s a dog at the moment. > > > > > > > zOS is not going away. But we could all use a total re-think of zOSMF. > > > > > > > > - KB > > > > > > > > ------- Original Message ------- > > > > On Wednesday, July 19th, 2023 at 6:17 AM, Jon Perryman > > > > jperr...@pacbell.net wrote: > > > > > > > > > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > > > > > Linux). With some changes, DB2, RACF and other z/OS products could > > > > > run in Linux on z16 in one sysplexed Linux image. We know it's > > > > > possible because IBM moved Unix and TCP into z/OS. IBM RHEL said > > > > > closed source would force non-paying customers to buy RHEL licenses > > > > > but this makes no sense. Something else must be in play. > > > > > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > > > > > insights into IBM's decision to close source RHEL. You can skip the > > > > > survey if you don't want to take it and view the survey results > > > > > through this website. Feel free to pass this along. > > > > > I think IBM wants to integrate z/OS products to retain their > > > > > investments and expand their customer base.. > > > > > Why is the z/OS community ignoring IBM RHEL closed source? Are > > > > > software vendors preparing their products for Linux? > > > > > > > > > > ---------------------------------------------------------------------- > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > ---------------------------------------------------------------------- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
