I went through the steps of Rolling out the variant for the A/B testing. I still see the option saying "Roll Out Vairant" when I go to Remote config. Do I need to stop the experiment for this to go away. How does it affect the data?
Thanks
Related
I just get start learning flink and try the case, "Real Time Reporting with the Table API "
When I ran docker-compose, all containers worked except jobmanager which is exited with 2.
up all
exit with 2
I tried rebuild and restart, but it does not work and I do not know what's wrong with it.
Could anyone help me to figure it out,please? Many thanks!
This particular tutorial does fail if you skip ahead and try to run it without first providing an implementation for org.apache.flink.playgrounds.spendreport.SpendReport.report. Several versions of that method are provided in the tutorial: pick one (perhaps the last one), drop it in, rebuild the docker image, and try again.
I have a workflow like this as a Azure Logic App:
Read from Azure Table -> Process it in a Function -> Send Data to SQL Server -> Send an email
Currently we can check if the previous action ended with an error and based on that we do not execute any further steps.
Is it possible in Logic Apps to perform a Rollback of actions when one of the steps goes wrong? Meaning can we undo all the steps to the beginning when something in step 3 goes wrong, for example.
Thanks in advance.
Regards.
Currently there is no support for rollback in Logic Apps (as they are not transnational).
Note that Logic Apps provide out-of-the-box resiliency against intermittent errors (retry strategies), which should minimize execution failures.
You can add custom handling of errors (e.g. following your example, if something goes in step 3, you can explicitly handle the failure and add rollback steps). Take a look at https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-exception-handling for details. You
Depending on whether steps in your logic app are idempotent you can also make use of the resubmit feature. It allows you to re-trigger the run with same trigger contents with which the original run instance was invoked. Take a look at https://www.codit.eu/blog/2017/02/logic-apps-resubmit-considerations/ for a good overview of this feature.
I have a running Ngios config and i will understanding, how works passive checks. I will expand and create my own passive checks. At the moment on the nodes is running a cron-job (ioadm check) and the results are going to the hagios GUI. It works pretty good.
I want to understand how going the "ioadm check" results to Nagios?
I hope you can help me.
regards
kinro
We have quite and extensive wizard UI flow and in order to test development changes (e.g.: DOM chanes) at the end of the flow we need to go through all the steps every time since there is data dependancy gathered in previous steps.
This is tedious, takes a lot of time, every time.
Have been thinking about some way of defaulting data but then still we have to click some buttons to get some a-ync data based on the input and press the next btn in the wizard steps.
Using a protractor like behaviour would be excellent. We already have tests set up for that which can take us to the point we need to verify, while developing, in seconds and having all the (stubbed) data in there.
Like to hear your thoughts on this and if such an automated Protractor way of getting to a certain point is possible.
EDIT: why not just use the Protractor test we use on the test server to use locally to go through the development steps and let it stop at a certain point?
While writing the post and re-reading it I answered it in the EDIT with Protractor. Havent tried it yet but should do the trick.
I have a test method, using NUnit and Selenium, which opens a browser on our website which is on the Production Server and registers a user and verifies that the registration is successful.
(I know ideally the system tests should run on a separate Test Server rather than production but here they want to test whether the prod system works!)
The problem is how to rollback the database changes as a result of this test? For example, the state of my database before and after running the state should be the same.
I thought of 3 possible options but none is practical:
1) writing SQL queries to delete from the actual tables before starting the test (Setup) and after running the test (TearDown); this is my current approach however
The problem with this approach is that I have to know exactly which tables were involved for each System Test which runs and this can quickly become very complex as a test may impact more than one table.
2) Writing transactional Code
This is not an option since the code changes are done by the website, not by the unit test written.
3) Getting an snapshot of existing database (SQL Server 2008 R2) before each test starts then after the test finished, restoring the snapshot to the original one.
This idea sounds good to me if we could run the tests only on Staging environment but the problem is that the tests have to run on Production and may take like 5 minutes totally so rolling it back and restoring it, would be a stupid idea as the changes done in that 5 minutes would be lost!
Please advise what approach would be best possible option to resolve this problem? there may be a 4th option?
Thanks,
Option 4 never ever ever ever do tests on a production server it's a recipe for disaster (see thousands of funny (if you are not the protagonist) stories on the internet on how this could go horribly wrong), the right thing to do would be to configure the test and production server in the same way.
There is a fith option. If the website receives a registration for user "WeAreTestingOutSite" it does everything except for actually adding the user to the Database.
To be honest, as was said, there are better ways to test if a production site is still in operation than to run bots to register a user to make sure it is working (or operational).
I would recommend you going with 4th option: Introduce new feature which allows to delete the user. Probably not to the user himself/herself but to the system admins (Backoffice users). That way you can test if user can be registered - and deleted afterwards while not caring that much about the SQL scripts.