SWAT within containerised (Viya4) environments : Referring to the bin and http K8s services

未关闭
#140 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
15/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
停滞
技术栈
kubernetes, python

调研方向

首先,在 SAS Studio 中从 Python 重现连接尝试,并将列出的 Kubernetes 服务名称和端口 5570 与 Viya 环境中发布的服务进行比较。检查 Kubernetes 服务 DNS 和 NodePort 配置,以确定受支持的主机名,然后确认最终的连接不会要求用户输入内部 IP。

由索引模型根据 Issue 内容生成。

描述

On a Viya 4 environment, I have published the sas-cas-server-default-bin and ..default-http services as NodePorts. A conscious decision has been taken to not deploy them as LoadBalancers in order to reduce entry points and administration overhead.

Accessing a Python editor from within SAS Studio (which is the customer's intended use), I am able to successfully connect to the binary service, through the controller's (internal) IP address - a sequence starting with 10.XX.XX.XX

Services in K8s are commonly accessed through the DNS name of <service_name>.<name_of_name_space>.svc.cluster.local. In this case, however, I am unable to connect through any of the following patterns (including port of 5570).

Within the connection string of

conn=swat.CAS(hostname=, port=, user=, password=)

hostname = any of the following :

sas-cas-server-default-bin.viya.svc.cluster.local
cas-shared-default-bin.viya.svc.cluster.local
sas-cas-server-default-controller.viya.svc.cluster.local

What might be the correct naming convention so that I do not have to have my users explicitly state the IP ?

主要语言
Python
星标
159
派生
66
PR 合并指标
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

sassoftware/python-swat 的其他 Issue

查看 sassoftware/python-swat 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。