Starting and stopping services in vespa - vespa

In the benchmarking page "https://docs.vespa.ai/en/performance/vespa-benchmarking.html" it is given that we need to restart the services after we increase the persearch thread using the commands vespa-stop-services and vespa-start-services.
Could you tell us if we need to do this on all the content nodes or just the config nodes?

When deploying a change that requires a restart, the deploy command will list the actions you need to take. For example when changing the global per search thread setting changing from 2 to 5 in the below example:
curl --header Content-Type:application/zip --data-binary #target/application.zip localhost:19071/application/v2/tenant/default/prepareandactivate |jq .
{
"log": [
{
"time": 1645036778830,
"level": "WARNING",
"message": "Change(s) between active and new application that require restart:\nIn cluster 'mycluster' of type 'search':\n Restart services of type 'searchnode' because:\n 1) # Number of threads used per search\nproton.numthreadspersearch has changed from 2 to 5\n"
}
],
"tenant": "default",
"url": "http://localhost:19071/application/v2/tenant/default/application/default/environment/prod/region/default/instance/default",
"message": "Session 8 for tenant 'default' prepared and activated.",
"configChangeActions": {
"restart": [
{
"clusterName": "mycluster",
"clusterType": "search",
"serviceType": "searchnode",
"messages": [
"# Number of threads used per search\nproton.numthreadspersearch has changed from 2 to 5"
],
"services": [
{
"serviceName": "searchnode",
"serviceType": "searchnode",
"configId": "mycluster/search/cluster.mycluster/0",
"hostName": "vespa-container"
}
]
}
],
"refeed": [],
"reindex": []
}
}

Related

Using Volttron aggregation agent

I'm trying to get the aggregate agent to work with timescale db.
https://volttron.readthedocs.io/en/main/developing-volttron/developing-agents/specifications/aggregate.html
I have a file aggregation.config
{
"connection": {
"type": "postgresql",
"params": {
"dbname": "volttrondb",
"host": "127.0.0.1",
"port": 5432,
"user": "user",
"password": "password",
"timescale_dialect": true
}
},
"aggregations":[
# list of aggregation groups each with unique aggregation_period and
# list of points that needs to be collected
{
"aggregation_period": "1h",
"use_calendar_time_periods": true,
"utc_collection_start_time":"2016-03-01T01:15:01.000000",
"points": [
{
"topic_names": ["campus/building/fake/EKG_Cos", "campus/building/fake/EKG_Sin"],
"aggregation_topic_name":"campus/building/fake/avg_of_EKG_Cos_EKG_Sin",
"aggregation_type": "avg",
"min_count": 2
}
]
}
]
}
And run the following command
vctl install services/core/SQLAggregateHistorian/ --tag aggregate-historian -c config/aggregation.config --start
It starts correctly - the vctl status shows it running and there are no errors in the log.
I do not see the point campus/building/fake/avg_of_EKG_Cos_EKG_Sin in the topics table.
Any suggestions?

How does Google Smart Home determine channelNumber for action.devices.commands.selectChannel?

Created Google Smart Home Action.
Implemented device with:
a. deviceType = action.devices.types.SETTOP
b. deviceTrait = action.devices.traits.Channel
Device is successfully discovered and added to Google Home App's Homegraph.
User sends command: "Ok Google, change to ESPN"
Receives the following json in fulfillment URL:
{
"requestId": "[RequestId GUID]",
"inputs": [{
"intent": "action.devices.EXECUTE",
"payload": {
"commands": [{
"devices": [{
"id": "[SettopBox device Id]"
}],
"execution": [{
"command": "action.devices.commands.selectChannel",
"params": {
"channelCode": "espn",
"channelName": "ESPN",
"channelNumber": "206"
}
}]
}]
}
}]
}
Questions:
How does Google Smart Home determine the "channelNumber" value for "ESPN"? The user's command was "Ok Google, change to "ESPN". This does not contain any information about the channel number.
If a provider was set automatically, is there a setting in Google Home or Google Assistant to change this provider?
The number of a channel for the Channel trait is provided in the SYNC request along with any relevant labels.
{
"availableChannels": [
{
"key": "ktvu2",
"names": [
"Fox",
"KTVU"
],
"number": "2"
},
{
"key": "abc1",
"names": [
"ABC",
"ABC East"
],
"number": "4-11"
}
]
}
As shown in the snippet, the channel number comes from the service. This may be up to the developer of the integration how these numbers may be determined, whether from a cable provider or over-the-air. The field is optional, so a service without channel numbers may still work by saying its name.

ARM Template deployment - CosmosDB provision fails with - Request rate is large. More Request Units may be needed, so no changes were made

