Stop blocking Instance/Binding spec updates if there is an operation in progress

TL;DR Let's remove the locking mechanism preventing spec updates while there is an operation in progress. Sending just last user that have updated the spec is consistent with "kube way" and is good enough.

Currently we prevent any spec updates while there is a provisioning/update operation in progress:
https://github.com/kubernetes-incubator/service-catalog/blob/b3de6eca6ff3ed6049d85156a493ceee1db69097/pkg/apis/servicecatalog/validation/instance.go#L256-L268
The main reason for that is addressing #1149, i.e. preventing concurrent updates to be able to tie every spec change to a user who made the change, and send every change as a separate OSB request to broker with user info attached.
While this requirement is understandable from the OSB brokers point of view, it's inconsistent with "kube way" and is actually impossible to fully support, especially once we address retries after failures (#1715).
Example:

User A creates an instance with P1 parameters in the spec.
Service Catalog sends a provisioning request with P1 as payload and user A attached to it.
Provisioning fails with 400 Bad Request, because one of the required parameters is missing.
User B goes and adds a missing parameter P2 to the spec. Now the spec parameters is: P = P1 + P2.
Service Catalog sends a provisioning request with P = P1 + P2 payload and user B attached to it. In other words, we have lost information about user A there.

The other annoying part that we'll face after fixing #1149 is that users won't be able to fix the spec until Service Catalog stops retrying (which by default is 1 week). The only quick way out of this situation would then be deleting an instance and creating a new one, which leads to a very confusing UX.
Proposal:  Stop preventing spec updates, and send the last user that mutated the spec as the one who is responsible for the entire spec.
/cc @pmorie @duglin @kibbles-n-bytes @staebler @jboyd01

After step 3, the failure, is there any reason that we don't reset the instance to the previous state? Do we have that info in the Status.

After step 3, the failure, is there any reason that we don't reset the instance to the previous state?

That would be inconsistent with every other Kubernetes resource out there. E.g. Deployment object does not revert the change if it cannot pull the docker image.
Spec holds the desired state provided by the user. We don't know what they would want to do if this state cannot be realized right now.

The current behaviour contradicts one of the Kubernetes design principles:

Functionality must be level-based, meaning the system must operate correctly given the desired state and the current/observed state, regardless of how many intermediate state updates may have been missed. Edge-triggered behavior must be just an optimization.

I.e. it should be ok to miss intermediate updates and only act on the current desired state. And hence intermediate updates should not be blocked.

Yea, but that was also written w/o taking into account that some 3rd party system has control over our state, or any of the other constraints we're living under. Not saying what we have now is perfect, or even what we want going forward, but its where we landed given all of the factors involved.

but its where we landed given all of the factors involved

As @pmorie in the original comment https://github.com/kubernetes-incubator/service-catalog/issues/1149#issuecomment-325394233:

This probably won't bear out in the long-term as a valid approach but it is good enough to get us to an initial beta.

As far as I understand, the current blocking behaviour was never considered to be finalized forever.
And with adding support for retries (a very critical UX feature), continuing support of blocking will be extremely annoying and painful for users.
Also, I don't think that the behaviour without blocking will break the OSB spec, even if it's different from Cloud Foundry.

@duglin @kibbles-n-bytes I have a proposal that can make the blocking behaviour opt-in: instead of hardcoding it in the API server validation, we can implement the admission controller that will do the same.
Then it's up to the vendor/admins to decide whether this admission controller should be turned on or not.

Another option is to add a parameter to BrokerSpec that will turn blocking on for the broker that relies on this behaviour heavily (i.e. performing a fine-grained authorization on its side).
Let's discuss these options at the next SIG call.

@duglin you suggested to create an OSB issue to clarify this part of the spec. Can you create one? Thanks.

@nilebox I can but I can't remember which part of the spec people thought was ambiguous. Can you refresh my memory?

@duglin somewhere around user info header? https://github.com/openservicebrokerapi/servicebroker/blob/master/profile.md#originating-identity-header
To be clear: I personally don't think it's ambiguous, I think it it's good that spec is not specific about the platform's behavior there (i.e. whether every instance parameters change by users must be sent separately or not).

I agree that I don't think its ambiguous either - which is why I was asking for the bit that people thought needed more clarity. While, in general, I think you're right that the platform should probably be allowed to decide when to do things like batch up changes into one update() and then associate that with just one user, in this case I don't think that's what we're talking about.
If all of the edits to the spec were done by the same kube user then I think it might be ok to batch them, but when the edits are not all done by the same user and the identity header is used in such a way that the specific user associated with the action matters (e.g. for authentication purposes), then batching defeats the point of the header because the wrong person will be associated with all aspects of the change. And at that point it feels like we're violating the (at least) the spirit of the spec.

I think calling it "batching" is a bit misleading; that almost implies that Service Catalog would be combining all requests at will for some sort of optimization. That's not the spirit of this change; this is only really relevant for failure situations, as successful requests would go through so quickly that in effect they'd be un-"batch"able. The spirit of this change is explicitly that, in the case where a request is not succeeding, if users want to modify the spec, they must be aware that their user identity will be tied to all pending changes.
In that interpretation, it's really not a discussion at the OSB spec level at all; it's a discussion solely about Service Catalog and its model of parameter ownership. In effect, we are 75% the way there already, and mostly just pretending that we're actually blocking spec changes. Parameters sourced from secrets can be updated willy-nilly (will the request even be tied to the correct user identity??), and after an update fails, we allow the user to edit the spec and trigger a new update, the entirety of which will be associated with that user's identity even if the previously-failed changes were made by someone else.

I know we’re not batching in general but that is the net result in this situation. Say someone modifies the plan and it fails because of an auth issue.  Someone else then modified something else, say a param, and triggers an update. If the 2nd person has more auth than the first person then both updates will happen and be associated with the 2nd user even tho the plan update should never have been allowed at all. Do I have that right?

@duglin You're right about the potential "batching effect", but again, it's out of the scope of OSB.
For example, Service Catalog could just say that it doesn't handle granular authorization of individual parameters at all, and user that updates a single parameter is responsible for all changed parameters since the last successful OSB operation. And that will be valid platform behavior according to OSB with correct header. It won't break brokers either. If Service Catalog users wants more granular control, he will have to implement this with admission control or RBAC on the Kubernetes side.
As @kibbles-n-bytes said, that's what already happens in 75% of scenarios, and we can't fix that (well, theoretically we could start blocking Secret updates with admission controller, and rollback changes if OSB request fails, but it will be too far from how Kubernetes resources supposed to work).

@nilebox I'm not sure its out of scope of OSB. My example wasn't about updating individual parameters it was about updating parameters AND updating the plan as two separate actions by two different individuals with different rights.
This isn't about breaking brokers as much as its breaking the auth model of the platform that is in place today. With the proliferation of platforms (docker, cf, kube, etc...) we had to identify a common spot in the workflow that would allow us to perform additional business logic checks on the actions that wouldn't force us to write custom platform-specific code each time. And in fact, some platforms don't allow for the insertion of additional checks at all. So, the common (and guaranteed) spot to insert this logic was on the OSBAPI flow between the platform and the broker by using what we call a "proxy broker". Its basically part of the platform and can do any additional checks/logic that are needed regardless of the platform being used and what checks the platform allows us to insert.
I'd like to back up the discussion a bit and understand why upon receiving a "400 bad request" we can't just rollback the spec to the previous (good) state since the data provided was clearly bad. We could set a condition to indicate why it was rolled back so the user can understand why/what happened. It just seems to me that allowing someone to update the spec (not to fix it but to make other changes) when we know the current state is bad, and will probably continue to be bad, is just making the situation worse.
I agree this isn't the Kube way, but Kube wasn't designed to handle the situation where a remote system needed to be checked-with before a spec change was finalized. So this locking mechanism was put in place to deal with it.
I guess one option (and this feel really funky) would be to make the OSBAPI call as part of an admission controller and then only update the spec if the OSBAPI call worked - otherwise reject the change.  :-)     If you think about it, this is pretty much the rollback idea, because that's the same net result just w/o the synchronous nature of the flow.

My example wasn't about updating individual parameters it was about updating parameters AND updating the plan as two separate actions by two different individuals with different rights.

@duglin I think it's more specific problem than we have discussed before. And there might be a specific solution for this. For example, block spec updates only if there is a plan change that haven't been reconciled yet.

why upon receiving a "400 bad request" we can't just rollback the spec to the previous (good) state since the data provided was clearly bad

We technically can, but it's not how Kubernetes resources work. Fixing the broken spec requires manual intervention from user.
Also, we can't rollback secret parameters, so again we are talking about 25% of problem coverage there (while in other 75% it's still not covered).

It just seems to me that allowing someone to update the spec (not to fix it but to make other changes) when we know the current state is bad, and will probably continue to be bad, is just making the situation worse.

I disagree. Manual intervention is much better than rollback with magic that competes with user for updating the spec.

make the OSBAPI call as part of an admission controller and then only update the spec if the OSBAPI call worked - otherwise reject the change

That actually shows why rolling back the spec is bad. Because Kubernetes resources are reconciled asynchronously, and what you suggest with admission control is making it synchronous. Blocking spec updates is also trying to make them single-thread and synchronous in some way.
I don't think rollback is an option to consider at all, but would be happy to hear other people's opinion.

It seems the cause of the issue is that the OSB protocol does not provide any means for the platform to consult the broker if the change is valid so that it could reject the request synchronously. There is schema to do validation but there are no means to check if the user is authorized. I was under impression until recently that authorization is not a concern OSB spec is trying to cover and I think the user info section was added only recently to the spec (is this correct?). It just feels the use case is not supported well at the spec level and hence there is no good way to support it in Kubernetes using the current OSB spec.

I'd like to back up the discussion a bit and understand why upon receiving a "400 bad request" we can't just rollback the spec to the previous (good) state since the data provided was clearly bad.

In addition to what has been said above, here are two more things to think about:

Rolling back would mean service catalog needs to store the previous "good" state. It might be ok because it may also be needed if service catalog wants to support sending patches (or old+new state in any other form) to brokers.
What to do if there is no previous "good" state - it was a create request and it has failed.

I agree this isn't the Kube way, but Kube wasn't designed to handle the situation where a remote system needed to be checked-with before a spec change was finalized. So this locking mechanism was put in place to deal with it.

Admission hooks is the mechanism to do this but as I said above there is no way in OSB spec AFAIK to perform an authz check.

