jiebi/CodeConvo huggingface dataset:
Change:
This says 0.6+, which isn't really right, since 0.6+ indicates commits on top of the latest tag. But that isn't the case here. We are exactly on the latest tag...

Discussion:
# Try to match the "git describe" output to a regex to try to extract # the "major" and "minor" versions and whether this is the exact tagged # version or whether the tree is between two tagged versions. <del> if [[ "${KUBE_GIT_VERSION}" =~ ^v([0-9]+).([0-9]+)([.-].*)?$ ]]; then </del> <ins> if [[ "${KUBE_GIT_VERSION}" =~ ^v([0-9]+).([0-9]+)(.[0-9]+)?([-].*)?$ ]]; then </ins> KUBE_GIT_MAJOR=${BASH_REMATCH[1]} KUBE_GIT_MINOR=${BASH_REMATCH[2]} <del> if [[ -n "${BASH_REMATCH[3]}" ]]; then </del> <ins> if [[ -n "${BASH_REMATCH[4]}" ]]; then </ins> KUBE_GIT_MINOR+="+" fi fi
Change:
According to this page: "PortalIP is usually assigned by the master. If specified by the user // we will try to respect it or else fail the request. This field can // not be changed by updates." PortalIP string to clarify the above - it means that user is allowed to assign it during creation of service, but not during update service - correct? why update is not supported as well? are the considerations for "we will try to respect it" - what validations are made (Except for addr already in use) ? exact error is returned when it can't be assigned?
1) We did not support update because it is a bit more complicated, but mostly because the semantic we want around services is that the IP never changes. 2) We ensure that the IP is within the "portal net" CIDR and not used already. 3) I am 99% sure it returns an HTTP 422 error , abonas wrote:
is there anywhere (or at least planned) the documentation of various errors returned from REST api? I mean beyond the standard 404, 500, etc. For instance - for duplicate entities, validation errors on entity content, things like the above. Is there a distinction between wrong json (which should always fail) and the above which is more of a runtime error? I know some apis (not kubernetes) will actually return 400 in this case and not 422, so declaration of errors will be a great help for consumers of REST api. (one can always experiment, test and register all those errors, but consider how time consuming that can be)
We do plan to document and test (and, in some cases, fix) status code behavior: .
Brian - you 1.0 milestone to this issue, but I'm not sure what is the action item here. Can you please explain what should be done?
The action here is/was to verify the behavior and ensure it is documented correctly. Thanks to we now have general status code behavior documented: It doesn't say what happens in this specific case, though I don't know that it's possible to document every specific case, at least not in a way that's kept up to date. I can confirm that 422 is returned in this case: It would be useful to document that users/clients can specify PortalIP in the services doc:
I'll take the update to and then close this.

Discussion:
can then aim traffic at the `Service` port on that `Node` and it will be proxied to the backends. <ins> ## Choosing your own PortalIP address A user can specify their own ```PortalIP``` address as part of a service creation request.  For example, if they already have an existing DNS entry that they wish to replace, or legacy systems that are configured for a specific IP address and difficult to re-configure.  The ```PortalIP``` address that a user chooses must be a valid IP address and within the portal net CIDR range that is specified by flag to the API server.  If the PortalIP value is invalid, the apiserver returns a ```422``` HTTP status code to indicate that the value is invalid. </ins> ## Shortcomings We expect that using iptables and userspace proxies for portals will work at
Change:
When starting locally a cluster from source by running hack/local-up-, kubecfg and kubectl require gcloud in order to work. It doesn't make sense to depend on gcloud when running a cluster from source locally in a dev env, hence please provide instructions to make kubectl/kubecfg work locally without gcloud in this local setup.
Doesn't make sense for vagrant either
Have you read getting started guide? In section. I think it's recently :)
I think the issue is that kube up local / vagrant shouldn't require gcloud at all ----- Original Message -----
It shouldn't. I suspect that it is that defaults to gce. I'm going to take a run through the experience/guides and make sure this is clear and there is no gcloud required.
I had done some work on making a real cluster provider for local, but didn't merge it, since it didn't look like it would be sufficient to make e2e work. However, if it would make it easier to run locally, I could check it in. It's weird that the local setup lives in hack.
I think it'd be great to have a real provider for local, but I'm not sure it is a super high pri. I'm going to clarify the local script a little to close out this. -- let us know if doesn't fix it for you and we will investigate further.