I tried deploying cosmosDB and when I first create it I get this error -
"Request rate is large. More Request Units may be needed, so no changes were made"
After redeploying it works.
But the initial creation doesn't.
I extended the throughput to 50000 (autoscale)
and 10000 with fixed size.
Is there another option to extend the RUs?
"type": "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers",
"apiVersion": "2020-03-01",
"name": "
"dependsOn":
],
"properties": {
"resource": {
"id": "subscriptions",
"indexingPolicy": {
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/\"_etag\"/?"
}
],
"spatialIndexes": [
{
"path": "/*",
"types": ["Point", "LineString", "Polygon", "MultiPolygon"]
}
]
},
"partitionKey": {
"paths": ["/partitionKey"],
"kind": "Hash"
},
"uniqueKeyPolicy": {
"uniqueKeys": []
},
"conflictResolutionPolicy": {
"mode": "LastWriterWins",
"conflictResolutionPath": "/_ts"
}
},
"options": {
"autoscaleSettings": {
"maxThroughput": 50000
}
}
}
The error message indicates that there was a large number of requests hitting the master partition for your account. This can be caused by other clients querying the database resource to list containers or querying containers to get it's properties. It can also happen when you are deploying a large number of Cosmos resources at the same time. This is mostly a transient issue and is hard to reproduce.
Your arm template for this container looks correct. I'm guessing you've purposely removed the name and depends on parameters.
I would update the api-version to 2020-04-01 however. There are issues with 2020-03-01 with autoscale and that api-version is going to be deprecated in the future.

Alexa Smart Home "Failed to Retrieve State"

I am playing with a sample Alexa Smart Home skill - I am not talking to any real hardware or back-end, just trying to get message flow working. I have set up a simple switch/plug/light that can just support turning On/Off - and I have account linked working and the skill enabled. When I try looking at it via the Alexa app on phone or web (with debug enabled) it always says the device isn't responding, or it's "Failed to Retrieve State". I can definitely see the messages in Cloud Watch as follows.
Any idea why I'd be chronically getting such a response??
Request:
"directive": {
"endpoint": {
"cookie": {},
"endpointId": "endpoint-003",
"scope": {
"token": "<<<SUPRESSING>>",
"type": "BearerToken"
}
},
"header": {
"correlationToken": "<<SHORTENED>>",
"messageId": "50397414-bb9d-412f-8a2c-15669978ab64",
"name": "ReportState",
"namespace": "Alexa",
"payloadVersion": "3"
},
"payload": {}
}
}
Response:
{
"context": {
"properties": [
{
"name": "connectivity",
"namespace": "Alexa.EndpointHealth",
"timeOfSample": "2020-06-29T16:49:59.00Z",
"uncertaintyInMilliseconds": 0,
"value": "OK"
},
{
"name": "powerState",
"namespace": "Alexa.PowerController",
"timeOfSample": "2020-06-29T16:49:59.00Z",
"uncertaintyInMilliseconds": 0,
"value": "ON"
}
]
},
"event": {
"endpoint": {
"endpointId": "endpoint-003",
"scope": {
"token": "Alexa-access-token",
"type": "BearerToken"
}
},
"header": {
"correlationToken": "<<SHORTENED>>",
"messageId": "7a8b9a71-adda-41b8-acba-4d3855374845",
"name": "Response",
"namespace": "Alexa",
"payloadVersion": "3"
},
"payload": {}
}
}
Problem was: The "name" in my header response should have been "ReportState". "Response" is only used for things that set/change values.
My general advice is to always verify that THREE things are good:
Initial "Discovery"
"Response" messages
General "ReportState" queries.
By this - I mean that:
Anything you advertised as should be reported in "discovery" better be reported in other ("ReportState") messages. If you advertise a "PowerController" - if your ReportStates don't contain status for that, you'll either not see the status, or it'll keep retrying forever (continuing to look for it) - or you might get some sort of an error.
If you CHANGED your discovery stuff - make sure that you really removed, re-discovered, and that the states (above) for the new additions/removals are okay
Always make sure that "EndpointHealth" is being reported.

IBM CLOUD function action took too long to respond in IBM watson chat dialog

Hi, I am creating a chatbot. I developed a IBM cloud function(action) in IBM.
This is the action code..
{
"context": {
"my_creds": {
"user": "ssssssssssssssssss",
"password": "sssssssssssssssssssssss"
}
},
"output": {
"generic": [
{
"values": [
{
"text": ""
}
],
"response_type": "text",
"selection_policy": "sequential"
}
]
},
"actions": [
{
"name": "ssssssssssss/user-detail",
"type": "server",
"parameters": {
"name": "<?input.text?>",
"lastname": "<?input.text?>"
},
"credentials": "$my_creds",
"result_variable": "$my_result"
}
]
}
Now my action user detail is giving response when i am invoking the code.
But when i am checking the output with my chatbot I am getting execution of cloud functions action took too long.
There is currently a 5 second limitation on processing time for a cloud function being called from a dialog node. If your process will need longer than this, you'll need to do it client side through your application layer.

Resources