On the implementation side I propose that we remove the code blocking updates now (given that it doesn't solve what it was supposed to in most cases), and continue discusson on the new design and possible changes in OSB and its implementation in Service Catalog.

@nilebox I don't know what the correct next step is yet but I'd prefer if we discussed this on a Monday call (or some other call) and developed a design plan before we undo the current code that people spent quite a bit of time developing.

We're having some internal discussions around this issue and someone had a question.... what happens if user A tried to delete an instance but then the delete failed at the broker for some reason (e.g. they don't have the authority to do so), then user B tried to update the instance? Would the update be blocked due to the instance being marked for deletion? Can we get out of this situation w/o doing some kind of roll back?

@duglin Deletion in Kubernetes is irreversible. Once an instance is marked with DeletionTimestamp, you can't "undelete" it. Also, any spec changes are rejected (i.e. you can't rollback, and you can't let the authorized user to touch instance to fix authz either). Controller can only update status and remove finalizers to proceed with deletion.
This is definitely a problem worth discussing in the scope of authorization.

Just to add to the above, in Kubernetes several authorization mechanisms are consulted before the object is marked for deletion (or is updated/created). Those mechanisms are built-in admissions controllers, admission hooks and configured authorization mechanism (RBAC by default).
Kubernetes is not expecting a backend for a controlled object to perform any authn/authz after the spec has been updated/deleted. It should happen before the change is made.

There is a sort of precedent here with deployment rollouts and multiple replicasets. I'm not sure what the analogy is exactly, or how dep+rs work together, but it could be said that because rollout and undo work by switching between different versions of specs (defined on the rs), and that there is a history of edits available to choose from.

@MHBauer good point! The way rollbacks work in deployments is that for every spec change (or rather a set of changes accumulated since the last rollout) there is a new replica set created, and the previous replica set being retained with pods scaled down to zero replicas: 0 instead of deleting. The number of replica sets to be retained is configurable via https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit
Another aspect is that deployments don't run rollbacks automatically hidden from the user, there is a very specific imperative command that is explicitly executed by the user:
kubectl rollout undo deployment/nginx-deployment

Also see https://kubernetes.io/cn/docs/concepts/workloads/controllers/deployment/#rollback-to

Rollback To
.spec.rollbackTo is an optional field with the configuration the Deployment should roll back to. Setting this field triggers a rollback, and this field will be cleared by the server after a rollback is done.
Because this field will be cleared by the server, it should not be used declaratively. For example, you should not perform kubectl apply with a manifest with .spec.rollbackTo field set.

And obviously, you can still update the Deployment spec even if there is a rollout in progress.

So in our case it would mean that:

ServiceInstance would internally produce a ServiceInstanceSnapshot (just made up a name) object for every OSB update request we send. This ServiceInstanceSnapshot must include all fields that can be potentially changed (plan, inline parameters, secret parameters). Sounds too hard to implement IMO.
We would need to add an imperative command to kubectl (via plugin?) that would trigger the rollback. Or add a command to svcat to do that.
We still shouldn't prevent spec updates if there is an update in progress. In other words, we still won't be able to track every single spec change separately.

To be clear, I'm not a fan of this option, and also this feature looks like an opt-in extension to the standard behavior, i.e. if you never run the kubectl rollout undo command, you'll never use rollbacks.

Also to add to above: when you rollback a Deployment, the environment variables picked up through envFrom won't be rolled back, i.e. only the Deployment spec is getting rolled back. In our case it means that we will only rollback plan and inline parameters, and not secret parameters.
Not sure what we would achieve by implementing rollbacks with the same semantics as Deployments. Sounds like we would have the same problems as we currently have, just with more complexity.
It's probably better to build rollbacks semantics at the higher level than Service Catalog (keeping history of both spec changes and secret parameters, and supporting imperative commands), if someone finds this useful.

I put this on the 16th agenda, we can discuss there, and either decide or schedule another meeting.
Sounds like it maybe wasn't the best analogy in terms of total behavior.
Rephrasing, so I make sure I understand:
We can't do an update to fix a broken spec, because the validation fails it.  At the risk of shooting myself in the foot, it sounds like the validation might be too strict for this case. I think we're abusing validation enough as it is. I don't want to suggest more changes at the moment.
(This part kind of rambles)
Thinking through multiple auth checks:

both users have appropriate access

everything is fine.

user 1 does, user 2 does not

user 1 is authorized to make the change, we are processing, user 2 doesn't have access to change and so the broker rejects it, but only later. user1 is irritated, and while they may be authorized to make user2 change, they do not know what it is.

user 1 does not, user 2 does

user 1 makes a change they are not allowed to, and our instance goes into a failure state, eventually. user 2 wants to make a different change, either

sees the failure state and can't know what user1 did to make it fail
sees in-progress, thinks everything is okay, and makes their change, only to be authorizing something they didn't necessarily wanting to be authorize.

neither user as access

everything fails

(reengage semi coherent thought)
It seems like what we need to be doing is ensuring freshness (that user2 sees the updates user1 made, and can't make a change without including those) when changing specs, and make the users understand that they're authorizing the whole state.
At all times, I think we have the problem of user1 and user2 not necessarily knowing what change was made by the other, as they only want to authorize their own change, and by the time of the rejection, history is gone. Not sure what to do about this.

It seems like what we need to be doing is ensuring freshness (that user2 sees the updates user1 made, and can't make a change without including those) when changing specs

This is guaranteed by design, otherwise update with fail with conflict error.

and make the users understand that they're authorizing the whole state

Indeed, this is the part we need to be explicit about in the docs to avoid any confusion.

@duglin if we want to elaborate on the synchronous authorization via admission controller, there is a new "authorized webhook" to be released in k8s 1.10: https://github.com/kubernetes/features/issues/516

admission controllers won't help in this case. In order for an AC to work it would need to fully understand the business logic that the broker is going to do while processing the update(). And since we don't even know which broker is going to be used until runtime, I don't see how we an do that. Or... if there was a way to do call the broker's update() func in some kind of "check mode" that would ask if the request would go thru w/o actually doing it, but OSB API doesn't define that.
I just don't see how to verify an incoming request w/o actually calling the broker to do it.
I supposed that could mean that we actually invoke the broker.update() as part of an AC (or as part of the apiserver.put() after all of the k8s checks have been done) and only store the successful results once it succeeded. Turns it into a sync flow though.

That might be an option for v3 - just not sure how to do that in the v2.x timeframe.

and make the users understand that they're authorizing the whole state

Indeed, this is the part we need to be explicit about in the docs to avoid any confusion.

I'm not sure that's fully covers it. To me, its not just a matter of "approving" both user1 and user2's changes, its associated the correct set of changes with each user. That model only works if, from the user's POV, user1 undid their changes and then user2 asked for both sets of changes. Granted its a fine line because you could argue that as long as user2 understands the full set of changes then its equivalent to them doing them all, but that's really only true if user1 agrees to not have their ID associated with the the first set of changes - which means them rolling back their edits.
I'd like to separate out the concerns and deal with them independently:
1 - failures:
I wonder if it would help (or hurt :-)  ) if we looked at a different usecase and see how we'd handle that to see if it provides some insight into how we might deal with this.....  what if some action is taken on a svc-cat resource but the broker refuses to do it - for some reason - and will never do it. At what point should svc-cat give up and restore its state to match reality?  This is probably more of a k8s question. I suspect the answer, in the normal k8s cases, is "never". It would be up to the user of the resource to issue a new put() to set the state appropriately (either to reality, or some other state that the broker will accept). However, in most (all?) k8s cases you can ask for the current state - we can't ask that of the broker. We do however at least try to keep track of the broker's state in our Status resources (although we don't seem to save the old plan).  So, perhaps we either need to fully support keeping track of the broker's state in the Status() section so the user can know what values should be used, or support an undo() func that does it for the user and thus avoid the locking aspect that prevents us from issues a put() to fix things.
2 - blocking is not the kube way:
While I'm sympathetic to this, I don't think we can take an absolute firm stand on this because we're dealing with another system that doesn't operate in the same kind of "desired state" model that k8s does - OSB API is more of a serialized/synchronized RPC system where each action must be associated with the correct user.
So, even if we did remove the blocking aspect and allowed subsequent changes, since user1 MUST still be associated with their changes (unless there is some kind of undo of them), then we're faced with having some sort of queue of operations which could create a long list of pending actions that are all based on one that will never be allowed to happen. Which is probably worse that asking people to serialize their requests because it presents those subsequent users with a lie about the current state of the world.
Also, this isn't about the state of the world not matching the desired state "yet", its about the desired state being invalid and should never have been allowed to be stored in the spec in the first place - there is a difference.

we can't ask that of the broker

Well, that's a hole in the OSB spec.
There's simply no way for Service Catalog to tell what's the instance state without GET request if the update request has failed with timeout or 500 Internal Server Error error.

its about the desired state being invalid and should never have been allowed to be stored in the spec in the first place

There is no such thing as "invalid desired state" in k8s. If the initial request was valid (i.e. json schema validation has passed, and all admission controllers proceeded with request), and the spec was updated, the desired state is considered valid. And if there is an error reconciling it, it is up to the user (or automation around k8s) to apply the new changes that will fix the desired state.

I feel like in order to replicate CloudFoundry mechanics and meet all requirements including authorization, we would have to get rid of etcd storage and controller-manager completely, and instead forward all requests directly to the brokers without persisting instances and bindings at all.
But again, that is not possible even in theory since there are no GET endpoints for instances and bindings in OSB API, which is a big mistake IMO.

There is no such thing as "invalid desired state" in k8s.

yup - exactly.  But in our case we may have one.

I feel like in order to replicate CloudFoundry mechanics and meet all requirements ...instead forward all requests directly to the brokers without persisting instances and bindings at all

Well, we could store them in etcd once the broker has completed its processing - but that turns these operations into RPC ones.  And I still can't figure out how bad that really would be.

We haven't decided yet, but the proposed set of changes most people agreed with at the today's call was:

Get rid of locks completely, i.e. merge #1790
Add support for imperative rollback command for a nicer UX (if the user doesn’t want to take ownership of the changes in the desired state that are different from the last applied state). Rollbacks are performed only for the spec (no secret parameters rollback)
Maybe: opt-in admission controller for locks if they are still needed for some SC use cases.

Now that #1765 is merged, this issue has become critical for non-happy-path and needs to be fixed ASAP.


S2 action bar update

Description

Made the following changes to component layout tokens for both mobile and desktop.
New tokens
action-bar-minimum-width
action-bar-label-to-action-group-area
Motivation and context