Discussion:
--master="http://${API_HOST}:${API_PORT}" >"${SCHEDULER_LOG}" 2>&1 & SCHEDULER_PID=$! <del> echo "Local Kubernetes cluster is running. Press Ctrl-C to shut it down." echo "Logs: " echo "  ${APISERVER_LOG}" echo "  ${CTLRMGR_LOG}" echo "  ${KUBELET_LOG}" echo "  ${PROXY_LOG}" echo "  ${SCHEDULER_LOG}" </del> <ins> cat <<EOF Local Kubernetes cluster is running. Press Ctrl-C to shut it down. Logs: ${APISERVER_LOG} ${CTLRMGR_LOG} ${KUBELET_LOG} ${PROXY_LOG} ${SCHEDULER_LOG} To start using your cluster, open up another terminal/tab and run: export KUBERNETES_PROVIDER=local cluster/kubectl.sh EOF </ins> cleanup() {
Change:
More often than not kube-up will loop forever for cluster initialization. I eventually realized it was because the script was looping forever on "https://|/api/v1beta1/pods". This happens any time Rackspace doesn't very quickly assign an IP address to the master. PR incoming with pretty rudimentary looping on the code that does the IP address lookup.

Discussion:
detect-master() { KUBE_MASTER=${MASTER_NAME} <ins> echo "Waiting for ${MASTER_NAME} IP Address." echo echo "  This will continually check to see if the master node has an IP address." echo </ins> KUBE_MASTER_IP=$(nova show $KUBE_MASTER --minimal | grep accessIPv4 | awk '{print $4}') <ins> while [ "${KUBE_MASTER_IP-|}" == "|" ]; do KUBE_MASTER_IP=$(nova show $KUBE_MASTER --minimal | grep accessIPv4 | awk '{print $4}') printf "." sleep 2 done echo "${KUBE_MASTER} IP Address is ${KUBE_MASTER_IP}" </ins> } # $1 should be the network you would like to get an IP address for
Change:
I get this from salt. I would fix it, but looks like this commit reversed what I would have done: Not sure why.
Darn it -- those guys said they tested it. I'll fix this up.
cc: -- FYI
Bah... was an attempt to fix this issue for a different case. I'll look at it again.
I'm running a couple of e2e tests on a fix now.
please reopen if still broken.

Discussion:
DOCKER_OPTS="" <del> {% if grains.docker_opts %} </del> <ins> {% if grains.docker_opts is defined and grains.docker_opts %} </ins> DOCKER_OPTS="${DOCKER_OPTS} {{grains.docker_opts}}" {% endif %} DOCKER_OPTS="${DOCKER_OPTS} --bridge cbr0 --iptables=false --ip-masq=false -r=false"
Change:
When you generate your second cluster, suddenly you'll find that nothing works from browsers. The ca/cert pairs we make reuse serial numbers. Firefox says: Chrome just refuses to show anything, which made this hard to debug. We generate the ca & cert here: Action items: Every CA we make should be unique, even within the same (e.g.) GCE project/ip address. Every cert we make should have a unique serial number. easyrsa docs don't make it immediately obvious how to accomplish this.
running build-ca in --batch mode wipes out the existing pki, which restarts the indexing at 0 if the ca already exists, shouldn't we just skip build-ca?
I will happily merge a PR with that change! I only understand this stuff well enough to figure out what's wrong... ;)
Actually--if that is a/the problem, then running kube- should bork my cluster, no? But actually it does seem to work. So I suspect that the problem is deeper than that, like we generate the same ca deterministically (or some important component thereof) when kube- runs? Like all of the browsers on my desktop now completely refuse to talk to any kubernetes master because of this.
Ah, it looks like we end up with this in all certs: ... I think we want to add a arg to the call to uniquify the certificate authority each time it's generated
That sounds like it's probably the problem. Thanks!
fixes this.

Discussion:
cd easy-rsa-master/easyrsa3 ./easyrsa init-pki > /dev/null 2>&1 <del> ./easyrsa --batch build-ca nopass > /dev/null 2>&1 </del> <ins> ./easyrsa --batch "--req-cn=$cert_ip@`date +%s`" build-ca nopass > /dev/null 2>&1 </ins> if [ $use_cn = "true" ]; then ./easyrsa build-server-full $cert_ip nopass > /dev/null 2>&1 cp -p pki/issued/$cert_ip.crt "${cert_dir}/server.cert" > /dev/null 2>&1
Change:
I1218 02:32:15. 2704 ] GET /stats?numstats=9: (42.94us) 301 goroutine 74 [running]: (respLogger).WriteHeader(0xc2081a58c0, 0x12d) +0x9c net/http.Redirect(0x7f9f2806ecd0, 0xc2081a58c0, 0xc2083da1a0, 0xc208240520, 0x7, 0x12d) +0x473 net/http.(redirectHandler).ServeHTTP(0xc208116660, 0x7f9f2806ecd0, 0xc2081a58c0, 0xc2083da1a0) +0x5e net/http.(ServeMux).ServeHTTP(0xc2080ff560, 0x7f9f2806ecd0, 0xc2081a58c0, 0xc2083da1a0) +0x1a3 (Server).ServeHTTP(0xc208116620, 0x7f9f2806ec98, 0xc2081ba140, 0xc2083da1a0) +0x117 net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f9f2806ec98, 0xc2081ba140, 0xc2083da1a0) +0x19f net/http.(conn).serve(0xc208120e80) +0xa7e created by net/http.(_Server).Serve +0x313

