IoT hub deployment is not getting applied to edge if the manifest size is high (like 122 KB)
I have 26 modules of which 18 are third party non-iot edge modules. The environment variables used in these third party modules are quite high in number and size.
If the environment variables of third party modules are not provided, then size of manifest becomes 37 KB and deployment will get applied.
As we do not have any control over environment variables of third party modules, cannot do much.
What can be an option to circumvent if this is a limitation.
Is there a way to provide "env file" like in docker run instead of
environment variables
Any other thoughts
Edge version used: 1.1.9
Asked here as well: https://learn.microsoft.com/en-us/answers/questions/915325/iot-hub-deployment-not-getting-applied-if-manifest.html
Related
Using this: https://github.com/JetBrains/skiko/
I was able to get the SkiaAwtSample to work and it shows a window with a grid of animating clocks. It shows that the backend is OpenGL (I'm using Linux Mint 21, and have NVidia proprietary drivers installed). My first impression is that the performance seems average at best. I predict if I'd try to replicate this using plain old Java2D, I'd get similar performance. I also predict that the performance of Java2D is downplayed. But it is not performance that I am after.
I want to stop investing in UI and graphics technologies that aren't portable.
The samples directory shows these 4 subdirectories:
SkiaAndroidSample SkiaAwtSample SkiaJsSample SkiaMultiplatformSample
When I try to use the build target in the SkiaJsSample directory, I get a long maven error report, that amounts to a dependency not having been met. It wants org.jetbrains.skiko:skiko:0.0.0-SNAPSHOT with 'org.jetbrains.kotlin.platform.type' with value 'js'.
The DEVELOPMENT.md file only mentions of building and making available in the local maven repo using :skiko:publishToMavenLocal
Digging further, I tried :skiko-js-wasm-runtime:publicToMavenLocal but no such target exists.
It seems only the awt stuff is included in the github repository. Isn't the whole thing open source. I can find wasm related entries in online maven repos, but why can't we build it locally and public to our local maven repos?
I have configured the environment variables as follows:
This resolution is supposed to be compatible with every OS, still tried many others and also different OS.
I applied the same settings for the .env file on the project.
What are the configurations you have provided to initiate your tests?
Since you have specified the flag BROWSERSTACK_USE_AUTOMATE="1", the setting on https://www.browserstack.com/automate/capabilities would come into effect.
While developing with IBM MobileFirst studio I've found that after building iOS/Android environment and generated native projects, even a blank app (e.g a quite simple Hello World Android app which do not use any native functionality), will take size more than 4Mb which is much larger than a real native exported Android apk file.
So are there any unused resources that can be deleted or other things we can do so that we can lose weight in the final exported apps?
Another detail, the classes.dex file inside the 'blank HelloWorld'apk file seems larger than a common apk file (4Mb size).
Starting MFP 7.0 you can now minify and concatenate mobile environments. This means that in addition to added security, by reducing the amount of files and contents of files, it can help - to some degree - with the filesize of the application.
Read more about application build settings
MFPF 7 supports by default many more hardware architectures. This support is required if you intend on using features such as JSONStore and others. The files adding this support are located at your-app\android\native\libs (arm64-v8a, armabi, armabi-v7a, mips, mips64, x86, x86-64). So if you know you're not using JSONStore for example, see if removing some or all of these files helps you. But also do a regression test in general to make sure that the app continues to work as required. I could be wrong about the scope of these files - which add 3.4MB on disk.
The vSphere SDK for .NET developers pdf has a sample that describes how to connect to Vcenter and perform operations such as power-off, reboot etc.
I need specific examples for changing VM configuration such as disk, memory, CPU etc as well as migration through Storage VMotion and cloning.
The vSphere PowerCLI admin guide has specific examples to the above using command line in Powershell but there are no corresponding examples in C#. Has anyone attempted these operations in C#?
The vSphere SDK for .NET comes with many samples for performing various operations.
The samples, however, need to be rebuilt using a supplied batch file(s).
Here's how it is done:
Navigate to the path: VMware-vSphere-WS-SDK-4.1.0-257238\SDK\samples\DotNet
Under this path, you will find various batch files, such as: Build2005.cmd and
Build2008.cmd
There's also a readme_dotnet.html, but it seems outdated.
Open a Visual Studio command line window.
Navigate to the samples\DotNet folder.
If you have installed VS in a non-default location, fix up the environment variable prior to beginning:
"set the environment variable VSINSTALLDIR to the directory containing the 2 directories "Common7" and "SDK"." Please remember to use quotes around directory names that have spaces in them.
Execute Build2005.cmd or Build2008.cmd (for VS2005/2008).
This will create a "cs" folder with all relevant samples (58 projects).
Hope this helps!
Lior
I've played with a number of VMWare API's and I've settled on VSphere SDK for .NET also. It's not perfect but it's the best I've found so far. As far as samples, since the PowerCLI cmdlets are just wrappers for the underlying .NET classes I tend to google for PowerCLI examples and then port that over to C#.
It seems strange that when I go to the website for code samples they simply don't have a category for this SDK. They only have samples for the SDK that's a bunch of .net class source files based on WSDL.
Preface:
My Company, like most, has several run-time environments and several release versions which themselves are composed of different versions of various jars.
For example, let us consider release versions 1.1, 1.2, and 1.3 of Software X, which may be deployed to a developer computer, testing, or production.
Software-x-1.1 is itself composed of jarA-0.9.1 and jarB-0.7.5, but software-x-1.3 is composed of jarA-1.7.31 and jarB-0.8.1.
Currently we use Spring's PropertyPlaceholderConfigurer to configure run-time variables (such as database credentials), however, properties also change with release versions.
We also use Maven 2 POM version 4 to specify which versions of our code need to be used. We place the version numbers of our jars as properties within profiles (dev,test,prod) inside of the parent pom and then reference those version numbers in all project poms.
As of right now, we have no way to specify which project versions pertain to a given release other than the most current one. Moreover, we deploy our run-time configurations to the SSDM pickup which then configures and creates the services defined by the built versions of our software.
--
Questions:
Is there any procedure/tool we can use to build our product by merely providing the run-time environment and version number? IE "build 1.1 dev"?
Is there anyway we can store the required jar versions for each release build? We are currently versioning all files, including the parent pom, but merely versioning the parent pom does not record which release version is pertinent to that parent pom.
What else can we do to further automate the process of builds?
For example, if we could manage run-time configurations within the parent pom that would be a step in the right direction, but that seems like a violation of scope.
Any tool outside of our framework is inconceivable at this point, but not in the far future.
Summary:
How can we automate our build process to the fullest extent without being error prone?
Based on the part for released version 1.1, 1.2 and 1.3 of the Software X it seemed to be right way to use profiles to handle differences between test, production etc. environments.
The software itself is an other story. I assume you are using a version control tool (VCT) to store the state of your development. So during the preparation of Software-x-1.1 you change your root pom and define the dependencies (jarA-0.9.1, jarB-0.7.5). Make a Tag Release 1.1. and than continue to Release 1.2...during the development of Release 1.3 you decided to change the dependencies (to jarA-1.7.31 and jarB-0.8.1) which results in a change to the pom's or your root pom only). May be i oversight your real problem.
If I summarize your problem: you want to manage release of versions across multiple environments, and you release distribution is an aggregate of executable (jars) as well as environments properties. Different versions of these deploy-able distributions propagate to diff env at different stages with there own set of env properties and you are looking at a way to have a common roll out (or may be release process) to handle all of this.
It seems the first problem you have is that you run a build per release per environment when you are propagating a release. If I am not wrong, you should try looking at your app architecture first to see if there is a way you can create environment independent binaries, in some cases projects prefer keeping properties as a separate module which is deployed along with the jars, and a Property Manager of sorts which figures reads the files, so you may have a maven module called properties, which bundles one zip each for every env set of property files. Your deployer script can then be given a parameter while running on which zip file to extract to a location from where the properties can be read into the application. What you gain this way is that you "create one release distribution per release - which has contents to run on all environments".
Also, is it the case that you release version is "not" the version that you have in POM? if not aligning your release version to POMs should be done. i.e. POM should be 1.3-SNAPSHOT when you are working on development phase of that release, and be bumped off to 1.3 in a branch when you are releasing it.
There are no one size fits all solutions for such things but practices similar to this one do help to a good extent.
PS Do let me know if I got your problem right, or have ended up beating around the bushes ;-) DS.