Configuration for a particular spinnaker system can be written in a number of different files. Is precedence documentation available?
e.g. for clouddriver:
/opt/spinnaker/config/clouddriver.yml
/opt/spinnaker/config/clouddriver-local.yml
/opt/clouddriver/config/clouddriver.yml
or settings can be in the provider section of
/opt/spinnaker/config/spinnaker-local.yml
I wrote a blog post on this very topic a while back, because several users were getting confused:
https://www.travistomsu.com/2016/12/19/configuring-spinnaker/
The gist is that there are various levels of shared settings (with overrides) and service-specific settings (with overrides).
The order of loading looks like:
spinnaker.yaml (shared across all services, do not edit - will be overwritten on update)
spinnaker-local.yaml (override across all services, editable)
service.yaml (service-specific, do not edit)
service-local.yaml (override for this particular service, editable)
As per my comment I found the documentation here
Based on that, even though there is no mention of /opt/subsystem/config/subsystem.yml I will go with using /opt/spinnaker/config/clouddriver-local.yml
Related
I'm trying to figure out if FeathersJS suits my needs. I have looked at several examples and use cases. FeathersJS uses a set of request methods : find, get, create, update, patch and delete. No other methods let alone custom methods can be implemented and used, as confirmed on this other SO post..
Let's imagine this application where users can save their app settings. Careless of following method conventions, I would create an endpoint describing the action that is performed by the user. In this case, we could have, for instance: /saveSettings. Knowing there won't be any setting-finding, -creation, -updating (only some -patching) or -deleting. I might also need a /getSettings route.
My question is: can every action be reduced down to these request methods? To me, these actions are strongly bound to a specific collection/model. Sometimes, we need to create actions that are not bound to a single collection and could potentially interact with more than one collection/model.
For this example, I'm guessing it would be translated in FeathersJS with a service named Setting which would hold two methods: get() and a patch().
If that is the correct approach, it looks to me as if this solution is more server-oriented than client-oriented in the sense that we have to know, client-side, what underlying collection is going to get changed or affected. It feels like we are losing some level of freedom by not having some kind of routing between endpoints and services (like we have in vanilla ExpressJS).
Here's another example: I have a game character that can skill-up. When the user decides to skill-up a particular skill, a request is sent to the server. This endpoint can look like POST: /skillUp What would it be in FeathersJS? by implementing SkillUpService#create?
I hope you get the issue I'm trying to highlight here. Do you have some ideas to share or recommendations on how to organize the API in this particular framework?
I'm not an expert of featherJs, but if you build your database and models with a good logic,
these methods are all you need :
for the settings example, saveSettings corresponds to setting.patch({options}) so to the route settings/:id?options (method PATCH) since the user already has some default settings (created whith the user). getSetting would correspond to setting.find(query)
To create the user AND the settings, I guess you have a method to call setting.create({defaultOptions}) when the user CREATE route is called. This would be the right way.
for the skillUp route, depends on the conception of your database, but I guess it would be something like a table that gives you the level/skills/character, so you need a service for this specific table and to call skillLevel.patch({character, level})
In addition to the correct answer that #gui3 has already given, it is probably worth pointing out that Feathers is intentionally restricting in order to help you create RESTful APIs which focus on resources (data) and a known set of methods you can execute on them.
Aside from the answer you linked, this is also explained in more detail in the FAQ and an introduction to REST API design and why Feathers does what it does can be found in this article: Design patterns for modern web APIs. These are best practises that helped scale the internet (specifically the HTTP protocol) to what it is today and can work really well for creating APIs. If you still want to use the routes you are suggesting (which a not RESTful) then Feathers is not the right tool for the job.
One strategy you may want to consider is using a request parameter in a POST body such as { "action": "type" } and use a switch statement to conditionally perform the desired action. An example of this strategy is discussed in this tutorial.
I know that local.Properties overrides project.Properties.
I also know that that these files define… database connections, ports, build environment, frontend HTTPS, etc.
I further know that project.Properties contains more properties.
Will appreciate if Hybris experts tell me syntax of local.Properties, illustrating with some example.
Please provide correct info.
If we talk about the syntaxes of entries in the project.properties file, then it is key=value
The property files in the hybris are of two types:
The extension level - The property file project.properties is the configuration file that carries properties in the key-value pair for the configurations involved on the extension level For instance, Consider a property in the project.properties of the yacceleratorstorefront (storefront template) extension storefront.storelocator.pageSize.Desktop=10 which clearly indicates the 'StoreLocator' results page size configuration per store. Since the store locator functionality is specific to the storefront and has no relevance for the other modules (like core, facades etc), the property is kept at the extension level.
Please note, project.properties reside in the extension folder
The global level - This is the property file which is the global configuration file, and deals with the properties are extension agnostic and carry a global impact. For instance the property commerceservices.default.desktop.ui.experience=responsive sets the ui experience to responsive mode that specifies the deployment to be for the responsive format.
The local.property file supersedes all of the properties with the same key that is defined in any of the project.proprties.
Please note, the local.properties file reside in the hybris/config folder
The hybris registry creates a property configuration map which constitutes all of the properties mentioned in the deployment configuration. The same could be managed in the HAC under platform/configuration.
The clear intent of the local.proprties file is to have information which either requires to be overriden on a global level. The override may be of different types, e.g. cart expiry time could be made different on different environments by the use of the local.property files.
For further reading, please refer to the link: https://wiki.hybris.com/display/release5/Configuring+the+Behavior+of+the+hybris+Commerce+Suite
property call hierarchy (from primary to secondary):
java -Dproperty.key=something
hybris/config/local.properties
hybris/*/(extension-name)/project.properties
hybris/bin/platform/project.properties
and within java code:
configService.getString("property.key", "last fallback value, if no propertyfile provide this key");
You could review all current variables using the hac interface for properties: http://localhost:9001/platform/config
What's the best practice when you have dependencies that you want to be able to configure when creating a PowerShell module in C#?
My specific scenario is that the PowerShell module I am creating via C# code will use a WCF service. Hence, the service's URL must be something that the clients can configure.
Is there a standard approach on this? Or will this be something that must be custom implemented?
A somewhat standard way to do this is to allow a value to be provided as a parameter or default to reading special variable via PSCmdlet's GetVariableValue. This is what the built-in Send-MailMessage cmdlet does. It reads the variable PSEmailServer if no server is provided.
I might not be understanding your question. So I'll posit a few scenarios:
You PS module will always use the same WCF endpoint. In that case you could hardcode the URL in the module
You have a limited number of endpoints to choose from, and there's some algorithm or best practice to associate an endpoint with a particular user, such as the closest geographically, based on the dept or division the user is in, etc.
It's completely up to the end user's preference to choose a URL.
For case #2, I suggest you implement the algorithm/best practice and save the result someplace - as part of the module install.
For case #3, using an environment variable seems reasonable, or a registry setting, or a file in one of the user's profile directories. Probably more important than where you persist the data though, is the interface you give users to change the setting. For example if you used an environment variable, it would be less friendly to tell the user to go to Control Panel, System, Advanced, Environment, User variable, New..., than to provide a simple PS function to change the URL. In fact I'd say providing a cmdlet/function to perform configuration is the closest to a "standard" I can think of.
I want to do custom configuration parameters in config.yml
Example:
In config.yml file
security_enhancement:
authentication:true
authorization:true
In same format like swiftmailer configuration etc.I'm not getting idea how to define.
I'm getting error like:
1/2 ParseException: Unable to parse in "\/var\/www\/demo\/app\/config\/config.yml" at line 217 (near "authentication:true").
Am I missing something here? Is it necessary to add in depending injection extension file? .Actually I want to enable disable authentication,authorization execution during dev mode which is implemented in listener which can be done using config_dev.yml . I don't want to add under Parameters. Any suggestions?
As you've rightly theorised, you do indeed need to add in DI extension files, assuming your configuration relates to particular bundles (which it almost certain will).
Whilst parameters can simply be defined at will, configuration features hierarchical structure and validation.
Usually, configuration is used to in turn, define parameters, but it allows for the values to be parsed and validated prior to their instantiation, so that bundle writers can provide better guidance as to how their services can be used (with meaningful errors), and trust the values that are being passed into them.
A decent read on how to get started with config component can be found in the Symfony2 docs: defining and processing configuration files with the config component.
I have set up a Content Type Hub and tested the syndication is working correctly by creating a test content type and watching it be published to the client site.
Then I deployed the content types I am actually interested in publishing to the hub (by way of a feature) along with the site columns they depend on.
I get the error
Content type '...' cannot be published to this site because feature '...' is not enabled.
I want to deploy content types with features for upgradability and ease of porting between dev, qual and prod environments. But am left not understanding what the benefit of the Hub is.
If I have to activate the deploying feature, the content types will already be on the site before publishing will take place. If I have to manually create the content types on the Hub site with the web UI (yuck!), I have the issue of trying to keep three landscapes manually synchronized.
Is there a way to efficiently manage content type deployment to the Hub while still using the Hub to publish the content types?
The advantage of using the Content Type Hub, is that it allows you to use and reuse your Content Types over multiple site collections and Web Applications throughout your farm.
Because all of your site collections are now using instances of the same syndicated content types, if, in the future, you need to add/remove/rename columns within the content types, this is done as easily as updating the content type, and resubscribing (then allowing sharepoint to run its timer jobs, and double checking that the changes updated because you're a careful SharePoint administrator).
I am not sure which error you are receiving, there simply isn't enough context in your post. However, I think you may be slightly confused on how syndicated content types are published. First, you turn on the content syndication hub publishing feature on the site collection that holds all of the content types you are going to reuse throughout your farm. Next you configure the mixed metadata service, so that SharePoint loads each of your content types "into memory" more or less.
After this step, you get to choose which site collections you want to subscribe to the syndication hub. To do this, you need to turn on the content type publishing site collection feature. Note: If you use blank templates for your sites you may receive a feature error like you've described, due to a "flaw" with blank templates. See my post at: http://www.thesharepointblog.net/Lists/Posts/Post.aspx?ID=109
Only AFTER you've turned on the subscribing feature, And content Type Hub timer job has run, AND the subscribing timer job has run, will your site collection see the available content types.
As for manually creating content types on the hub site, the only OOB way of doing this is to use the UI. Personally, I wrote a utility that does everything I just described for me, from creating the initial content types, to creating the syndication hub, publishing them to all of the site collections, and most time consumingly, associating them with all of the lists and libraries on the subscribing site collections. I had intended for my employing company to sell it, but as they don't seem interested, I could open source it if there is enough interest.
Hope this was helpful.
This looks like a shortcoming of the hub, indeed.
I've witnessed it before.
If you've deployed your content type to the hub, please check if the INHERITS tag of the content type element is set to TRUE. Otherwise it won't work in a hub.
<ContentType ID="xxxxx"
Name="xxxx"
Group="xxxx"
Description="xxxx"
Inherits="TRUE"
Version="0">
</ContentType>
Don't forget that you can actually synchronize the content types BETWEEN farms -- this is especially valuable when you are developing on a separate farm and don't want to hassle with a PnP Framework for managing your content types... In some cases, the Content Type may already exist on the production farm and you need a copy of them on dev and/or test..