Discussion:
defer httplog.NewLogged(req, &w).StacktraceWhen( httplog.StatusIsNot( http.StatusOK, <ins> http.StatusMovedPermanently, http.StatusTemporaryRedirect, </ins> http.StatusNotFound, ), ).Log()
Change:
sending the following json to update a service: "{"apiVersion":"v1beta1","port":6380,"containerPort":6379}" fails with 422 and message: "service "" is invalid: name: required value ''" It's not clear from the message what is exactly the problem. is the "name" field missing? isn't it called "id" at the moment? if yes, another issue () points on the fact that including the id fails the request with another error.
similar issue happens when creating a service: input (based on the guestbook example) : POST fails with :
Internal names are not converted to external during rendering of the status message. Name is the newer api version field name for what used to be called id
but the input json contains "id", so why does it fail in the first place?
I'm referring to the first comment, where update failed because you omitted the ID of the service you were updating
Update requires the full resource to be specified. GET the resource, modify the fields you want to change, and do a PUT.
Using for the field name conversion problem.
As mentioned, PUT should not accept partial updates - PATCH should, and the issue for that is . This is documented in : "Otherwise, PUT expects the whole object to be specified." Where else does it need to be documented?

Discussion:
The PUT and POST verbs on objects will ignore the "status" values. Otherwise, PUT expects the whole object to be specified. Therefore, if a field is omitted it is assumed that the client wants to clear that field's value. <del> Modification of just part of an object may be achieved by GETting the resource, modifying part of the spec, labels, or annotations, and then PUTting it back. See [concurrency control](#concurrency-control-and-consistency), below, regarding read-modify-write consistency when using this pattern. Some objects may expose alternative resource representations that allow mutation of the status, or performing custom actions on the object. </del> <ins> The PUT verb does not accept partial updates. Modification of just part of an object may be achieved by GETting the resource, modifying part of the spec, labels, or annotations, and then PUTting it back. See [concurrency control](#concurrency-control-and-consistency), below, regarding read-modify-write consistency when using this pattern. Some objects may expose alternative resource representations that allow mutation of the status, or performing custom actions on the object. </ins> All objects that represent a physical resource whose state may vary from the user's desired intent SHOULD have a "spec" and a "status".  Objects whose state cannot vary from the user's desired intent MAY have only "spec", and MAY rename "spec" to a more appropriate name.

case "PUT": // Update a resource. route := ws.PUT(action.Path).To(UpdateResource(updater, ctxFn, action.Namer, codec, resource, admit)). Filter(m). <del> Doc("update the specified " + kind). Operation("update" + kind). </del> <ins> Doc("replace the specified " + kind). Operation("replace" + kind). </ins> Reads(versionedObject) addParams(route, action.Params) ws.Route(route)
Change:
During a PD testing, I created a pod, and found it has a trouble to be started for a half hour, but events show it properly started: $ get pods Running: cluster/../cluster/gce/../../output/dockerized/bin/linux/amd64/kubectl get pods POD CONTAINER(S) IMAGE(S) HOST LABELS STATUS testpd testpd kubernetes/pause kubernetes-minion- <nonePending $ get events | grep testpd Running: cluster/../cluster/gce/../../output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 The issue might be missing some key events or events are misleading. Looking into it.

