Is it possible to specify a set-based label selector for a replication controller? I cannot figure out the syntax to do so in the request json. I can't find anything in the documentation, so if you have a link to the appropriate documentation, that would be helpful.
This is something we want to support, and is/was underway (see PR 7053), but it is not yet possible.
You can observe the status/progress on:
https://github.com/kubernetes/kubernetes/issues/341
It's possible to work around the lack of this feature by creating a new label that would match the selector you'd like and then create a trivial selector that matches that new label.
FYI, you can see the API specification for ReplicationController's spec here:
http://kubernetes.io/v1.0/docs/api-reference/definitions.html#_v1_replicationcontrollerspec
The schema is listed as "any", but it's actually a map of string to string, like labels.
Related
I could not understand what the package can do, the offical doc show nothing about unstructured. What the package used for ? Is it used for converting map[string]interface{} to K8S Obj ?
https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured
It looks like unstructured provides an interface to kubernetes objects, when you don't know object type upfront, i.e. dynamic package in client-go uses it extensively
As #kseniia-churiumova suggested it is used when you don't know the object type. Here is the use case to understand it better. Let us say your organisation has a policy that all Kubernetes object must have annotation "owner" with value pointing to email ID of a person or group. You have tasked with finding all the resources that violates this policy.
You can have a configuration file that has list of GroupVersionKind and use unstructured to query them. If a new type needs a check you can add to configuration without changing the code.
Note: This is just an example. In production you will have to use something like Gatekeeper that implements OPA specification to enforce policies.
I was just curious to know if it's by any means possible to add a sort functionality to the default find action of a model without overriding the same in the controller ?
We do have beforeCreate and afterCreate features in the models which is quite useful in many cases. Similarly beforeFetch or something like that, if exists can be really useful when we want some pre/post processing on the result set while doing a get request.
An example of this would be: localhost:1337/user?sort=id desc
I've been working on a component and currently I'm trying to do different things based on the selector chosen for the component.
So basically if I have a component with this structure
myComponent/
dialog.xml
myComponent.jsp
altView.jsp
I know that if I have a Node with resourceType myComponent I can request the alt view via browser by requesting "path/to/component/content.altView.html" and everything is hunky dory.
Similarly I can do a cq include and do something like:
# with cq include
<cq:include path="my/path.altView" resourceType="myComponent"/>
# or with sling include
<sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
However, when I'm handling the request, I've seen some interesting behavior when looking at the RequestPathInfo Object.
For example, if we look at all 3 of the above cases I might have something like this:
# http://path/to/component/content.altView.html
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <cq:include path="my/path.altView" resourceType="myComponent"/>
slingRequest.getRequestPathInfo().getSelectors(); // []
slingRequest.getRequestPathInfo().getExtension(); // altView
I understand why the cq:include returns different results (we're making a request to my/path.altView and .altView coincidentally serves as the extension in this case). I'm curious if there is a normalized why to pull "altView" (or the selected view) regardless of if it's been used as an extension or selector. Or if this is normal and I just need to check both the extensions and selectors individually.
i.e
selectors = get selectors();
if selectors
do stuff
else check extensions
do stuff
Again thank you very much for your insights, this community is awesome.
[EDIT]
In response to an answer, I thought I'd give a little more context to what I'm doing. Basically our component structure is set up so that each of our components has an associated Java Class that handles the business logic. (I.E. apps/myapp/components/myComponent will map to com.mypackage.components.MyComponent) That said, within my component's Class I need to handle the control flow differently depending on how the component was called (i.e. what selectors/extensions/etc). For example, if my component was called normally I'd do the base behavior, but if it was called with selector (for exmaple) "altView" I would need to handle the alternative view differently, and in this alternative view different data will be available, etc.
My question was along the basis that it seems that i can give the "path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/>
However, when I check my RequestPathInfo in my component class to decide workflow, "altView" is returned as the extension, not within the String[] selectors. Note, the above compiles fine, and it selectors the correct .jsp file for rendering, the RequestPathInfo object just stores the data in a different place.
I'm starting to guess that places the selector into the path attribute works because the selectors and extensions modifiers alter the behavior vary similarly. mycomponent.altView.html resolves to altView.jsp whereas if I was to do mycomponent.altView it would also attempt to resolve a mycomponent/altView.jsp just as it would do the same for mycomponent.xml to mycomponent/XML.jsp
It seems like you're kind of working around Sling resolution. The easiest way to do "different things based on selector" in a given component (let's say my/new/component) is to create different renderers.
For example, say I am requesting /content/app/page.html, and on that page was the component my/new/component. Or if I request /content/app/page.selector.html, I want a slightly different experience for my/new/component.
In the cq:component, I would create two JSPs: component.jsp and component.selector.jsp. Sling will automatically know, based on the selector in the request, which renderer to use. Obviously each renderer can produce a different experience.
The same is true for extension. In the example, component.jsp and component.selector.jsp are actually equivalent to component.HTML.jsp and component.selector.HTML.jsp. The HTML is just implied. However, you could do component.XML.jsp and component.selector.XML.jsp and Sling will again, pick the most relevant selector, based on the selector(s) and extension of the request.
Now, what if you don't want the selector to show up in the page request's URL (in my opinion you shouldn't)...
You can include your component using sling:include and add the selector, like you've done.
The caveat is that sling:include works a little differently than cq:include, so only use this when you need to. Instead, you could also use Sling mapping to hide the selector from the user. The majority of the time I would recommend this approach.
I'm not sure what you were trying to do with adding the selector to the "path" attribute. I don't think that would do anything. The "path" is defining the resource name (and the node name if the resource is not synthetic). Including the selector in that wouldn't do anything, except make the resource name include a period and the selector.
My question was along the basis that it seems that i can give the
"path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/> However, when I check my RequestPathInfo in my component class to
decide workflow, "altView" is returned as the extension, not within
the String[] selectors.
As opposed to the cq:include tag, you could alternatively use sling:include tag, which provides attributes to modify the selectors & suffix on the request:
<sling:include resourceType="myComponent" path="my/path" addSelectors="altView"/>
or
<sling:include resourceType="myComponent" path="my/path" replaceSelectors="altView"/>
If you already have selectors on the request that you don't want to apply to myComponent.
In terms of the differences between Sling include & CQ include, there seems to be very little, apart from the latter also supporting script inclusion. From the docs:
Should you use <cq:include> or <sling:include>?
When developing AEM components, Adobe recommends that you use
<cq:include>.
<cq:include> allows you to directly include script files
by their name when using the script attribute. This takes component
and resource type inheritance into account, and is often simpler than
strict adherence to Sling's script resolution using selectors and
extensions.
After looking around for a while I was able to understand how the json: tags are used in the Go language. However two tags I have come across I'm still lost on, and can't seem to find documentation on it.
Both pertain to a REST api service and the full code can be found here-> code.google.com
What is the root: tag used for
gorest.RestService `root:"/orders-service/" consumes:"application/json" produces:"application/json"`
as well how does the method: tag work?
userDetails gorest.EndPoint `method:"GET" path:"/users/{Id:int}" output:"User"`
I didn't know if anyone had any links to a site or document that might explain this more, from the examples I can learn enough to use it. However, I would really like to fully understand it.
Thanks for your time!
Tags are nothing but strings, they don't have any meaning per-se.
Libraries can use reflection to introspect struct fields and interpret their tags. See reflect.StructTag.
In your case, gorest parses the following tags on Services:
root
consumes
produces
and these on Endpoints:
realm
method
path
output
input
role
postdata
Their meaning is described in gorest's documentation.
These are gorest tags. See gorest wiki http://code.google.com/p/gorest/wiki/GettingStarted
Is there any way I can use the format_number_choice function inside of a actions file. In fact I need to use it for a Form error message.
'max_size' => 'File is too large (maximum is %max_size% bytes).',
In English it's simply "bytes", but in other languages the syntax changes after a certain value (for example if the number is greater than 20 it's: "20 of bytes").
I can use parenthesis, of course, but if the framework offers support for doing this specific thing, why not to use it?!
The way it's currently implemented in the 1.4 branch, you can define only one translation per message using il18n XML files.
What you could do is create a custom validator which inherits the current validator (sfValidatorFile in your example) and does the size checking in the doClean method before calling its parent's method.
I suggest you take a look at the source to see how it works : sfValidatorFile
The correct way to handle number ranges for translation is explained here in the Definitive Guide. I won't reproduce it here as the documentation itself is clear and concise. Note however that the string is not extracted automatically by the i18n-extract task, so you need to add it manually - again, the documentation explains this.
So yes, you can use the format_number_choice() function inside an action - you just need to load the helper inside the action like this:
sfContext::getInstance()->getConfiguration()->loadHelpers('I18N');