I'm trying to create a build and release to a actors service in Visual Studio Online. I already created build and release to anothers services fabric without problem. But with this specific service I getting the error below:
The BuildLayout of the application in E:\SFabric\SP\SP2DS\Fabric\work\ImageBuilderProxy\AppType\SchedulerServiceAppType is invalid. Config is missing for service SchedulerServicePkg.
The first time the release works fine, but after the first version is released, the others releases I got this error.
The others services are Stateless, I dont know why this problem happens and just with this service that is Stateful.
New Information
I'm trying to change advantages setting and I got successful sometimes.
Even that, I want to know how I do correctly
# Novac - Just noticed a duplicate post on Github addressing this specific issue. More importantly, a member of Azure's Service Fabric Dev team is actively engaged and waiting for your response to his followup questions - ref snip below:
Currently tracked via GitHub issue:https://github.com/Azure/service-fabric-issues/issues/802. Strongly recommend redirecting this conversation to the Github thread/url above.
Related
When one creates an ASP.NET Core Web API in Visual Studio 2022, and tests it locally, one gets a convenient Swagger page built upon an OpenAPI definition, to test all HTTP endpoints.
However, when deployed and trying to access {path-to-api}/swagger, it returns a 404 Not Found error, even while on localhost, when both the API and the database is sitting on my own machine. Even if the database is in the Azure cloud, for that matter, it also works, if I put the Azure SQL Database connection string into appsettings.json.
So is there a way to achieve this, preferably without too much hassle? Or am I wrong in wanting this, do developers mostly test their APIs locally? Because I want the Swagger API online only for testing.
The problem is getting and using the swagger functionality into the cloud. Is it possible and good practice?
If you look at the startup, you will notice that the swagger is only loaded during a development session via an if check. Commenting that out, or expanding it based on evironment, will allow a published version to generate the page on the target host.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
I generally do that for first publishes or to Dev/Test environments to see it running. Once it is not needed, I un-comment it back in.
Also it may be actually viable (turned on) in Dev or UAT server because one is also publishing the open api it to APIM (Azure api manager), which takes the api and generates its own development environment; away from an initial publish.
Also once published, it is not the default page, one still has to path to it such as .../swagger/index.html.
I'm aborting this mission to deploy the Swagger interface to Azure along with my API. It's bad security practice to make the HTTP request methods so visually available to all. So the answer to my question do developers mostly test their APIs locally, is apparently yes.
I wondered if I should remove the question, but I would like to make it still stand, in case anyone else is contemplating about doing the same thing - exposing an API online with the Swagger UI.
I recently deployed a Next.js application for a software engineering boot camp. I am using Vercel for hosting the web app. The problem I am having has been spoken about on the internet before. However, I couldn't find much helpful information.
When I look at the real-time logs for my application from my Vercel dashboard, a 504 error gets thrown for multiple API routes I have created. I am aware that Vercel places restrictions on requests depending on the hosting plan someone subscribes to. However, I can't help but wonder if I have overlooked an important step when deploying my application.
When deploying my application, I did the following things:
Connected a session store to my MongoDB database.
Created a password-protected MongoDB Atlas account (credentials are environment variables).
White-listed all IP addresses so that any user can interact with their portion of the database.
I would appreciate help finding out if these errors are my fault and if there is anything I can do about them or if they are solely caused by the restrictions of the "Hobby" plan.
Thank you very much in advance,
-Sam
Screen Shot:
I had a similar issue, turned out, it was just the fact that I did not add the vercel ip addr to the network access page on mongodb so momgodb was blocking vercel from accessing data.
You need to integrate MongoDB in your project on Vercel.
Go to your project settings in Vercel and go to the Integrations tab. Click the Browse Marketplace button and find MongoDb. Click Add Integration button and follow the instructions.
Hope this helps... I know this was asked quite a while ago.
You have to troubleshoot the issue by doing the following
Eliminate the NextJS app out of the equation - Using postman https://www.postman.com/downloads/ - Confirm the output of your API, what is the time the API takes? Given function invocation has a limit, you need to optimize the API to meet the threshold.
If the API times are fine and resolution occurs outside of your app, the next step is to troubleshoot the API route, remove the DB parts and just echo back a success message and check the function invocation time.
If #2 turns out to be the issue, reach out to vercel support - Another option could be hosting it outside and whitelisting the cross domain API ask from your application.
We want to execute external integration tests and manually call a rollback if something is wrong.
We're using the 'Service Fabric Application Deployment' task in Team Services (VSTS) and it seems to only keep the latest in the cluster.
Cluster --> Applications --> [Application], and then under Essentials. Only one row item is listed which shows the latest version.
Also, attempting Start-ServiceFabricApplicationUpgrade results in 'Application type and version not found.'
How do we alter the behaviour of previous version retention of application types? (And what is the default?)
I don't have the answer to your question, but I do offer this thought:
While I understand there may be a valid use case out there for trying to do this, I think a more accepted approach is to set up a test environment that matches production very closely. Deploy to test and test the heck out of it before approving the deployment to production.
One of the main selling points of Service Fabric is its ability to be so redundant, yet with your proposed workflow you are deploying code to that environment in which you're not entirely confident in. I think that really goes against what Service Fabric offers you.
Since you will be testing it so thoroughly on the Test environment, hopefully anything you end up finding in Production is small enough to be fixed through a patch a few hours later or however fast you can fix it.
I'm trying to setup an integration between my GitHub and VSTS account.
I'm creating a build definition to build and deploy my code to my azure web app. From all the things I've read online (I've been trying to make this work for at least some 3h now) this should be so simple I'm reconsidering calling myself a developer... =/
I've added the Service Endpoint:
But it doesn't show up at the build definition:
The other service endpoints for azure work fine, I'm able to set them at the build definition, but the GitHub just won't work! I've tried signing out, using chrome's private window, removing and re-adding the endpoint, using IE, nothing makes that damn thing show up as an option in the dropdown.
Does anyone have any ideas?
EDIT - ScreenCast
http://screencast-o-matic.com/watch/cDif6XiUSZ
After 3 days and no answer from MS I kept trying to figure it out and it seems this account is running on an old version.(?)
I have another account that's working fine and I started to compare both, here's why I think that:
Different versions
no online column and different header (Account profile vs Account/acc_name)
Perhaps you are right that your account is running in an old server.
I created one in India South and experienced the same behavior.
Then I deleted it and created one in South US and I can see my GitHub repository.
I noticed this afternoon that my Bluemix IoT Application was in the 'Unknown' state. When I mined into the app to see what the problem could be, I got the following pop-up:
App staging failed in the buildpack compile phase
I haven't made any changes to my NodeRED flows in months, and if I spin up a new IOT Foundation app, it starts just fine.
Any ideas on what is going on here?
A recent update to the underlying application stack has caused an incompatibility with older versions of the IoTF boilerplate.
The fix is to edit your application's package.json file and remove the 'mqlight' entry under the dependencies section. New instances of the boilerplate already have this entry removed - hence why they work.
Perhaps check the bluemix server status at https://developer.ibm.com/bluemix/support/#status
There were some issues reported around scheduled maintenance. There are also buildpack updates scheduled.