Discussion:
err := kl.syncPod(pod, dockerContainers) if err != nil { glog.Errorf("Error syncing pod, skipping: %v", err) <ins> record.Eventf(pod, "", "failedSync", "Error syncing pod, skipping: %v", err) </ins> } }) }
Change:
The build has been failing for the last several days because of this:
Do you have an opinion on this one? checkin basically introduced a dep on a random ass file in contrib, making the default for basiclally every provider out there to pull this file and turn on DNS. I actually agree with it, but I'm more inclined to take the file and put it somewhere else that's not contrib anymore, since , by its name, says "we aren't officially supporting it", and shouldn't really be pulling from unsupported places. I looked at it briefly this morning, and the solutions to this broke down to: Move the file somewhere else: ( toplevel somewhere somewhere?) Ship some subset of Ship snapshots of
I'm going to move the file under
We do similar stuff for monitoring. But that stuff happens to be in which we do package. Ug.
should all of the contrib/dns dir move there, then? , Joe Beda wrote:
-- yes. I'm moving and to . At some point we can make those addons be more generic so that you can just drop something in there and there are helper scripts to launch it into a cluster. Testing it now.

Discussion:
<ins> #!/bin/bash # Copyright 2015 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # This script will build a kubernetes.tar.gz and # kubernetes-test.tar.gz, unpack them in a separate directory and try # to run e2es from there, as if it were a binary distribution separate # from the git tree. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. # Build a release echo echo "... building release" echo "${KUBE_ROOT}/build/release.sh" echo echo "... ensuring git e2e cluster is down" echo go run "${KUBE_ROOT}/hack/e2e.go" -v -down TEST_DEPLOY="${KUBE_ROOT}/_output/test-deploy" echo echo "... deploying kubernetes.tar.gz / kubernetes-test.tar.gz to ${TEST_DEPLOY}" echo rm -rf ${TEST_DEPLOY} mkdir -p ${TEST_DEPLOY} tar -C "${TEST_DEPLOY}" -xzf _output/release-tars/kubernetes.tar.gz tar -C "${TEST_DEPLOY}" -xzf _output/release-tars/kubernetes-test.tar.gz # Nothing past here should touch the git checkout. unset KUBE_ROOT cd "${TEST_DEPLOY}/kubernetes" echo echo "... running e2e tests from ${TEST_DEPLOY}" echo go run ./hack/e2e.go -v -up -test -down "$*" || ( status=$? echo echo "... e2e tests failed from ${TEST_DEPLOY}! To reproduce this command:" echo "...   (cd '${TEST_DEPLOY}/kubernetes' && go run ./hack/e2e.go -v -up -test -down" "$*" ")" echo exit ${status}) exit 0 </ins>
Change:
The node disk type should be an option in the cluster/gce/config-*.sh files. The nodes get created here:
And also the disk size.
How to do this for aws ? I am stuck at 10GB minion
It . A pull request adding it would be very welcome!
please check this thread
Hello there, can I do something to make this available in the command ? I'd like to us an SSD drive :)

Discussion:
MASTER_SIZE=n1-standard-1 MINION_SIZE=n1-standard-1 NUM_MINIONS=${NUM_MINIONS:-4} <ins> MINION_DISK_TYPE=pd-standard MINION_DISK_SIZE=10GB </ins> # TODO(dchen1107): Filed an internal issue to create an alias # for containervm image, so that gcloud will expand this # to the latest supported image.

MASTER_SIZE=g1-small MINION_SIZE=g1-small NUM_MINIONS=${NUM_MINIONS:-2} <ins> MINION_DISK_TYPE=pd-standard MINION_DISK_SIZE=10GB </ins> # TODO(dchen1107): Filed an internal issue to create an alias # for containervm image, so that gcloud will expand this # to the latest supported image.

# $1: The name of the instance. # $2: The scopes flag. # $3: The minion start script. <del> function create-instance { </del> <ins> function create-minion { </ins> detect-project local attempt=0 while true; do

--project "${PROJECT}"  --zone "${ZONE}"  --machine-type "${MINION_SIZE}"  <ins> --boot-disk-type "${MINION_DISK_TYPE}"  --boot-disk-size "${MINION_DISK_SIZE}"  </ins> --image-project="${IMAGE_PROJECT}"  --image "${IMAGE}"  --tags "${MINION_TAG}" 

) > "${KUBE_TEMP}/minion-start-${i}.sh" local scopes_flag="${scope_flags[@]}" <del> create-instance "${MINION_NAMES[$i]}" "${scopes_flag}" "startup-script=${KUBE_TEMP}/minion-start-${i}.sh" & </del> <ins> create-minion "${MINION_NAMES[$i]}" "${scopes_flag}" "startup-script=${KUBE_TEMP}/minion-start-${i}.sh" & </ins> if [ $i -ne 0 ] && [ $((i%5)) -eq 0 ]; then echo Waiting for creation of a batch of instances at $i...
Change:
Or for some other reason it complains about v1beta1 and 2 on my system even though actually grepping those files shows no problems.
it's griping about Host