Made token changes required for the S2 action bar update.
Related issue

https://jira.corp.adobe.com/browse/SDS-14094
Types of changes

 [ ] Patch (bug fixes, typos, mistakes; non-breaking change which fixes an issue)
 [X] Minor (add a new token, changing a value, deprecating a token; non-breaking change which adds functionality)
 [ ] Major (deleting a token, changing token value type, renaming a token by deprecating the old one; fix or feature that would cause existing functionality to change)
Checklist:

 [X] I have signed the [Adobe Open Source CLA](https://opensource.adobe.com/cla.html).
 [X] I updated the token in all applicable sets. This applies if updating, adding, or deleting a token that has data across different sets (for example, if the value differs across color themes.)

TESTING spectrum2
READING spectrum-tokens: /spectrum-tokens/packages/tokens/src/
READING   tokens studio: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-colors/
READING   tokens studio: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-non-colors/

WARNING - studio token uuid collision: (bc54e89f-6740-4004-891e-c515f8f79693)
spectrum2/layout.component/desktop,action-bar-close-button-to-counter
spectrum2/layout.component/desktop,action-bar-label-to-action-group-area
spectrum2/layout.component/mobile,action-bar-close-button-to-counter
spectrum2/layout.component/mobile,action-bar-label-to-action-group-area

STUDIO SYNC SUMMARY
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.component.action-bar-minimum-width

SPECTRUM SYNC SUMMARY
NEW TOKENS: (1) action-bar-minimum-width

TEST COMPLETE

TESTING spectrum2
READING spectrum-tokens: /spectrum-tokens/packages/tokens/src/
READING   tokens studio: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-colors/
READING   tokens studio: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-non-colors/
STUDIO SYNC SUMMARY
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.component.action-bar-minimum-width
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.component.action-bar-label-to-action-group-area

SPECTRUM SYNC SUMMARY
NEW TOKENS: (2) action-bar-minimum-width, action-bar-label-to-action-group-area

TEST COMPLETE


Update http4s-circe, http4s-dsl to 0.23.25

About this PR
📦 Updates

org.http4s:http4s-circe
org.http4s:http4s-dsl

from 0.21.34 to 0.23.25
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

💡 Applied Scalafix Migrations

org.http4s:http4s-.*:0.22.0

github:http4s/http4s/v0_22?sha=series/0.22

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s" }
}]

labels: library-update, early-semver-major, semver-spec-minor, version-scheme:early-semver, scalafix-migrations, commit-count:n:2

Superseded by #552.


Getting 2 different Kubernetes versions

When doing an install from the current master branch, it mixes 2 Kubernetes versions.
When doing kubectl version I am getting the following:
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.4", GitCommit:"224be7bdce5a9dd0c2fd0d46b83865648e2fe0ba", GitTreeState:"clean", BuildDate:"2019-12-11T12:37:43Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

But when doing kubectl get nodes I am getting this
NAME                   STATUS   ROLES    AGE   VERSION
kubernetes-master-01   Ready    master   35m   v1.16.2
kubernetes-worker-01   Ready    <none>   35m   v1.16.2
kubernetes-worker-02   Ready    <none>   35m   v1.16.2

I checked the kubeadm and kubectl package on the master server and they are both 1.16.2-00. I think it has to do with kubernetesVersion: stable in /root/master-config.yaml when doing the kubeadm init. Should we fix the version in there?

I think you pointed it out correctly. Do you want to PR a fix for this?

yes, I will have a look at fixing that. Trying to also think about https://github.com/xetys/hetzner-kube/issues/87 and how this fix could help towards solving this.


PropType Validation Bug

I originally created this issue on the expo repository and a Samaritan who goes by wodin said it would be better moving it to this repository.
The issue I have been experiencing is not seeing a yellow warning box on snack when I pass an incorrect Proptype.
Below is the link to the snack that demonstrates the problem:
https://snack.expo.io/@alishehzad/no-warning-for-incorrect-proptype
Here count is validated in 'Count.js' and exported to 'App.js'.
This works fine locally. Just not in a snack.

Duplicate of #18


Add GetSetBits and Count to BitArray

This adds two new functions to the BitArray interface for efficient access to set bits.
GetSetBits returns the position of bits set in the array. It is provided a position to start from and will fill the buffer with as many set bits as fit. Its implementation is based on TrailingZeros64 from math/bits.
Example usage:
ba := newBitArray(10)
ba.SetBit(1)
ba.SetBit(4)
ba.SetBit(8)

buffer := make([]uint64, 0, 2)
assert.Equal(t, []uint64{1, 4}, ba.GetSetBits(0, buffer))
assert.Equal(t, []uint64{8}, ba.GetSetBits(5, buffer))

Count returns the total number of bits set in the array. Its implementation is based on OnesCount64 from math/bits.
Example usage:
ba := newBitArray(10)
ba.SetBit(1)
ba.SetBit(4)
ba.SetBit(8)

assert.Equal(t, 3, ba.Count())

ba.ClearBit(4)
assert.Equal(t, 2, ba.Count())

ba.Reset()
assert.Equal(t, 0, ba.Count())

@Workiva/release-management-p


OnUnobservedTaskException() System.ArgumentException: Requested value 'media' was not found.

Not sure what triggers this.  It looks like it is trying to check filtering but I have nothing custom defined in the bot.  I'm not even sure where the media keyword is used.
EDIT: Actually it looks like it is happening when it detects a PICS change.  I just added the default set of filters to the config to see if it fixes it... Will advise later and close if it does.
2023-12-05 14:31:53|ArchiSteamFarm-52604|FATAL|ASF|OnUnobservedTaskException() System.ArgumentException: Requested value 'media' was not found.
   at System.Enum.TryParseByName(RuntimeType enumType, ReadOnlySpan`1 value, Boolean ignoreCase, Boolean throwOnFailure, UInt64& result)
   at System.Enum.TryParseInt32Enum(RuntimeType enumType, ReadOnlySpan`1 value, Int32 minInclusive, Int32 maxInclusive,Boolean ignoreCase, Boolean throwOnFailure, TypeCode type, Int32& result)
   at System.Enum.TryParse[TEnum](ReadOnlySpan`1 value, Boolean ignoreCase, Boolean throwOnFailure, TEnum& result)
   at FreePackages.FilterableApp..ctor(UInt32 id, KeyValue kv)
   at FreePackages.FilterablePackage.<>c.<AddPackageContents>b__22_0(ValueTuple`2 packageContent)
   at System.Linq.Utilities.<>c__DisplayClass2_0`3.<CombineSelectors>b__0(TSource)
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.ToList()
   at FreePackages.FilterablePackage.AddPackageContents(IEnumerable`1 packageContents)
   at System.Collections.Generic.List`1.ForEach(Action`1)
   at FreePackages.PackageHandler.HandleProductInfo(List`1 productInfo)
   at FreePackages.PackageHandler.GetProductInfo(HashSet`1 appIDs, HashSet`1 packageIDs, Func`2 onFetchProductInfoCallback)
   at FreePackages.PackageHandler.HandleChanges()
   at FreePackages.PackageHandler.<>c.<<OnPICSChanges>b__19_3>d.MoveNext()

Bot config (updated):
{
  "AutoSteamSaleEvent": true,
  "CustomGamePlayedWhileFarming": "Farming...",
  "CustomGamePlayedWhileIdle": "Idling...",
  "Enabled": true,
  "SkipRefundableGames": true,
  "SteamLogin"<EMAIL_ADDRESS>  "SteamPassword": "iYAg5wS2pYHPXq",
  "EnableFreePackages": true,
  "FreePackagesFilters": [
    {
      "Types": [],
      "Tags": [],
      "Categories": [],
      "Languages": [],
      "MinReviewScore": 0,
      "IgnoredContentDescriptors": [],
      "IgnoredTypes": [],
      "IgnoredTags": [],
      "IgnoredCategories": [],
      "IgnoredAppIDs": [],
      "ImportStoreFilters": false,
      "IgnoreFreeWeekends": false,
      "PlaytestMode": 0
    }
  ]
}

I think I see what's causing this.  This doesn't look like a config issue.  It looks like there's a certain game which has a property value that the plugin isn't expecting to see.
If it doesn't go away on it's own, maybe you can temporarily fix this by going to your ArchiSteamFarm config folder, and edit the FreePackages.cache file in a text editor.  Change it to something like: {"LastChangeNumber":21412195}
I'm currently running the plugin, but I didn't get this error, and I don't understand why I wouldn't.  Have you been using the plugin for long or have you just started using it?  What version of ArchiSteamFarm are you using?  Also are you using an OS specific version of ArchiSteamFarm or the generic version?


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/73849

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/74052

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/74992

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/80353

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/82302

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/102126

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/112593

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/113023

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/115023

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/116692


[GoCD Helm Chart] Bump up GoCD Version to 20.8.0

This PR was created by @GaneshSPatil for testing purposes. (I Was verifying the bump up gocd helm chart version script).
Closing...


publish to nexus repo with rest api

https://help.sonatype.com/repomanager3/rest-and-integration-api
https://support.sonatype.com/hc/en-us/articles/213465868-Uploading-to-a-Staging-Repository-via-REST-API
curl -v -u admin:admin123 -H "Content-type: application/x-rpm" --upload-file some.rpm http://localhost:8081/nexus/service/local/staging/deployByRepositoryId/abc-1000/com/mycompany/artifact/1.0/artifact-1.0.rpm

Param
value

Profile Name
Test

Profile Selection Strategy
Explicit or Implicit - selected by ID or Nexus will calculate match

Searchable Repositories
[x]

Staging Mode
Deploy and UI Upload

Template
Maven2 (hosted, release)

Repository Target
All (Maven2)

Release Repository
Releases

IQ Server Application
(none)

Content Type
maven2

fixes #49


Install logs: NoWorkerNodes => (AWS|GCP)NoWorkerNodes

Replace the NoWorkerNodes regex/reason with cloud-specific versions
AWSNoWorkerNodes and GCPNoWorkerNodes.
HIVE-1722

/assign @gregsheremeta
/cc @wking @joelddiaz

/cc @tzvatot

/lgtm

Are we going to have any issues with this removing the old failure reason code?

/test e2e

/hold
in fact, now that i see that these regex configmaps are more than just OSD-specific (eg ACM would also receive this), i'd really like to see more generic text associated with this

/unhold


Higher range with random picker

