When using the v2/groups API to update a subset of applications in a group, how does one specify the configuration for those apps that are unchanged? Does the update request have to include the full original configuration for the unchanged app, or does one simply have to include its id to indicate it is still part of the group but with configuration unchanged?
You can either
use PUT on the group and include the unchanged configuration as well. Marathon will detect which apps are changed and only redeploy changed applications.
use PUT on the app endpoint to only change one of the apps in isolation.
Related
I've been trying to migrate some BUs and their default teams from our dev environment to a higher environment and keep the default teams' GUIDs the same in both envs but have not been successful. I tried changing the order I deploy them, ie tried deploying BUs before and after teams but it made no difference. The problem is when I deploy a BU, the system automatically creates a default team which I cannot delete or rename or even make non-default so that I could make the teams I want (with the same GUID) as default. Also I've tried different tools such as SDK's DataMigrationUtility and XrmToolBox's Data Transporter but the outcome is the same, i.e. I cannot get rid of the default team.
I would appreciate any advice on how to do this.
Thanks in advance
Default Teams for BU are created by system automatically and you cannot transfer them or create them or unassigned them.
Same is the case with default queue for Team (owner Team) you cannot create them, transfer them and unassigned them.
You could definitely transfer Teams (which are not default teams) but unfortunately the one you are trying is not possible.
I am using Wildfly 9.0.2.Final, while in development, all my files that uploaded via my web service and stored in resources/images are gone when I perform a full-publish (luckily this are development dummy images). In production, where is the best place to store or best practice to prevent files/images from missing?
If the files belong somehow to your application, place the somewhere inside the web application (and outside of WEB-INF). They will be accessible through the respective URL path.
If your application needs to store user data that gets uploaded dynamically during application runtime and shall persist even if you redeploy the application, then you better have a configurable directory on disk. One default option to find the JBoss/Wildfly data directory could be to query for the system property 'jboss.server.data.dir'.
My group is getting into web services for the first time. What is the usual way to control versioning issues with web services and clients? We're generating our services and clients using in IBM's RAD using the wizards it presents. The services and clients work well enough, but we're wondering how managing these will become a task going forward.
-If a service changes, and it's interface doesn't change I presume older clients would never know the difference and would work fine.
-If a service changes to add a new property to a parameter, would older clients work with it if they didn't need to set that value?
-How do people handle version control of web services as they grow in number and the number of apps using their clients grows? What is best practice on this sort of thing?
There are two types of versioning that we use. One that is visible to clients (public) and one that isn't (private). This comes from (what you already touched upon) whether clients are affected or not.
If clients are affect by, for example change in XSD Schema definitions or functionality of the WS changes in such way that clients must also modify their end, we change the public version. We increment the version number in WS context root, which means that it will have different URL than the previous version. Also make sure that the code archive, in our case they are war, have also the public version, as not to overwrite the previous deployment.
For example our WS called foo is in public version 2. Its URL is http://ourserver:8000/foo_2 and war file is called foo_2. We modified our XSD Schema, so the clients must react to the change. We update the version and now URL is http://ourserver:8000/foo_3 and war file is called foo_3. The previous version still exists, while clients can slowly transition to the new version.
If the change does not force any action from clients, then we call this private versioning. This usually shows up, in combination with public version, as a part of a project name. Using previous example, we have a WS foo, with private version 5 and public 2. Our project for this service is called WS_foo_2_5. We now change the order in which we store incoming data. This does not effect the clients, so we change the private version. In effect we have project WS_foo_2_6. We create a code archive from it called foo_2 and deploy it with URL set to http://ourserver:8000/foo_2. This way we modified the version, without changing anything from clients POV.
So as to avoid overwhelming the infrastructure in a web application instance, what would be the methods of implementing a feature roll out to a controlled group of your user-base?
It depends on the situation. You can't really redirect them to another site using another database if the users are expecting to work with real data and the real site.
I would introduce a flag on your users in your user-table, let's say isBetaUser (bool). Then you can just show these new features for users that got this flag set to True. You could also let them check this flag off using a checkbox through some settings page, if they don't like the idea of trying out new features that is.
Partition your users into groups. Randomly. Demographically. Somehow.
Pick one or more groups for a pilot.
Fix your web site to have both versions of your app running. Maybe use virtual hosting or a different path or something.
One database. Two applications. Data doesn't move. Only the presentation changes.
At first, all users are in the old version. Workload has not changed.
Move a group of users so that their default URL's or links or menus or whatever are references to the new application.
Same workload. Same database. Same number of users. Two applications.
Move another group of users to the new application.
Same workload. Same database. Same number of users. Two applications.
Eventually, after all users are moved, you can delete the old application.
We have an internal web system that handles the majority of our companies business. Hundreds of users use it throughout the day, it's very high priority and must always be running. We're looking at moving to ASP.NET MVC 2; at the moment we use web forms. The beauty of using web forms is we can instantaneously release a single web page as opposed to deploying the entire application.
I'm interested to know how others are deploying their applications whilst still making them accessible to the user. Using the deployment tool in Visual Studio would supposedly cause a halt. I'm looking for a method that's super quick.
If you had high priority bug fixes for example, would it be wise to perhaps mix web forms with MVC and instead replace the view with a code-behind web form until you make the next proper release which isn't a web form?
I've also seen other solutions on the same server of having the same web application run side-by-side and either change the root directory in IIS or change the web.config to point to a different folder, but the problem with this is that you have to do an entire build and deploy even if it were for a simple bug fix.
EDIT: To elaborate, how do you deploy the application without causing any disruption to users.
How is everyone else doing it?
I guess you can run the MVC application uncompiled also? and just replace .cs/views and such on the run.
A websetup uninstall/install is very quick, but it kills the application pool.. which might cause problem. Depending on how your site is built.
The smoothest way is to run it on two servers and store the sessions in sql server or shared state. Then you can just bring S1 down and patch it => bring s1 back up again and bring S2 down => patch S2 and then bring it up again. Al thought this might not work if you make any major changes to the session parts of the code.
Have multiple instances of your website running on multiple servers. The best way to do it is to have a production environment, a test environment, and a developement environment. You can create test cases and run the load every time you have a new build, if can get through all the tests, move the version into production ;).
You could have two physical servers each running IIS and hosting a copy of the site. OR you could run two copies of the site under different IIS endpoints on the SAME server.
Either way you cut it you are going to need at least two copies of the site in production.
I call this an A<->B switch method.
Firstly, have each production site on a different IP address. In your company's DNS, add an entry set to one of the IPs and give it a really short TTL. Then you can update site B and also pre-test/warm-up the site by hitting the IP address. When it's ready to go, get your DNS switched to the new site B. Once your TTL has expired you can take down site A and update it.
Using a shared session state will help to minimise the transition of users between sites.