Discussion:
// TODO: provide exact specification for format. Source string `json:"source,omitempty" description:"component reporting this event; short machine understandable string"` // Host name on which the event is generated. <del> Host string `json:"host,omitempty"` </del> <ins> Host string `json:"host,omitempty" description:"host name on which this event was generated"` </ins> // The time at which the client recorded the event. (Time of server receipt is in TypeMeta.) Timestamp util.Time `json:"timestamp,omitempty" description:"time at which the client recorded the event"`

Source string `json:"source,omitempty" description:"component reporting this event; short machine understandable string"` // Host name on which the event is generated. <del> Host string `json:"host,omitempty"` </del> <ins> Host string `json:"host,omitempty" description:"host name on which this event was generated"` </ins> // The time at which the client recorded the event. (Time of server receipt is in TypeMeta.) Timestamp util.Time `json:"timestamp,omitempty" description:"time at which the client recorded the event"`
Change:
From IRC ... Currently kubectl get pod <idonly list Host IP on which the pod bounds to, there is no PodIP information. The only way for the user to know PodIP is run the same command with "-o json" flag. This is confusion to the user. cc
Already working on a PR for this.
Yay.

Discussion:
if len(containers) > 0 { firstContainer, containers = containers[0], containers[1:] } <del> _, err := fmt.Fprintf(w, "%st%st%st%st%st%sn", </del> <ins> _, err := fmt.Fprintf(w, "%s/%st%st%st%st%st%sn", </ins> pod.Name, <ins> pod.Status.PodIP, </ins> firstContainer.Name, firstContainer.Image, podHostString(pod.Status.Host, pod.Status.HostIP),
Change:
It's 127.0.0.1 regardless of the public address. Looks like we need to set WebServicesUrl: where we create the endpoint: using PublicAddress: and ReadWritePort:
/cc
In particular: , bgrant0607 wrote:

Discussion:
func (m *Master) InstallSwaggerAPI() { // Enable swagger UI and discovery API swaggerConfig := swagger.Config{ <del> WebServices: m.handlerContainer.RegisteredWebServices(), </del> <ins> WebServicesUrl: m.readWriteServer, WebServices:    m.handlerContainer.RegisteredWebServices(), </ins> // TODO: Parameterize the path? ApiPath:         "/swaggerapi/", SwaggerPath:     "/swaggerui/",
Change:
If the apiserver only listens on one physical IP, then you'd have to use kubectl --server to specify the host. The help message says specify the IP, connection refused: both IP and Port, then ok: So, is it possbile to default the port to 8080 if no port specified at command line or read it from the config file /etc/kubernetes/apiserver, which is 8080 too. If it's impossible to default the port to 8080, it needs an update of the help message at least, like: or add --port flag.
The options are: the port from the port by trying if none is specified a flag the documentation I think (4) is the way to go (I'm not lazy I swear). (1) requires access to the API server's filesystem which is off-limits. (2) seems like it'll work for some configs and is a default that may change. (3) is more verbose and adds yet another flag. Will send a PR.

Discussion:
--logtostderr=true: log to standard error instead of files --match-server-version=false: Require server version to match client version --namespace="": If present, the namespace scope for this CLI request. <del> -s, --server="": The address of the Kubernetes API server </del> <ins> -s, --server="": The address and port of the Kubernetes API server </ins> --stderrthreshold=2: logs at or above this threshold go to stderr --token="": Bearer token for authentication to the API server. --user="": The name of the kubeconfig user to use

// BindClusterFlags is a convenience method to bind the specified flags to their associated variables func BindClusterFlags(clusterInfo *clientcmdapi.Cluster, flags *pflag.FlagSet, flagNames ClusterOverrideFlags) { <del> flags.StringVarP(&clusterInfo.Server, flagNames.APIServer, flagNames.APIServerShort, "", "The address of the Kubernetes API server") </del> <ins> flags.StringVarP(&clusterInfo.Server, flagNames.APIServer, flagNames.APIServerShort, "", "The address and port of the Kubernetes API server") </ins> flags.StringVar(&clusterInfo.APIVersion, flagNames.APIVersion, "", "The API version to use when talking to the server") flags.StringVar(&clusterInfo.CertificateAuthority, flagNames.CertificateAuthority, "", "Path to a cert. file for the certificate authority.") flags.BoolVar(&clusterInfo.InsecureSkipTLSVerify, flagNames.InsecureSkipTLSVerify, false, "If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure.")