Fixes #7. Gets the latest comic number from the API, and uses it as the highest number for the random range.
No parameters will NOT provide a random comic, if that worked in the past it doesn't work anymore. If you want that, see PR #10.

Looks good. thanks!


Text height function does not respect it's argument

Problem:  plines_m_win() does not take into account it's "limit_winheight"
argument for filler lines below the last line of the buffer.
Solution: Check window height when "limit_winheight" is TRUE.

thanks!


IndexError when using with custom meshes

Hi, upon running the example notebook I receive the following IndexError. Can you please guide.
The error occurs in functional mapping section of the example_notebook.ipynb when I replace the objs with my mesh models. Are there any specific conditions that need to be fulfilled for running on different meshes apart from the examples provided ?
File [~/sem2_BTP/pyFM/pyFM/functional.py:244](https://vscode-remote+ssh-002dremote-002b192-002e168-002e3-002e126.vscode-resource.vscode-cdn.net/home/aishani20278/sem2_BTP/pyFM/~/sem2_BTP/pyFM/pyFM/functional.py:244), in FunctionalMapping.preprocess(self, n_ev, n_descr, descr_type, landmarks, subsample_step, k_process, verbose)
    241 self.descr2 = sg.mesh_WKS(self.mesh2, n_descr, k=self.k2)  # (N2, n_descr)
    243 if use_lm:
--> 244     lm_descr1 = sg.mesh_WKS(self.mesh1, n_descr, landmarks=lmks1, k=self.k1)  # (N1, p*n_descr)
    245     lm_descr2 = sg.mesh_WKS(self.mesh2, n_descr, landmarks=lmks2, k=self.k2)  # (N2, p*n_descr)
    247     self.descr1 = np.hstack([self.descr1, lm_descr1])  # (N1, (p+1)*n_descr)

File [~/sem2_BTP/pyFM/pyFM/signatures/WKS_functions.py:118](https://vscode-remote+ssh-002dremote-002b192-002e168-002e3-002e126.vscode-resource.vscode-cdn.net/home/aishani20278/sem2_BTP/pyFM/~/sem2_BTP/pyFM/pyFM/signatures/WKS_functions.py:118), in mesh_WKS(mesh, num_E, landmarks, k)
    115 else:
    116     assert len(mesh.eigenvalues >= k), f"At least ${k}$ eigenvalues should be computed, not {len(mesh.eigenvalues)}"
--> 118 return auto_WKS(mesh.eigenvalues[:k], mesh.eigenvectors[:, :k], num_E, landmarks=landmarks, scaled=True)

File [~/sem2_BTP/pyFM/pyFM/signatures/WKS_functions.py:107](https://vscode-remote+ssh-002dremote-002b192-002e168-002e3-002e126.vscode-resource.vscode-cdn.net/home/aishani20278/sem2_BTP/pyFM/~/sem2_BTP/pyFM/pyFM/signatures/WKS_functions.py:107), in auto_WKS(evals, evects, num_E, landmarks, scaled)
    105     return WKS(abs_ev, evects, energy_list, sigma, scaled=scaled)
    106 else:
--> 107     return lm_WKS(abs_ev, evects, landmarks, energy_list, sigma, scaled=scaled)

File [~/sem2_BTP/pyFM/pyFM/signatures/WKS_functions.py:68](https://vscode-remote+ssh-002dremote-002b192-002e168-002e3-002e126.vscode-resource.vscode-cdn.net/home/aishani20278/sem2_BTP/pyFM/~/sem2_BTP/pyFM/pyFM/signatures/WKS_functions.py:68), in lm_WKS(evals, evects, landmarks, energy_list, sigma, scaled)
     66 e_list = np.asarray(energy_list)
     67 coefs = np.exp(-np.square(e_list[:, None] - np.log(np.abs(evals))[None, :]) / (2*sigma**2))  # (num_E,K)
---> 68 weighted_evects = evects[None, landmarks, :] * coefs[:,None,:]  # (num_E,p,K)
     70 landmarks_WKS = np.einsum('tpk,nk->ptn', weighted_evects, evects)  # (p,num_E,N)
     72 if scaled:

IndexError: index 3177 is out of bounds for axis 0 with size 1345

Hi,
The example notebook use landmarks, which are specific to the given shapes. You would need to input your own (or even simply set them to None).
I'd also recommend directly using the ZoomOut algorithm on some initial correspondences instead of using the Functional Map pipeline from the example notebook (see pyFM.refine.zoomout).


Unnecessary Complexity and Possible Future Proofing in Some Recipes.

A bunch of recipes which contain things like Logs or Planks I saw in the code that list every single type of plank.
While it may not be that bad it could be easier to instead do the following for example in the case of Logs in bulk_bowl.json .
This is the current code
    "key": {
        "#": [
            {
                "item": "minecraft:oak_log"
            },
            (imagine here more listing but of Every Single type of wood in Log,Striped and Wood form)
        ]
    }

This code right now its inefficient and not future-proof since it would need updates for each time a new wood type its added.
In its place we could use the tag "minecraft:logs" which removes the need of any maintanance and makes it not only more readable but also clean and fail-proof.
The Finished thing should look similar to this
    "key": {
        "#": {
            "tag": "minecraft:logs"
        }
    }

I should make it clear that there are a bunch of different tags and even some for planks and other stuff so it could be useful not only for this but for many recipes overall.

yea some recipes do this, but i made this awhile ago forgetting i could do this so some recipes are using the multiple log variants instead of the tag. there is just some recipes i skipped over when going back and fixing them.


[OSPP] Proposal for Unknown Task Recognition Algorithm Reproduction based on Lifelong Learning of Ianvs

Proposal for Unknown Task Recognition Algorithm Reproduction based on Lifelong Learning of Ianvs.
This PR is a proposal that project aims to reproduce the CVPR2021 paper "Learning placeholders for open-set recognition" in the Semantic Segmentation dataset. This paper proposes placeholders that imitate the emergence of new classes, thus helping to transform closed-set training into open-set training.
This PR is a modification of the last PR

lgtm

The PR is perfect, but there are some minor issues about git commit convention that should be noted.
For commit history of Ianvs repository more readable and cleaner,  I suggest to squash the commits by git rebase -i kubeedge/main, to keep the number of commit to 1~3, and to make the commit message more concrete.
More details can be refered as following:

'Merge branch 'kubeedge:main' into main', it can be remove by the command git rebase
'update proposal', it can be more concrete like 'added someting to proposal', or just squash it to commit of proposal
'modify test report', it can be mocre concrete like 'removed/added someting to the test report'
...

these are just some examples, you can write it according to your own understanding.


PYIC-7753: Update reverification coi check

Proposed changes
What changed
Coi check rules for reverification:

DOB must match exactly
1 char of given name(s)
3 chars of family name(s)
Small bit of refactoring + updating/adding unit tests for new logic

Why did it change
Match coi check rules for reverification to latest requirements
Issue tracking

PYIC-7753

I've spotted this full name check in the CoiHandler when the reprove identity flag is set. This was using the FULL_NAME_DOB check too but should they have the same check rules? It doesn't look like it's being used for reverification?
(cc @Wynndow)

This is used when the user comes to IPV with the reprove_identity intervention flag set. I would say that just having the same full check that we use elsewhere would be find. But I also know this change is under some scrutiny from the fraud team, so it may be that we need exact name correlation. Not a very helpful answer, I know.

I've spotted this full name check in the CoiHandler when the reprove identity flag is set. This was using the FULL_NAME_DOB check too but should they have the same check rules? It doesn't look like it's being used for reverification?
(cc @Wynndow)

This is used when the user comes to IPV with the reprove_identity intervention flag set. I would say that just having the same full check that we use elsewhere would be find. But I also know this change is under some scrutiny from the fraud team, so it may be that we need exact name correlation. Not a very helpful answer, I know.

Thanks Chris :) in that case I'll reinstate the previous FULL_NAME_AND_DOB for reprove identity journeys just to be safe


Make is_monotonic~ work properly for index

Resolve #931 (The contents below is same as the contents of this issue)
When we use is_monotonic_decreasing or is_monotonic_increasing for index,
pandas works like below:
>>> s = pd.Series([7, 6, 5, 4, 3, 2, 1], index=[7, 6, 5, 4, 3, 2, 1])
>>> s.index.is_monotonic_decreasing
True

Since the index order is literally motononic decreasing, they return True
But our case,
>>> s = ks.Series([7, 6, 5, 4, 3, 2, 1], index=[7, 6, 5, 4, 3, 2, 1])
>>> s.index.is_monotonic_decreasing
False

as seen above, it returns False.
because our existing logic always order by index column before calculate the each rows increasing or decreasing.
So they always calculate result based on data column, not index column. (index column is always sorted since order by)
So i think maybe it is better to fix this logic to follow behavior of pandas one for index.

@itholic Good catch!
btw, the proposed fix seems still something missing:
>>> pser
0.097069    0.097069
0.674804    0.674804
0.417065    0.417065
dtype: float64
>>> pser.is_monotonic
False

>>> ks.from_pandas(pser).is_monotonic
True
>>> ks.from_pandas(pser).index.is_monotonic
False

maybe we need to apply the fix for Index to Series' case as well.

Codecov Report

Merging #930 into master will decrease coverage by 1.73%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #930      +/-   ##
==========================================
- Coverage   94.46%   92.73%   -1.74%
==========================================
  Files          34       34
  Lines        6383     6402      +19
==========================================
- Hits         6030     5937      -93
- Misses        353      465     +112

Impacted Files
Coverage Δ

databricks/koalas/base.py
95.37% <100%> (+0.57%)
:arrow_up:

databricks/koalas/usage_logging/__init__.py
24.54% <0%> (-72.73%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
50% <0%> (-50%)
:arrow_down:

databricks/koalas/__init__.py
75.6% <0%> (-9.76%)
:arrow_down:

databricks/conftest.py
91.48% <0%> (-6.39%)
:arrow_down:

databricks/koalas/frame.py
95.41% <0%> (-0.61%)
:arrow_down:

databricks/koalas/generic.py
95.07% <0%> (-0.5%)
:arrow_down:

databricks/koalas/plot.py
94.04% <0%> (-0.24%)
:arrow_down:

databricks/koalas/groupby.py
91.18% <0%> (-0.21%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4022df3...39e1bcf. Read the comment docs.

@ueshin , ah i missed it. just fixed it, Thanks for commenting :)

oops, I've never seen such that build failure. 😢
(maybe internal dependency issue..?)

Let me retrigger the build and let's see.

@ueshin oops my comment removed by mistake; yeah let's see and maybe hyukjin is something doing for speed up build process. 😃


emptyFill not working

Hi there,
I am using the emptyFill parameter to color the empty fill part of the circle, however it will not change the color to what I want:
I am using it like so:
emptyFill: {  color: '#CCCCCC' }
the color changes but to black, not grey...

@danimanca - according to documentation, you should specify the color as follows:
el.circleProgress({
  emptyFill: '#CCCCCC'
  // ...
})

I hope I've helped you. I'm closing this ticket, but feel free to reopen.


Upgrade fmtlib to support clang-17

Enhancement
Ref https://github.com/pingcap/tiflash/issues/7193
We need to upgrade fmtlib to support clang-17. However, the latest version of fmtlib disable implicit casts from enum/enum class to int, which leads to compile error. We need to resolve those errors with magic_enum::enum_name to print out the enum nam or fmt::underlying to print out the int value.
Reference: https://github.com/fmtlib/fmt/issues/3671

When we are sure the enum value has corresponding name, we use magic_enum::enum_name to cast it to string
When we are not sure the enum value has corresponding name, we use fmt::underlying to cast it to int

for example, the enum type defined in kvproto/tipb

For some classes, we implement a format_as function to make it printable by fmtlib

MppVersion/MPPDataPacketVersion/StringRef/SettingInt/SettingFloat/SettingDouble


Send-Teams-adaptive-card-on-incident-creation - Teams Sender Issue

I got the Send-Teams-adaptive-card-on-incident-creation working with the Playbook and Automation rule, BUT the Logic App is using my account to send to Teams channel. This is NO good since it depends on my account instead of a "service account", anyone in our team that interacts with the Teams channel incident post will be making incident changes on behalf of my account instead of their own, lastly, what happens in the future if my account gets disabled for any reason?
How can we have the Logic App use a managed identity or "service account" so Sentinel incidents in Teams are not bound to a single employees account?

Circling back on this.
Is there any way to have the Sentinel send incidents to a Teams channel without having the Logic App depend on a user account to authenticate to Teams that is a member of the Teams group? We do not want the incidents to appear as though they are being sent by a specific team member in the Teams channel, rather they are being sent by Sentinel.

Hi @Guruleenyc, thanks for flagging this issue, we will investigate this issue and get back to you with some updates. Thanks!

Due to the Adaptive Card shortcomings I noted, as a workaround I am now looking into a Playbook / Logic App to use a HTTP action POST with the Teams Webhook URL.
However, the JSON body in the HTTP trigger is difficult to get the format right.
Currently this is my JSON body for the Teams post:
"HTTP_2": {                 "inputs": {                     "body": {                         "attachments": [                             {                                 "content": {                                     "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",                                     "body": [                                         {                                             "text": "**Creation time**: @{triggerBody()?['object']?['properties']?['createdTimeUtc']}",                                             "type": "TextBlock"                                         },                                         {                                             "text": "**Title**: @{triggerBody()?['object']?['properties']?['title']}",                                             "type": "TextBlock"                                         } 										{                                             "text": "**ID**: @{triggerBody()?['object']?['properties']?['incidentNumber']}",                                             "type": "TextBlock"                                         }, 										{                                             "text": "**Severity**: @{triggerBody()?['object']?['properties']?['severity']}",                                             "type": "TextBlock"                                         }, 										{                                             "text": "**Description**: @{triggerBody()?['object']?['properties']?['description']}",                                             "type": "TextBlock"                                         }, 										{                                             "text": "**URL**: @{triggerBody()?['object']?['properties']?['incidentUrl']}",                                             "type": "TextBlock"                                         },                                     ],                                     "type": "AdaptiveCard",                                     "version": "1.2"                                 },                                 "contentType": "application/vnd.microsoft.card.adaptive",                                 "contentUrl": null                             }                         ],                         "type": "message"                     },                     "headers": {                         "Content-Type": "application/json"                     },

Hi @Guruleenyc, which issue you are facing now ?

Hi @Guruleenyc , Gentle Reminder: We are waiting for your response on this issue. If you still need to keep this issue active, please respond to it in the next 2 days. If we don't receive a response by 18-10-2024 date, we will be closing this issue.
Thanks!

Hi @Guruleenyc, since we have not received a response in the last 5 days, we are closing your issue as per our standard operating procedures. If you still need support for this issue, feel free to re-open at any time. Thank you for your co-operation.


[WIP]: add m2m_rawid style to style_fields

Still WIP, but I think this is an important feature due to #252 .

Thanks very much, and I will merge it when you finish this feature.

I just fixed a pop up issue on click search button, I think now this could be merged.
Though it's just work for now.


update bug.

the following sql will cause parsing exception. is it the bug?
find out the remove only field will not work with After keyword.
update user  set first_name = 'gn' remove birthday return AFTER $current  where @rid = #23:14

Fixed.


Fix DSA/ECDSA sign infinite loop(s)

Checklist

[ ] documentation is added or updated
[x] tests are added or updated

I assume this should not go into 3.1

DSA is not part of FIPS 186-5

DSA (signing) is not part of FIPS 186-5

But doesn't this impact the default provider?

This pull request is ready to merge

Merged with manual fixes for 3.0 and 3.1

Is there a reason why this should not be back-ported to 1.1.1 ?


add support for freebsd

note:  this is tested and working in production.

general comments: this now needs a rebase. i'd also squash it down to one commit.

for $config_file, we had to add that because the file is different on freebsd than it is on linux.  the ability to override it is there, but we also set a default per osfamily.
in all of the defines, if you prefer i can use $::haproxy::config_file instead of including the params manifest and then setting a local variable.

i'll also rebase to one commit.  initially i was leaving the manifests and tests separate, but rebasing to one is no problem.

updated per your request.  i also added some better testing for freebsd.

+1; @xaque208 might be interested in this as well

Cool!

i updated the chroot directory.

:+1: looks good now

+1

changes made as requested

changes made as requested.  hash rockets are lined up within each attribute.  variable equals signs are lined up per case.

excellent, thank you @sethlyons!


Invalid URL port

I'm running on the master branch and getting below error.
time="2017-05-02T23:10:36Z" level=info msg="Cron is set to @every 2m"
time="2017-05-02T23:11:05Z" level=error msg="Error attempting to create snapshot repository: Put https://elasticsearch:9200_snapshot/np-elasticsnapshots: invalid URL port \"9200_snapshot\""
time="2017-05-02T23:11:05Z" level=info msg="About to create snapshot..."
time="2017-05-02T23:11:05Z" level=error msg="Error attempting to create snapshot: Put https://elasticsearch:9200_snapshot/np-elasticsnapshots/snapshot_2017-05-02-23-11-05: invalid URL port \"9200_snapshot\""

URL is not delimited by a slash in this line:
https://github.com/upmc-enterprises/elasticsearch-operator/blob/master/pkg/snapshot/scheduler.go#L41
Am I missing something?
running k8s version 1.5.6

No, I think you're correct! Not sure how it worked before for me, but I've got it fixed in #26.


Curity sgnl kong blog and integration

This is a containerized demo environment with a patient records API proxied by the Kong API Gateway and protected by the Curity Identity Server and SGNL.

No specific reason. This example is based on Curity's
https://github.com/curityio/curity-kong-opa-demo . I adapted it to
integrate with our services.
I think we can remove the license and have the MIT license take precedence.
Aldo Pietropaolo
Director of Solutions Engineering
Would you like to book a meeting?
https://calendar.app.google/caGYHgiFZcjL2Txj8
On Mon, Nov 20, 2023 at 5:01 PM Erik Gustavson @.***>
wrote:

@.**** commented on this pull request.
@AldoSGNL https://github.com/AldoSGNL any specific reason for Apache vs
MIT license? We have MIT as the top-level license for the entire repo so it
might confuse things to have a license file in a sub-folder
—
Reply to this email directly, view it on GitHub
https://github.com/SGNL-ai/examples/pull/18#pullrequestreview-1740844773,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYOLCDRDQGNRYS2UOGIFAPTYFPOLFAVCNFSM6AAAAAA64Z7VGCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONBQHA2DINZXGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Good from my side


Fix typos

Mostly duplicate of #117, #149, #177, except for:
agregation → aggregation
compilier → compiler
cant't → can't
Execept → Except
application/javascipt → application/javascript
differnet → different
duplictes → duplicates


KafkaSource should provide an option to either delete a topic or to auto delete a topic on close

See #892

opened #989 for this.
one more step is to enable delete topic (which is disabled by default) in config/server.properties
delete.topic.enable=true

@kkasravi Please let me know if this works for you.
I've verified on kafka <IP_ADDRESS> that the kafka topic was deleted after close.
You can also find the delete info in kafka/logs/server.log
[2015-06-04 09:11:58,075] INFO Deleting index /tmp/kafka-logs/appnewnewnew_KafkaWordCount_topic1_0-0/00000000000000000000.index (kafka.log.OffsetIndex)
[2015-06-04 09:11:58,075] INFO Deleted log for partition [appnewnewnew_KafkaWordCount_topic1_0,0] in /tmp/kafka-logs/appnewnewnew_KafkaWordCount_topic1_0-0. (kafka.log.LogManager)

@manuzhang thanks! i'll try it out on our cluster and let you know if i run into any issue


References of Project and its ViewModel are not synchronized

Fixed in https://github.com/RobinKa/netprints/commit/6eff69776810a6efc3f7b92e1afe2c82200583e9


Added a note about no body for GET requests

Writing this in the documentation makes us more serious.

The PR is updated.
There is no workaround for this limitation BTW. It is a limitation in Buzz.

doesn't buzz have other clients than curl?
it looks like you need to add Elasticsearch to the dictionary.

doesn't buzz have other clients than curl?

True.
The PR is updated

:+1:

Thank you for merging


404 error

Challenge http://beta.freecodecamp.com/challenges/waypoint-use-bracket-notation-to-find-the-last-character-in-a-string has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
See below for screenshot of the error after entering the code correctly, hitting "Run code",  and then "Go to my next challenge".

Closing as stale


Cannot deploy app to Raspberry Pi 2 (win10 IOT Core)

In Visual Studio 2015 RC (Windows 10 Preview) an error occures while deploying:
Error : DEP0800 : The required framework "C:\Program Files\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.NET.CoreRuntime\1.0.\AppX\ARM\Microsoft.NET.CoreRuntime.1.0.appx" failed to install.

I'm sorry that the samples aren't working for you!  To help us track down the problem and fix it, can you please specify which sample you are seeing this error for?

Blinky (normal one)
I also followed steps on http://ms-iot.github.io/content/en-US/win10/samples/Blinky.htm but mainly used the code from the repo

I fixed it by reflashing the SD card. I assume it was not correctly flashed the first time because I see more Processes on the webUI


Storage: Use normal mount rather than zfs mount for ZFS volumes

Seems to work better inside the snap than zfs mount.
Signed-off-by: Thomas Parrott<EMAIL_ADDRESS>

Testsuite passed


Add a new interface net.Net

Description
With two initial implemenations

net.StdNet the functions from the standard libraries net package
vnet.Net the virtual network for testing

This PR closes #34 and clearly separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change allows users to provide their own
'net.Net' implementation for reasons like the one described in #34.
This PR changes some of the core API for this package, why we might consider bumping it to v2.
I have also prepared associated PRs for pion/ice as well as pion/turn which will be linked here shortely.
Reference issue
Fixes #34

@Sean-Der Can you unblock to CI for me? I think you already approved the idea of the PR in #168.

@Sean-Der I fixed the CI warnings. Can you re-trigger the pipeline please?

Okay, yet another try please.

I think this is ready to be merged @Sean-Der?

Hi @enobufs, @Sean-Der,
is there anything I can do to help getting this PR getting merged?
Do we need more maintainers for Pion?

@Sean-Der @at-wat Is there anything I should be aware when we bump a major version of this package?

@enobufs I already drafted a bunch of dependent PRs for other Pion packages which will use the new Net interface.
I will update those PRs once the v2 is released.

@enobufs If there are other pending breaking changes, it would be nice to include them in v2.0.0.
We can tag v2.0.0-rc.0 after this PR if there might be other changes, and tag v2.0.0 after settled.

Hi @enobufs,
I did some more work and moved the Net interface to the main package of the transport module.
I also started to extend the interface with support for TCP connections.
My goal is to extend the interface as much as we need to cover all uses of the standard Go net package throughout the various Pion packages where it makes sense:

Dial, DialUDP, DialTCP
Listen, ListenPacket, ListenTCP, ListenUDP
ResolveIPAddr, ResolveTCPAddr, ResolveUDPAddr
more?

More changes:

Harmonized return types of {stdnet,vnet}.NewNet()
Fix typos
Fix UT assertions
Add Net.InterfaceBy{Name,Index}()
Make CI pass

I did not realize earlier that this package had not even reached v1 yet.  I am thinking about this work to be the release candidate as v1. (if necessary, we could create v0 (maintenance branch) if necessary (probably not). @at-wat @Sean-Der let me know if you have any thoughts/concerns.

Once this landed on master, I will tag it as v1.0.0-beta to facilitate further work on pion/ice.

v0 may have breaking change without bumping major version according to the semantic versioning.
(I don't have strong opinion about this)

v0 may have breaking change without bumping major version according to the semantic versioning.

True. We could just bump it to v0.8.0 for now, but this package should have v1 soon.

Thanks @enobufs and @at-wat :)
I've rebased and merged the changes. I expect that we might need some more minor patches to make it work with all the other Pion modules. After that we could think about tagging v1 in my opinion.


Internal image CDN for embed images

Add a way for users to upload images directly to message.style which can then be used in embeds. There could be a small button next to each image url field which allows uploading a file and then automatically fills the url field with the url to the uploaded image.
This would most likely be a premium feature it requires (permanent?) storage for the images.

To prevent users from abusing this CDN to host their images for use outside of Discord we can check the Referer header and only allow discord.com and message.style.


pre-commit hook: drop git stash in favor of git diff

there are edge cases where git stash digests working directory and
refuses to give it back. it happened to me several times, unfortunately
i wasn't able to replicate this exact behaviour later. iirc @abuxton
also mentioned it happening, and courseware troubleshooting mentions
disappearing CWD.
for those reasons i propose dropping stash and re-implementing it using
diff. hook is modeled on this blog post:
http://jakemccrary.com/blog/2015/05/31/use-git-pre-commit-hooks-to-stop-unwanted-commits/
additionally it validates 1st commit to repo, which original hook
ignored.

Yes this is a thing.  Let me test out this hook, when I tried to fix this in the past there were weird edge cases related to having some files committed and some untracked in the working tree and other things.

:+1:

Yep, I can't get it to break.


Add lock command when the target pip supports pip install --dry-run --report

I'm going to close this as I don't think I'll ever implement it.
A defining characteristic of pip-deepfreeze is it's sync+lock with editable install, one step operation.


Error when Run the Sample Code from Google SDK to RaspberryPi 3

Hello, i create the step by step tutorial from Google SSK site to RaspberryPi 3 but when i try to run the

googlesamples-assistant-hotword --project-id my-dev-project --device-model-id my-model

e have this errors:

Traceback (most recent call last):
File "/home/pi/env/bin/googlesamples-assistant-hotword", line 11, in
sys.exit(main())
File "/home/pi/env/lib/python3.5/site-packages/googlesamples/assistant/library/hotword.py", line 139, in main
device_model_id, device_id, args.nickname)
File "/home/pi/env/lib/python3.5/site-packages/google/assistant/library/device_helpers.py", line 88, in register_device
raise RegistrationError(r, device_model_id)
google.assistant.library.device_helpers.RegistrationError: Failed to register device INVALID_ARGUMENT (400): Could not get the device instance. Project_id from side channel and project_id from url do not match.

Can someone help me with this issue?

I have the same error, I have changed project id and model id as per instruction.

The model ids do not have to relate to the project id, but model ids are universal and prefixing with the project name will help prevent name conflicts.

The model ids do not have to relate to the project id, but model ids are universal and prefixing with the project name will help prevent name conflicts.

Aren't model id auto-generated? means my project id is assi-xxyy and the model-id I found in device registration is assi-xxyy-(my-model-name)-xxyy. Am I taking any wrong value as model id then?

You can register model ids manually if you really want.


NVIDIA boards

This PR addresses #326.
This is the final outcome.

[!warning]
Quantities underlined in #ff0000 need specific review since I didn't manage to find them out or I'm uncertain about. Essentially, the RAM and the Disk space.

[!note]
I've reported the carrier boards for the form factor. Feel free to propose alternatives.

I have added the info about eMMC and SSD support for the 3 configurations

Thanks heaps @maggia80 👍🏻
I've incorporated your comments!
The only missing point is the RAM capacity of Xavier NX. Is it 16GB or 8GB?

acity of Xavier NX. Is it 16GB or 8GB?

16GB

Thanks! Fixed via the latest commit.
We can merge it.


Shakedown tests

Codecov Report

Merging #3 (cd67a9b) into main (855dab5) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #3   +/-   ##
=======================================
  Coverage   64.34%   64.34%
=======================================
  Files           6        6
  Lines         819      819
  Branches      132      132
=======================================
  Hits          527      527
  Misses        263      263
  Partials       29       29

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fixes New-Object error when host list is empty

I was getting the following error:
New-Object : The value supplied is not valid, or the property is read-only. Change the value, and then try again.
At C:\scripts\modules\drsrule\DRSRule.psm1:77 char:11

      New-Object DRSRule.VMHostGroup -Property @{

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : InvalidData: (:) [New-Object], Exception
FullyQualifiedErrorId : SetValueException,Microsoft.PowerShell.Commands.NewObjectCommand

Not sure if it is due to running PS 5 or PowerCLI 6, but tracked it down to the VMHost property.  I think the old syntax was generating some weird PSObject wrapped $null, which the DRSRule.VMHostGroup object was not able to cast correctly.

Hey, Chris, thanks for looking to make things better! As for the error that you are getting -- what is the scenario in which you are getting it? I tried to reproduce an error with Get-DrsVMHostGroup, but was not able to. You are just trying to get a VMHost group (that maybe has no VMHosts in it)?

Yeah it seems we have a group that doesn't have any hosts in it (which is a
whole different problem :)).  It looks like the problem is a change in
behavior in PowerShell v5.  The following works on v4 but not v5:
ipmo drsrule
new-object drsrule.vmhostgroup -Property @{
VMHost = $(
if($true){
get-process "boo" -ea 0
}
)
}
On Mon, Jun 29, 2015 at 8:13 PM Matt Boren<EMAIL_ADDRESS>wrote:

Hey, Chris, thanks for looking to make things better! As for the error
that you are getting -- what is the scenario in which you are getting it? I
tried to reproduce an error with Get-DrsVMHostGroup, but was not able to.
You are just trying to get a VMHost group (that maybe has no VMHosts in it)?
—
Reply to this email directly or view it on GitHub
https://github.com/PowerCLIGoodies/DRSRule/pull/1#issuecomment-116897229
.

Thanks, Chris. Added your update, and a few others (same problem in two other functions, added a changelog, and updated some tests).


Locale vs Lang (In)-Consistency

The default App of Laravel contains a lang  folder and interchangeable talks about language and locale.
Improvements:
Locale is the worlwide standard and reduces a lot of misconceptions (see below):

Renaming the "lang" to "locale" folder (Maybe this is open for discussion whats a real best practice. There are frameworks using locales others using lang. But the following two points are extremely important):
Most important: Introduce (also in the documentation) in the default App an example directory/file that uses a real "locale identifier" like en_US.php! Its fine having support for "catch all country locales" like "en_*" (in effect "en") but it should be obvious (and also explicitly stated), that laravel internally support real locales (en_US) and not just "languages".
Officialy state that laravel is build around locales (and not only languages) and encourages to use real locales (as every more standard-conform application does)!. Also the conf/app.php file does not make this abvious. To make this abvious the best would be a default settings (in app.php) like
app.locale = 'en_US',
app.fallback_locale' => 'en',
This would make it clear to everyone that full locales are supported

Why/Problems:

Standardization (with all the many benefits)
Missconceptions and Hacks: I was not aware, that laravel seems to support real locales like en_US. I ever thought (due to folder naming and documentation) that only languages is supported (like "en"). But my app internally uses real locales and I started to introduces messy hacks to convert between them.
I use some thridparty packages for translation handling: It seems they also are not aware of the laravel support of locales (due to the problems stated above). They now do not even support real locales (so I had to fork them and change a lot).

Thanks.

What are you suggesting except renaming lang to locale and en to en_US?

But my app internally uses real locales and I started to introduces messy hacks to convert between them.

Could you tell a bit more about how are you using locales and how are you converting between them?

I use some thridparty packages for translation handling: It seems they also are not aware of the laravel support of locales (due to the problems stated above). They now do not even support real locales (so I had to fork them and change a lot).

Could you link those packages and maybe your fork. What have you changed? What are your requirements?
In other words, I am asking for your opinion on how Laravel locale system could be done better because there will be probably many changes in 5.3.

I remember thinking this years ago. Personally I like translate or just t which I use in other areas.

Ideally, the Lang/Country/Locale logic can be brought in line with Symfony:
http://symfony.com/doc/current/reference/forms/types/locale.html
We currently just had a breaking change affect us in https://github.com/micheleangioni/laravel-js-lang-converter/issues/4, as that package is following the Laravel convention, which uses the Language as the Locale (unlike Symfony).

Closing since this is not actually a bug report.
For suggestions and feature requests please use the https://github.com/laravel/internals repo.


Upgrade request package

@aureooms Just curious: did you run into a problem with requests v2.74.0?

It is using an old version of the uuid package which gives an annoying deprecation message on  install. No other complaints.

@dblandin Could you do a release with this (might want to bump to 2.81.1 while you're at it)?
Request dropped support for node < 4 btw, so should be semver major

Out in 0.5.0, woo!


Fixes and more customization

Some changes that can be necessary for this addition.

More control for the user.
'%s' as a parameter for custom prop in ajax data.
Callback now can return processed ajax response

This is an amazing plugin for Materialize, awesome job!

Thank you!


Support content pack Localization

Allow content packs to have their own Localization data (sits in between valkyrie and quests).

This is required for #508


make fails

On a fresh Ubuntu 12.04 VM, with the following versions:
GNU Make 3.81
Python 2.7.3
libprotoc 2.4.1 installed at /usr/local/bin/protoc
Pin 3.17, revision 98314 installed at /home/matthew/Downloads/pin-3.17-98314-g0c048d619-gcc-linux
gcc 4.6.3
I set PROTOBUF_HOME to /usr/local
and PIN_HOME to /home/matthew/Downloads/pin-3.17-98314-g0c048d619-gcc-linux
Then, when I run make inside the maple folder, I get the error
src/core/wrapper.hpp:150:25: error: operator '>=' has no left operand
Ok, no worries, I delete the ifdef since my pin version is higher, then re-run make and get
In file included from /usr/include/c++/4.6/bits/stl_algobase.h:62:0,
                 from /usr/include/c++/4.6/tr1/unordered_map:35,
                 from src/core/static_info.h:26,
                 from src/core/execution_control.hpp:30,
                 from src/tracer/profiler.hpp:23,
                 from src/tracer/profiler.cpp:20:
/usr/include/c++/4.6/bits/cpp_type_traits.h:83:10: error: redefinition of ‘struct std::__true_type’

Since this project was last updated a few years ago, could this be caused by different versions of gcc? Or me using a later version of pin than is supported? (I see that support for Pin-2.14 was added in 2014, but this version of Pin is no longer available).
If anyone has a working version of maple, would they be able to share their system configuration so that I can get it working on a VM?
Thanks

在新的Ubuntu 12.04 VM上，具有以下版本：
GNU Make 3.81
Python 2.7.3
libprotoc 2.4.1安装在/usr/local/bin/protoc
Pin 3.17上，修订版98314安装在/home/matthew/Downloads/pin-3.17-98314-g0c048d619-gcc-linux
gcc 4.6.3上
我定PROTOBUF_HOME要/usr/local
和PIN_HOME到/home/matthew/Downloads/pin-3.17-98314-g0c048d619-gcc-linux
然后，当我make在maple文件夹中运行时，出现错误
src/core/wrapper.hpp:150:25: error: operator '>=' has no left operand
好的，不用担心，由于我的管脚版本较高，因此删除了ifdef，然后重新运行make and get
In file included from /usr/include/c++/4.6/bits/stl_algobase.h:62:0,
                 from /usr/include/c++/4.6/tr1/unordered_map:35,
                 from src/core/static_info.h:26,
                 from src/core/execution_control.hpp:30,
                 from src/tracer/profiler.hpp:23,
                 from src/tracer/profiler.cpp:20:
/usr/include/c++/4.6/bits/cpp_type_traits.h:83:10: error: redefinition of ‘struct std::__true_type’

由于该项目的更新时间是几年前，这可能是由不同版本的gcc引起的吗？还是我使用的引脚版本比支持的版本高？（我看到在2014年增加了对Pin-2.14的支持，但是此版本的Pin不再可用）。
如果任何人都拥有可运行的Maple版本，他们是否可以共享其系统配置，以便我可以在VM上运行它？
谢谢

Have you solved your problem? I have also encountered this problem. I am looking forward to your reply


Are the VoteNet, Mesh R-CNN and C3DPO in the plan?

Graet work!
Are the VoteNet, Mesh R-CNN and C3DPO in the plan?

Sorry, I do not have bandwidth to do that; I'm hoping for the community could build Det3D together!


feat(frontend): remove token store from BtcTransactionModal

Motivation
Similar to PR #3660 , the component BtcTransactionModal was using the token store to define the token to which the transaction refers too.
That means that in the unified transaction list, we will have an issue when opening the modal, specifically, the amount is not calculated.
We remove this dependency making it a prop.

[OISY-130]


⚠ ClamAV has degraded performance

In f4072a5, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 208 ms

Resolved: ClamAV performance has improved in 57da48f after 21 minutes.


Fix: fix a bunch of clippy warnings

Fix some clippy warnings by cargo clippy --fix

coverage: 80.113% (+0.1%) from 80.0% when pulling d2c7c13a3a2f6f03dcddf3ee9427fae5de2a0b83 on fix/clippy into 6892566b5d6d47999413faa4e6be1098c7925009 on master.


Logging system

Passing in a logger to the processes would be nice, and if it wrote to an actual logs file

@OR13 that would be awesome. I'd be happy to see your approach.

@OR13 you can go ahead and logging to the rest of the code if you want now.

hey, sorry for missing this.
There are a number of logging levels we can use, which can then be used to make the logs noisy or quiet as we choose.
https://github.com/winstonjs/winston#logging-levels
{
  emerg: 0,
  alert: 1,
  crit: 2,
  error: 3,
  warning: 4,
  notice: 5,
  info: 6,
  debug: 7
}

I will add logging sparingly to any work from now on, if you want to see more, just ask. I don't want to add so much it become too distracting.

Good to know. I think for now we can get away with mostly just info


inclued future package when python library is send to  in the workernode.

In related to the change in here. https://github.com/dmwm/WMCore/pull/6420
The problem occurs since the code including (builtin, past, etc)  is running in worker node. If the code is run agent there is no problem, since agent rpm has dependency on future package. But it doesn't seem that package is ported to worker node. Anyway, I will create a new issue for that.

@amaltaro, @juztas, Alan, Justas, do you know where we can control this.
Doesn't CRAB have problem with this? It is preferable to add the future package in the library we send WN. Otherwise we have to remove this import (builtins, etc) at least temporary.

hey, let me tackle this down tomorrow as high prio ;)

Well, seems to have been fixed. So closing


Add a method to SyntaxProtocol to dump a node recursively for debugging purposes

Swift’s reflection mechanism is actually really good to print syntax trees, we just need a convenient way to access it.
This produces output as can be seen in CustomReflectableTests.swift.

@swift-ci Please test


how to send mails using cloud code

Can we send mail invites using cloud code which uses mail adapter? If possible,could you share sample cloud code?

Sorry but I' ve never used cloud code in parse, I am not sure if this module works with that :S

Simply initialize it, then use sendMail() and here's a simple snippet:
https://gist.github.com/ahmedengu/60278f8293f714decdedcd66f0bc48f8


DeviceTypes page is missing a title

It seems like https://docs.resin.io/devicetypes/ is somehow missing a title - this means that if a search result includes this page in the output, you end up with an empty bullet point.
E.g. https://docs.resin.io/search-results?searchTerm=raspberry includes this HTML output:

      Getting Started With Raspberry Pi 1, Zero, or Zero W and Rust

      Supported Devices

resulting in:

which obviously looks kinda weird! (and results in a link that you can't actually click on)

Should this ticket stay open until the fix has been deployed?
https://docs.resin.io/search-results?searchTerm=raspberry


{Core} Use knack 0.8.0rc1

Description
This PR contains these sub-PRs:

{Core} Pass cli_ctx to implicit items (#16287)
{Core} Use custom tag message (#15730)
[Core] Print INFO log from SDK (#15676)

History Notes

[Core] Print INFO log from SDK (#15676)

Core

/azp run


The link of consensus.py in bigchaindb/bigchaindb/README.md is incorrect

it links to a wrong URL

Closing with #1070 merged.


Option to hide title

Title display should be optional. For example, when displaying first 12h and 12-24h in vertical grid it doesn't look nice.

In the yaml, set title: null. That will hide the title.

I love your card design. I like to drop the title as well. I tried the following yaml but still displays "Hourly Weather"
type: custom:hourly-weather
entity: weather.home_hourly
title: null
icons: true
show_wind: 'true'
show_precipitation_amounts: true
num_segments: '10'
show_precipitation_probability: true

I love your card design. I like to drop the title as well. I tried the following yaml but still displays "Hourly Weather"
type: custom:hourly-weather
entity: weather.home_hourly
title: null
icons: true
show_wind: 'true'
show_precipitation_amounts: true
num_segments: '10'
show_precipitation_probability: true

Did you save and exit edit mode?

Yes I did, thanks for the reply.

it did not

That works! thanks!


[postgres] still trying to collect metrics from other dbs even with dbstrict enabled

Output of the info page
Cut some of this out, let me know if I left off anything important
===============
Agent (v7.26.0)
===============

  Go Version: go1.14.12
  Python Version: 3.8.5
  Build arch: amd64
  Agent flavor: agent
  Check Runners: 4

  Host Info
  =========
    bootTime: 2021-03-12 13:49:23.000000 UTC
    kernelArch: x86_64
    kernelVersion: 4.4.0-1086-aws
    os: linux
    platform: ubuntu
    platformFamily: debian
    platformVersion: 20.04
    procs: 3
    uptime: 370h38m29s
    virtualizationRole: guest
    virtualizationSystem: lxc

=========
Collector
=========

  Running Checks
  ==============

    postgres (5.3.2)
    ----------------
      Instance ID: postgres:c77faf0e1fe8695f [OK]
      Configuration Source: file:/app/.apt/etc/datadog-agent/conf.d/postgres.d/conf.yaml
      Total Runs: 1
      Metric Samples: Last Run: 15, Total: 15
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 1
      Average Execution Time : 114ms
      Last Execution Date : 2021-03-28 00:27:52.000000 UTC
      Last Successful Execution Date : 2021-03-28 00:27:52.000000 UTC
      metadata:
        version.major: 13
        version.minor: 2
        version.patch: 0
        version.raw: 13.2 (Ubuntu 13.2-1.pgdg20.04+1)
        version.scheme: semver

Additional environment details (Operating System, Cloud provider, etc):
Heroku, with the heroku buildpack installed: https://github.com/DataDog/heroku-buildpack-datadog
My postgres.d/conf.yaml has the following configurations:
instances:
    ## @param dbname - string - optional - default: postgres
    ## Name of the PostgresSQL database to monitor.
    ## Note: If omitted, the default system postgres database is queried.
    #
    dbname: "d2ng60rocubth6"

    ## @param dbstrict - boolean - optional - default: false
    ## Whether to restrict the scope of the check to just the database in question.
    ## Set to `true` if you only want to gather metrics from the database provided in the dbname parameter.
    #
    dbstrict: true

Steps to reproduce the issue:

Setup a heroku dyno with a postgres instance
Configure your postgres conf to specify the dbname and dbstrict: true
See warnings roll into your logs like so:2021-03-28 00:32:38 UTC | CORE | WARN | (pkg/collector/python/datadog_agent.go:122 in LogMessage) | postgres:c77faf0e1fe8695f | (postgres.py:150) | Not all metrics may be available: permission denied for database dbiml2v4ce0j2c

Note that dbiml2v4ce0j2c in the warning does not match configured dbname: "d2ng60rocubth6"

Describe the results you received:
See above
Describe the results you expected:
No warnings, since ideally it's not trying to scan db's other than the one it's configured for.

Hi @wbobeirne,
The reason you are seeing this error is because the dbstrict option was added in postgres (5.3.3). You can follow these steps to upgrade your postgres integration with the appropriate version.


Device Form Validation with Device Type & Platform

Environment

Nautobot version (Docker tag too if applicable): 2.0.5
Python version: 3.11
Database platform, version: N/A
Middleware(s): N/A

Steps to Reproduce

Create manufacturer "Cisco"
Create Platform "Cisco IOS", assign to manufacturer "Cisco"
Create Device Type "CSR1000V", assign to manufacturer "Cisco"
Create Device "NYC-RT01", assing to CSR1000V and Cisco IOS
Attempt to change to Arista

Expected Behavior
Form validates and allows

Observed Behavior
Either fails validation or have to remove platform and edit it at second time.

I think this logic needs to be updated https://github.com/nautobot/nautobot/blob/8629dfbcb2478a3db3162c7c3c600efba6f5b42b/nautobot/dcim/forms.py#L1604

You're not able to change the manufacturer, device type and platform in a single edit form because the self.fields["platform"].queryset is populated from the existing instance's device_type, not the current device_type selected in the form.

is populated from the existing instance's device_type, not the current device_type selected in the form.

Yes, that is what my suggested code in the comment before yours attempts to address. I am not so sure that self.fields["device_type"].manufacturer will actually work, but that is the intention of it.


Describe how to create a binaryData in a configMap

This is a Feature Request
What would you like to be added
There does not seem to exist a description of how a configMap with binaryData can be created, e.g. via command line. https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-directories and the following sections describe how to create configMaps, but all examples create textual data.
Why is this needed
ConfigMaps can store binaryData, as described in the API docs. But there is no information about how to create it.
This feature is a followup from #20738. When this feature is implemented, one should make the words "use binaryData" (in the notes about the encoding used to expose configMaps as files -- see #20738) links pointing to the description of how to create binaryData.

The question is ... why do you want to create binary configmap from command line instead of from a file? How would you type in binary data from command line?

/language en

Of course nobody would type in the binary data. The config map would be created from command line using --from-file, but the examples show that the result has only the Data section is populated. So the question is: how can I force the binaryData field to be populated?

@fml2 interesting question. Looks like kubectl create configmap --from-file=... can detect the file content. However, I'm not aware of any option one can use to force the population of binaryData rather than data.

Indeed, it seems that the file contents is checked for being a valid UTF-8, see https://github.com/kubernetes/kubernetes/blob/66e3c66eafdcecc49c20f21953b2b069fc17f645/staging/src/k8s.io/kubectl/pkg/generate/versioned/configmap.go#L262-L270.
Does this mean that the binaryData (and not Data) will be automatically populated if the file contains binary data (as in "not a valid UTF-8")?

Does this mean that the binaryData (and not Data) will be automatically populated if the file contains binary data (as in "not a valid UTF-8")?

Yes, I think so.
Maybe you want to raise an issue to kubectl in the upstream repo (kubernetes/kubernetes), requesting support to explicitly specify the field to populate?

/close
This is resolved.
Please feel free to reopen if needed.

Can we please reopen this -- rather important -- topic?
The doc about creating a configMap from a folder should very clearly mention that binary data -- identified by the absence of a valid UTF-8 character -- goes into 'binaryData' while non-binary data goes into 'data'.
In all honesty, this rule is very bizarre, not logical, intransparent and IMHO not necessary since it's probably best to store any data just B64 encoded.
Btw, If you just look at LENS 6's configMap (https://k8slens.dev/) , then LENs will just show you textual data and no binaryData at all. I guess they are not even aware about this distinction.

This was described in #25986 and is now in this section: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files

support-bundle-results (2).txt


ODE - Top menu options

Problem description
We need to customize the Top menu for the ODE in all OS.
Steps to reproduce it

Open the ODE
Check the Top Menu options

Context: full list of options available here.. Also check discussion in here
Changes
Mac OS , Windows and Ubuntu
Open data editor menu

Faith, the Open Data Editor menu is too close to the name of the tool. I think we need to see if we want to keep the ODE menu.

File
Current options

Close window

Suggested changes

Add: file,External data, folder
Create folder
New project
Open project
Save

Edit
Current options

Undo
Redo
Cut
Copy
Paste
Paste and match style
Delete
Select all
Substitutions----Show substitutions
Speech ---Start speaking
Autorrelleno
Iniciar dictado
Emoji y símbolos

Suggested changes

Undo
Redo
Delete

View
Current options

Reload
Force reload
Toggle developers tool
Actual Size
Zoom in
Zoom out
Toggle Full Screen

Suggested changes

Reload
Force reload
Full Screen
Minimize

Window
Current options

Minimize
Zoom
Mover a la izquierda de la pantalla (the text is in Spanish)
Reemplazar ventana desplazada
Quitar ventana del conjunto
Bring all to front
Open data Editor

Suggested changes
Remove this menu in full
Help
Current options
It's empty.
Suggested changes

Open Data Editor User Guide

@Faithkenny Please, let's address this issue this week, of possible. I provided a suggested list of categories but I would love to have your insights.

@Faithkenny can you take a look at this tomorrow?

First thing I'm handling today. I've been thinking about it over the weekend.

@Faithkenny can you take a look at this tomorrow?

Attending to this first thing today, being thinking about it over the weekend

So I've reviewed menu items, shortcuts on similar/dissimilar apps, @romicolman's suggestions and have some recommendations
Starting with the MacOS,

Sentence case for the Top menu options
A menu item that has ellipses... at the end indicates that clicking on it will pop up a dialog
Some of the greyed out options are context aware e.g Recently Opened/History should be only available after after files have been imported. Some others like Settings... are ideas to signal what's coming in December
I agree, I also think we should take out the Window menu completely.

Here is the Figma file

To sum up. For Mac
Open Data Editor Menu

Quit Open Data Editor

File Menu

Add file
Add folder
Add external data
Delete
Publish

Edit Menu

Undo
Redo

View Menu

Reload
Metadat
Errors panel
Source

Remove the Window menu
Help Menu

ODE user guide
Report an issue (it should redirect to the new section of the user guide)

Images updated for the Pre-release version

To sum up. For Mac
Open Data Editor Menu
* Quit Open Data Editor

File Menu
* Add file

* Add folder

* Add external data

* Delete

* Publish

Edit Menu
* Undo

* Redo

View Menu
* Reload

* Force reload

* Metadat

* Errors panel

* Source

Remove the Window menu
Help Menu
* ODE user guide

* Report an issue (it should redirect to the new section of the user guide)

Hi, in the Help Menu, could you please provide the "ODE user guide" link and the "Report an issue" link? 🙏

Hi @guergana!
ODE user guide: https://opendataeditor.okfn.org/documentation/getting-started/
Report an issue: it will be a special paragraph on the user guide for that. Since we are still implementing changes, please add this link for now: https://github.com/okfn/opendataeditor

Hello, @romicolman I am confused about Reload and Force reload... These are options that are defaults of electron, but they don't seem to add any value to our app. In which cases do you think these options would be needed?

https://github.com/okfn/opendataeditor

@romicolman for the Report an issue link, shouldn't the address be https://github.com/okfn/opendataeditor/issues

We checked categories with @roll. Please, remove reload and force reload (I've already updated my comment to remove these 2 categories)

Hi @guergana! Regarding the file menu, if the user selects Add (file or folder) the ODE should display the "From my computer dialog":

Steps to reproduce it
Scenario 1

File menu
Add
New file
The ODE shows the "From my laptop" dialog

Scenario 2

File menu
Add
New older
The ODE shows the "From my laptop" dialog


chore(deps): update tubenhirn/semantic-release-gitlab docker tag to v4.0.7

This PR contains the following updates:

Package
Update
Change

tubenhirn/semantic-release-gitlab
patch
v4.0.6 -> v4.0.7

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 4.4.19 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fix condition in find_node_context_host

I believe the current condition is incorrect, because in case of balancer-s->name is shorter than the prefix, it gets included for node->mess.balancer even though they don't match.
In combination with #267 it prevents 404 when the node is up but without app (yet).

Should we have if (strlen(balancer->s->name) <= BALANCER_PREFIX_LENGTH) { continue; } if (strcasecmp(&balancer->s->name[BALANCER_PREFIX_LENGTH], node->mess.balancer) != 0) { continue; } The test for strlen() is to check that the strcasecmp is not comparing somewhere outside the balancer->s->name... Is that even possible?

The proposed change is equivalent to the two ifs you wrote if I read that correctly.
For the second part I don't think it's possible because BALANCER_PREFIX_LENGTH is smaller than the array size. However, I thought that the strlen should prevent reading invalid balancer names (e.g. if we have a valid balancer name for which we change the first char to \0, we would catch it with the strlen but wouldn't without it).