From dusty at dustymabe.com Thu Jun 2 14:23:33 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Thu, 2 Jun 2016 10:23:33 -0400 Subject: [Devtools] Subtlety with libvirt provider that is causing quite a bit of misinformation Message-ID: <57504165.8030407@dustymabe.com> There is a small subtlety with the libvirt vagrant provider that many people aren't aware of. On the first `vagrant up` the vagrant box will be uploaded to the libvirt storage pool and then used as a backing device for the vm that gets started. So now you have the vagrant box file (lives in the .vagrant.d directory) as well as a file in the libvirt storage pool. The problem comes about when you remove/re-add a box to a machine. When you remove the box, it removes the box from vagrant but it does not remove the box from the libvirt storage pool. If you subsequently re-add the box (a newer version this time) to vagrant and perform a `vagrant up` then no box gets uploaded because there is already a "backing image" in libvirt with that name. What this leads to is people thinking they have the latest version of the CDK installed, but really using something that is old as dirt. One example of this was the developers post [1] that came out a week ago. The author was using a CDK box from January and some of the information he had in the post was old. Another example came to me from some of my contacts in consulting. Basically this is dangerous because some people can "test" things and "verify" they are working and not realize they are using old stuff. We need to somehow resolve this in the vagrant-libvirt provider or come up with some other, client side way of verifying things. Dusty [1] http://developers.redhat.com/blog/2016/05/27/use-vagrant-landrush-to-add-dns-features-to-your-openshift-cdk-machine/ From dusty at dustymabe.com Thu Jun 2 14:25:55 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Thu, 2 Jun 2016 10:25:55 -0400 Subject: [Devtools] Subtlety with libvirt provider that is causing quite a bit of misinformation In-Reply-To: <57504165.8030407@dustymabe.com> References: <57504165.8030407@dustymabe.com> Message-ID: <575041F3.6030503@dustymabe.com> On 06/02/2016 10:23 AM, Dusty Mabe wrote: > > There is a small subtlety with the libvirt vagrant provider that many > people aren't aware of. > > On the first `vagrant up` the vagrant box will be uploaded to the > libvirt storage pool and then used as a backing device for the vm that > gets started. So now you have the vagrant box file (lives in the > .vagrant.d directory) as well as a file in the libvirt storage pool. > > The problem comes about when you remove/re-add a box to a machine. > When you remove the box, it removes the box from vagrant but it does > not remove the box from the libvirt storage pool. If you subsequently > re-add the box (a newer version this time) to vagrant and perform a > `vagrant up` then no box gets uploaded because there is already a > "backing image" in libvirt with that name. > > What this leads to is people thinking they have the latest version of > the CDK installed, but really using something that is old as dirt. > > One example of this was the developers post [1] that came out a week > ago. The author was using a CDK box from January and some of the > information he had in the post was old. > > Another example came to me from some of my contacts in consulting. > > Basically this is dangerous because some people can "test" things and > "verify" they are working and not realize they are using old stuff. > > We need to somehow resolve this in the vagrant-libvirt provider or > come up with some other, client side way of verifying things. > > Dusty > > [1] http://developers.redhat.com/blog/2016/05/27/use-vagrant-landrush-to-add-dns-features-to-your-openshift-cdk-machine/ You can workaround this now by doing something like the following: vagrant box remove cdkv2 virsh vol-delete --pool default cdkv2_vagrant_box_image_0.img vagrant box add ... Dusty From alr at redhat.com Thu Jun 2 15:08:55 2016 From: alr at redhat.com (Andrew Lee Rubinger) Date: Thu, 2 Jun 2016 11:08:55 -0400 Subject: [Devtools] Subtlety with libvirt provider that is causing quite a bit of misinformation In-Reply-To: <575041F3.6030503@dustymabe.com> References: <57504165.8030407@dustymabe.com> <575041F3.6030503@dustymabe.com> Message-ID: Thanks for sending this along. Because I'm newer to Vagrant; does "vagrant destroy" sufficiently clean up so that the next "up" operation is a clean state? Or in libvirt does this have the same issue as you mention with caching in the storage pool? S, ALR On Thu, Jun 2, 2016 at 10:25 AM, Dusty Mabe wrote: > > > On 06/02/2016 10:23 AM, Dusty Mabe wrote: > > > > There is a small subtlety with the libvirt vagrant provider that many > > people aren't aware of. > > > > On the first `vagrant up` the vagrant box will be uploaded to the > > libvirt storage pool and then used as a backing device for the vm that > > gets started. So now you have the vagrant box file (lives in the > > .vagrant.d directory) as well as a file in the libvirt storage pool. > > > > The problem comes about when you remove/re-add a box to a machine. > > When you remove the box, it removes the box from vagrant but it does > > not remove the box from the libvirt storage pool. If you subsequently > > re-add the box (a newer version this time) to vagrant and perform a > > `vagrant up` then no box gets uploaded because there is already a > > "backing image" in libvirt with that name. > > > > What this leads to is people thinking they have the latest version of > > the CDK installed, but really using something that is old as dirt. > > > > One example of this was the developers post [1] that came out a week > > ago. The author was using a CDK box from January and some of the > > information he had in the post was old. > > > > Another example came to me from some of my contacts in consulting. > > > > Basically this is dangerous because some people can "test" things and > > "verify" they are working and not realize they are using old stuff. > > > > We need to somehow resolve this in the vagrant-libvirt provider or > > come up with some other, client side way of verifying things. > > > > Dusty > > > > [1] > http://developers.redhat.com/blog/2016/05/27/use-vagrant-landrush-to-add-dns-features-to-your-openshift-cdk-machine/ > > > You can workaround this now by doing something like the following: > > vagrant box remove cdkv2 > virsh vol-delete --pool default cdkv2_vagrant_box_image_0.img > vagrant box add ... > > Dusty > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- Red Hat Developer Programs Architecture @ALRubinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From dusty at dustymabe.com Thu Jun 2 15:16:27 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Thu, 2 Jun 2016 11:16:27 -0400 Subject: [Devtools] Subtlety with libvirt provider that is causing quite a bit of misinformation In-Reply-To: References: <57504165.8030407@dustymabe.com> <575041F3.6030503@dustymabe.com> Message-ID: <57504DCB.1060701@dustymabe.com> On 06/02/2016 11:08 AM, Andrew Lee Rubinger wrote: > Thanks for sending this along. > > Because I'm newer to Vagrant; does "vagrant destroy" sufficiently clean up so that the next "up" operation is a clean state? Or in libvirt does this have the same issue as you mention with caching in the storage pool? > The 'vagrant destroy/vagrant up' works completely fine. The existing box will be removed and the new box will be clean. The problem I am refering to is when you trying to "update" the underlying base image (i.e. a new version of the CDK comes out). In this case if you don't properly remove the old CDK box from libvirt before adding the new box, then you'll most likely be using the wrong bits. From dusty at dustymabe.com Thu Jun 2 15:19:26 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Thu, 2 Jun 2016 11:19:26 -0400 Subject: [Devtools] [Container-tools] Subtlety with libvirt provider that is causing quite a bit of misinformation In-Reply-To: <17a75b09-d7ee-c162-a9fa-6824cbe0e671@redhat.com> References: <57504165.8030407@dustymabe.com> <17a75b09-d7ee-c162-a9fa-6824cbe0e671@redhat.com> Message-ID: <57504E7E.4020504@dustymabe.com> On 06/02/2016 10:34 AM, Lalatendu Mohanty wrote: > On 06/02/2016 07:53 PM, Dusty Mabe wrote: >> There is a small subtlety with the libvirt vagrant provider that many >> people aren't aware of. >> >> On the first `vagrant up` the vagrant box will be uploaded to the >> libvirt storage pool and then used as a backing device for the vm that >> gets started. So now you have the vagrant box file (lives in the >> .vagrant.d directory) as well as a file in the libvirt storage pool. >> >> The problem comes about when you remove/re-add a box to a machine. >> When you remove the box, it removes the box from vagrant but it does >> not remove the box from the libvirt storage pool. If you subsequently >> re-add the box (a newer version this time) to vagrant and perform a >> `vagrant up` then no box gets uploaded because there is already a >> "backing image" in libvirt with that name. >> >> What this leads to is people thinking they have the latest version of >> the CDK installed, but really using something that is old as dirt. >> >> One example of this was the developers post [1] that came out a week >> ago. The author was using a CDK box from January and some of the >> information he had in the post was old. >> >> Another example came to me from some of my contacts in consulting. >> >> Basically this is dangerous because some people can "test" things and >> "verify" they are working and not realize they are using old stuff. >> >> We need to somehow resolve this in the vagrant-libvirt provider or >> come up with some other, client side way of verifying things. >> >> Dusty >> >> [1] http://developers.redhat.com/blog/2016/05/27/use-vagrant-landrush-to-add-dns-features-to-your-openshift-cdk-machine/ > > Dusty, > > Thanks for bringing it up. There is a old issue in vagrant-libvirt > about this i.e. https://github.com/vagrant-libvirt/vagrant-libvirt/issues/85 > Thanks lala. I added a comment upstream. > think we should add it to documentation for the immediate next release > so that users are aware about this. Agreed. We should also probably throw some resources towards helping to fix the problem. Would be good to get this fixed sooner than later. Should I file a BZ for this issue? Dusty From dusty at dustymabe.com Thu Jun 2 15:28:17 2016 From: dusty at dustymabe.com (Dusty Mabe) Date: Thu, 2 Jun 2016 11:28:17 -0400 Subject: [Devtools] [Container-tools] Subtlety with libvirt provider that is causing quite a bit of misinformation In-Reply-To: References: <57504165.8030407@dustymabe.com> Message-ID: <57505091.3080404@dustymabe.com> On 06/02/2016 11:25 AM, Jason Brooks wrote: > On Thu, Jun 2, 2016 at 7:23 AM, Dusty Mabe wrote: >> >> There is a small subtlety with the libvirt vagrant provider that many >> people aren't aware of. >> >> On the first `vagrant up` the vagrant box will be uploaded to the >> libvirt storage pool and then used as a backing device for the vm that >> gets started. So now you have the vagrant box file (lives in the >> .vagrant.d directory) as well as a file in the libvirt storage pool. >> >> The problem comes about when you remove/re-add a box to a machine. >> When you remove the box, it removes the box from vagrant but it does >> not remove the box from the libvirt storage pool. If you subsequently >> re-add the box (a newer version this time) to vagrant and perform a >> `vagrant up` then no box gets uploaded because there is already a >> "backing image" in libvirt with that name. > > Here's what to watch for: > > $ vagrant box remove centos/atomic-host > Removing box 'centos/atomic-host' (v7.20160331) with provider 'libvirt'... > Vagrant-libvirt plugin removed box only from you LOCAL > ~/.vagrant/boxes directory >>From libvirt storage pool you have to delete image manually(virsh, > virt-manager or by any other tool) > > If you see that message, you need to do what it says. > > "vagrant box update" works fine, but is this not an option for the CDK? > Since the CDK doesn't use atlas, it can't use versioning, which I think means that we can't use `vagrant box update`. If we could use versioning, the version gets stored alongside the name of the file in the libvirt storage pool, so this would be less of a problem. Dusty From lmohanty at redhat.com Thu Jun 2 15:42:33 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 2 Jun 2016 21:12:33 +0530 Subject: [Devtools] [Container-tools] Subtlety with libvirt provider that is causing quite a bit of misinformation In-Reply-To: <57504E7E.4020504@dustymabe.com> References: <57504165.8030407@dustymabe.com> <17a75b09-d7ee-c162-a9fa-6824cbe0e671@redhat.com> <57504E7E.4020504@dustymabe.com> Message-ID: On 06/02/2016 08:49 PM, Dusty Mabe wrote: > > On 06/02/2016 10:34 AM, Lalatendu Mohanty wrote: >> On 06/02/2016 07:53 PM, Dusty Mabe wrote: >>> There is a small subtlety with the libvirt vagrant provider that many >>> people aren't aware of. >>> >>> On the first `vagrant up` the vagrant box will be uploaded to the >>> libvirt storage pool and then used as a backing device for the vm that >>> gets started. So now you have the vagrant box file (lives in the >>> .vagrant.d directory) as well as a file in the libvirt storage pool. >>> >>> The problem comes about when you remove/re-add a box to a machine. >>> When you remove the box, it removes the box from vagrant but it does >>> not remove the box from the libvirt storage pool. If you subsequently >>> re-add the box (a newer version this time) to vagrant and perform a >>> `vagrant up` then no box gets uploaded because there is already a >>> "backing image" in libvirt with that name. >>> >>> What this leads to is people thinking they have the latest version of >>> the CDK installed, but really using something that is old as dirt. >>> >>> One example of this was the developers post [1] that came out a week >>> ago. The author was using a CDK box from January and some of the >>> information he had in the post was old. >>> >>> Another example came to me from some of my contacts in consulting. >>> >>> Basically this is dangerous because some people can "test" things and >>> "verify" they are working and not realize they are using old stuff. >>> >>> We need to somehow resolve this in the vagrant-libvirt provider or >>> come up with some other, client side way of verifying things. >>> >>> Dusty >>> >>> [1] http://developers.redhat.com/blog/2016/05/27/use-vagrant-landrush-to-add-dns-features-to-your-openshift-cdk-machine/ >> Dusty, >> >> Thanks for bringing it up. There is a old issue in vagrant-libvirt >> about this i.e. https://github.com/vagrant-libvirt/vagrant-libvirt/issues/85 >> > Thanks lala. I added a comment upstream. > >> think we should add it to documentation for the immediate next release >> so that users are aware about this. > Agreed. We should also probably throw some resources towards helping > to fix the problem. Would be good to get this fixed sooner than later. Agree, we should try to fix it. > Should I file a BZ for this issue? The only place it will get attention is Trello :) > > Dusty > > _______________________________________________ > Container-tools mailing list > Container-tools at redhat.com > https://www.redhat.com/mailman/listinfo/container-tools From bex at pobox.com Mon Jun 6 08:28:59 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Mon, 6 Jun 2016 10:28:59 +0200 Subject: [Devtools] [Container-tools] Consolidate Docs for ADB (and related projects) into a single repo In-Reply-To: <5746F4F2.3010106@pobox.com> References: <5746F4F2.3010106@pobox.com> Message-ID: <5755344B.1060607@pobox.com> I have given this a bit more thought and have some additional comments inline: On 05/26/2016 03:06 PM, Brian (bex) Exelbierd wrote: > Hola, > > We'd like to consolidate the documentation related to the ADB into a new > repository in ProjectAtomic GH namespace. The working name for the repo > is "Developer-Docs". After further thought, I believe the right place for these docs to live is in the ADB repo. This is based on the belief that vagrant service-manager is not intended to be used outside of the ADB and that adb-utils exists as a separate repo primarily for packaging convenience. If these beliefs are not true then we should still use a third-repo. > > The affected projects would be: ADB, Vagrant-Service-Manager and ADB-utils. > > The goal of this move is to: > o Make it easier to tell a cohesive story and improve onboarding. > o Enable deeper cross-linking > o Enable easier community contribution (including downstream consumers) > by centralizing docs to reduce "hunting" > o Enable easier publishing to docs.projectatomic.io (very > WIP/conceptual) - it will at least not make it harder > > Docs that are for developers working on the tools themselves will not be > moved at this time. This can be done if there is a general feeling this > is valuable. > > Each sub-project repo's README would be updated to direct users to the > docs in the published location (initially in the new repo). > > Given the impact of these changes, I'd like to see acks from an > appropriate set of maintainers from each project. If a project would > like an issue to ack against in their project, please reply and I will > create one. I have opened issues for discussion in the repos as follows: adb-utils: https://github.com/projectatomic/adb-utils/issues/137 vagrant service-manager: https://github.com/projectatomic/vagrant-service-manager/issues/249 adb: https://github.com/projectatomic/adb-atomic-developer-bundle/issues/423 regards, bex > Assuming it is accepted, the conversion to AsciiDoc will be done in > conjunction with this move. We may also reorder/rewrite docs as a part > of this to begin telling a more cohesive and complete story. > > Thank you. > > regards, > > bex > > _______________________________________________ > Container-tools mailing list > Container-tools at redhat.com > https://www.redhat.com/mailman/listinfo/container-tools -- Brian (bex) Exelbierd | bex at pobox.com +420-606-055-877 | @bexelbie http://www.winglemeyer.org From bex at pobox.com Mon Jun 6 08:36:22 2016 From: bex at pobox.com (Brian (bex) Exelbierd) Date: Mon, 6 Jun 2016 10:36:22 +0200 Subject: [Devtools] [atomic-devel] Proposal - Moving container development tools docs to the Asciidoc format In-Reply-To: References: <57434FAA.8060308@redhat.com> Message-ID: <57553606.5060201@pobox.com> On 05/26/2016 03:26 PM, Stephen Milner wrote: > On Mon, May 23, 2016 at 2:44 PM, Josh Berkus wrote: >> I'm happy for this to be our default, but I'm concerned about making >> existing projects port their docs. For one thing, at least a couple of >> projects make use of readthedocs.org, which requires a different format. > > Agreed. Commissiare makes use of reST for readthedocs and, AFAIK, > there is no planned support at RTD for asciidoc or other formats. I've > not personally tried pandoc to see how well it would convert between > the two but that may be an option for those of us currently on RTD. I don't think we need to do a conversion. docs.pa.o is theoretically able to accept anything with a known conversion toolchain to html, which reST does. The question I think we need to answer is do you want to publish the docs in two places or not. If not, which source is considered authoritative and which should have a redirect? regards, bex From lmohanty at redhat.com Mon Jun 6 11:02:50 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Mon, 6 Jun 2016 16:32:50 +0530 Subject: [Devtools] ADB video series starts today Message-ID: <2b3d023e-bba6-8629-a66c-80340f55897c@redhat.com> Hi, The video series for ADB starts today. Below are the details for today's topic. Also refer the titanpad [1] about the future planning . We will record the session and upload it in Youtube. Timing: 13:30 UTC i.e. 7PM IST BlueJeans Url: https://bluejeans.com/883761482 Topic : Native Docker experience on an OS X or Windows Host : Speaker: Lalatendu Mohanty * Introduction to ADB * Quickstart * setup and demo * How the docker client on the host talks to the docker demon inside ADB. [1] https://titanpad.com/adbvideoseries Thanks, Lala -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdrage at redhat.com Mon Jun 6 13:40:16 2016 From: cdrage at redhat.com (Charlie Drage) Date: Mon, 6 Jun 2016 09:40:16 -0400 Subject: [Devtools] Weekly Nulecule IRC Meeting Message-ID: <20160606134016.GC1@9737a5c312fc> Short meeting this week. No blockers. Only update to Nulecule / Atomic App is the K8S PR + Nulecule documentation. https://meetbot.fedoraproject.org/nulecule/2016-06-06/nulecule_weekly_irc_meeting.2016-06-06-13.32.log.html -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From nshaikh at redhat.com Wed Jun 8 13:05:04 2016 From: nshaikh at redhat.com (Navid Shaikh) Date: Wed, 8 Jun 2016 18:35:04 +0530 Subject: [Devtools] vagrant-service-manager v1.1.0 release Message-ID: Hi, vagrant-service-manager version 1.1.0 is released. This release of the plugin addresses bug fixes and important enhancements with acceptance tests. --debug flag inclusion, new start/enable commands for services and documentation updates are few to enlist, check the detailed changelog at [1]. Update your plugin and let us know the feedback! Thanks! [1] https://github.com/projectatomic/vagrant-service-manager/releases/tag/v1.1.0 -- Navid -------------- next part -------------- An HTML attachment was scrubbed... URL: From prkumar at redhat.com Thu Jun 9 05:46:11 2016 From: prkumar at redhat.com (Praveen Kumar) Date: Thu, 09 Jun 2016 11:16:11 +0530 Subject: [Devtools] redhat registry: What repo toplevel for atomicapp? In-Reply-To: <573CC5BE.5040801@dustymabe.com> References: <573CC29B.4070605@dustymabe.com> <573CC5BE.5040801@dustymabe.com> Message-ID: <1465451171.4795.197.camel@redhat.com> On Wed, 2016-05-18 at 15:42 -0400, Dusty Mabe wrote: > > On 05/18/2016 03:29 PM, Dusty Mabe wrote: > > > > In the Red Hat registry I can only get AtomicApp from: > > > > docker pull devstudio/atomicapp > > OR > > docker pull cdk_beta/atomicapp (OUTDATED) > > > > > > This doesn't seem right to me. What toplevel should we be under? > > > Also the tags for atomicapp in the registry are inappropriate. The > latest version is 0.5.0 but the tags that I can pull from are: > > ``` > # skopeo registry.access.redhat.com/devstudio/atomicapp??2>/dev/null > | jq '.RepoTags' > [ > ? "7.2-13", > ? "latest" > ] > ``` Tag is now fixed for atomicapp, please give it a try. ``` # skopeo registry.access.redhat.com/devstudio/atomicapp??2>/dev/null | jq '.RepoTags' [? ? ?"0.5.0", ? ?"latest" ]? ``` > > What we are doing upstream looks much different: > > ``` > # skopeo docker.io/projectatomic/atomicapp??2>/dev/null | jq > '.RepoTags'?????????????????????????????????????????????????????????? > ????????????????????????????????????????????????????????????????????? > ??????????????????? > [ > ? "0.0.1", > ? "0.1.0", > ? "0.1.1", > ? "0.1.10", > ? "0.1.11", > ? "0.1.12", > ? "0.1.2", > ? "0.1.3", > ? "0.2.1", > ? "0.2.2", > ? "0.2.3", > ? "0.3.0", > ? "0.3.1", > ? "0.4.0", > ? "0.4.1", > ? "0.4.2", > ? "0.4.3", > ? "0.4.4", > ? "0.4.5", > ? "0.5.0", > ? "0.5.1", > ? "dev", > ? "latest" > ] > ``` > > > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools From lmohanty at redhat.com Thu Jun 9 15:25:32 2016 From: lmohanty at redhat.com (Lalatendu Mohanty) Date: Thu, 9 Jun 2016 20:55:32 +0530 Subject: [Devtools] Atomic Developer Bundle v2.2.0 released Message-ID: <72963e64-019d-5321-3a29-85446f64f7d3@redhat.com> We have released the Atomic Developer Bundle 2..2.0 through CentOS Atomic SIG. The ADB release also includes release of following ecosystem projects: * adb-utils : version 1.7- A set of utility scripts and configuration files for ADB. * vagrant-service-manager: version 1.1.0 - Vagrant plugin designed to enable easier access to the features and services provided by the ADB ADB 2.2.0 release adds several bugfixesand enhancemnets , including: * The Vagrant box size has been reduced significantly. The size of the box is almost 150MB less than ADB 2.0.0. * ADB is now using OpenShift Origin 1.2.0 as default. However user can change it to latest in the Vagrantfile [5] to use latest OpenShift Origin. This release also includes many changes and bugfixes, which are detailed in the release changelog of adb-utils [1], vagrant-service-manager [3] [6] andADB [2]. Please update the ADB Vagrant box [4] and the vagrant-service-manager ($ vagrant plugin update vagrant-service-manager) and give the new ADB version a spin. [1] https://github.com/projectatomic/adb-utils/releases/tag/v1. 7 [2] https://github.com/projectatomic/adb-atomic-developer-bundle/tree/v2. 2.0 [3] https://github.com/projectatomic/vagrant-service-manager/releases/tag/v1.1.0 [4] https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/docs/updating.rst [5] https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/components/centos/centos-openshift-setup/Vagrantfile#L10 [6] https://www.redhat.com/archives/devtools/2016-June/msg00011.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgurung at redhat.com Fri Jun 10 12:51:22 2016 From: bgurung at redhat.com (Budh Gurung) Date: Fri, 10 Jun 2016 18:21:22 +0530 Subject: [Devtools] Proposing design for automating ADB Initialization Message-ID: Hi, Currently, we are setting up ADB environment for customized behaviors through Vagrantfiles present in ADB repo [1] under "components/centos" folder. General flow for setting up any customized behavior like openshift in ADB is as follows: - User go to ADB repo [1] - Navigate to ?components/centos/centos-openshift-setup? folder - User open Vagrantfile in "raw" mode - Download and copy to desired location - User perform further Vagrant operations Whole idea of this proposal is to automate this initial behavior of setting up Vagrantfile in ADB. ### New Behavior Through command line, user will fire only one command to setup Openshift. Example: $ vagrant service-manager init projectatomic/adb --service openshift > > $ ls > Vagrantfile # Vagrantfile for OpenShift Same for Kubernetes and Meso-marathon. ### Points to note for proposed change - - This will be replacement for command "vagrant init projectatomic/adb". - User need not to download any Vagrantfile. Vagrantfile automatically generated as per user configurations. ( Currently user need to download or git clone adb repo [1] and go to respective Vagrantfile ) - Vagrantfiles will be maintained in Vagrant service-manager repo [2] ( Currently, Vagrantfiles are maintained in ADB repo [1] ) - Documentation need to be updated for this change in ADB - Automate the initialization process. Open gate for other automation too. ( Currently no automation ) - Better User experience I would like to know more about what you think about this proposal. Please feel free to give your valuable comments/suggestions. [1] https://github.com/projectatomic/adb-atomic-developer-bundle [2] https://github.com/projectatomic/vagrant-service-manager Regards, Budh Ram Gurung Software Engineer - Dev Tools -------------- next part -------------- An HTML attachment was scrubbed... URL: From surajd at redhat.com Fri Jun 10 13:44:20 2016 From: surajd at redhat.com (Suraj Deshmukh) Date: Fri, 10 Jun 2016 19:14:20 +0530 Subject: [Devtools] Proposing design for automating ADB Initialization In-Reply-To: References: Message-ID: On Fri, Jun 10, 2016 at 6:21 PM, Budh Gurung wrote: > Hi, > > Currently, we are setting up ADB environment for customized behaviors > through Vagrantfiles present in ADB repo [1] under "components/centos" > folder. > > General flow for setting up any customized behavior like openshift in ADB is > as follows: > > User go to ADB repo [1] > Navigate to ?components/centos/centos-openshift-setup? folder > User open Vagrantfile in "raw" mode > Download and copy to desired location > User perform further Vagrant operations > > Whole idea of this proposal is to automate this initial behavior of setting > up Vagrantfile in ADB. Nice Idea, this will save me the hassle of manually downloading the Vagrantfile, which is confusing to new users. > > ### New Behavior > > Through command line, user will fire only one command to setup Openshift. > Example: > >> $ vagrant service-manager init projectatomic/adb --service openshift >> >> $ ls >> Vagrantfile # Vagrantfile for OpenShift > > > Same for Kubernetes and Meso-marathon. > > > ### Points to note for proposed change > > This will be replacement for command "vagrant init projectatomic/adb". > User need not to download any Vagrantfile. Vagrantfile automatically > generated as per user configurations. ( Currently user need to > download or git clone adb repo [1] and go to respective Vagrantfile ) > Vagrantfiles will be maintained in Vagrant service-manager repo [2] ( > Currently, Vagrantfiles are maintained in ADB repo [1] ) > Documentation need to be updated for this change in ADB > Automate the initialization process. Open gate for other automation too. > ( Currently no automation ) > Better User experience > > > I would like to know more about what you think about this proposal. > Please feel free to give your valuable comments/suggestions. > > [1] https://github.com/projectatomic/adb-atomic-developer-bundle > [2] https://github.com/projectatomic/vagrant-service-manager > > > > Regards, > Budh Ram Gurung > Software Engineer - Dev Tools > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -- - Suraj Deshmukh (surajd) https://deshmukhsuraj.wordpress.com https://twitter.com/surajd_ From cdrage at redhat.com Mon Jun 13 13:39:19 2016 From: cdrage at redhat.com (Charlie Drage) Date: Mon, 13 Jun 2016 09:39:19 -0400 Subject: [Devtools] Weekly IRC Nulecule Meeting Message-ID: <20160613133919.GB1@95c0bfec6f60> Another short meeting this week. Not much happeneing in the Nulecule / Atomic App land with the exception of two new PR's added to Atomic App from an outside/community contributor :) https://meetbot.fedoraproject.org/nulecule/2016-06-13/weekly_nulecule_irc_meeting.2016-06-13-13.31.log.html -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From cdrage at redhat.com Tue Jun 14 13:35:20 2016 From: cdrage at redhat.com (Charlie Drage) Date: Tue, 14 Jun 2016 09:35:20 -0400 Subject: [Devtools] Atomic App 0.6.0 Pre-Release Message-ID: <20160614133520.GA1@262819efea53> Hey all, Quite a significant amount of code has been contributed since the 0.5.2 release of Atomic App! We'll be releasing this next version of Atomic App with some major code changes including the change of cmd to API for the Kubernetes provider. If you have any blockers please let us know before we do the release later this afternoon! -- Charlie Drage Red Hat - OSAS Team / Project Atomic 4096R / 0x9B3B446C http://pgp.mit.edu/pks/lookup?op=get&search=0x622CDF119B3B446C From pmuir at redhat.com Thu Jun 16 16:24:24 2016 From: pmuir at redhat.com (Pete Muir) Date: Thu, 16 Jun 2016 17:24:24 +0100 Subject: [Devtools] [Container-tools] [atomic-devel] Call for live demos for Atomic Cluster at Summit, Community Central In-Reply-To: <5762CC5D.5090203@redhat.com> References: <57504BCC.9040801@redhat.com> <57504E02.3020705@redhat.com> <57504F99.8010903@redhat.com> <575862F2.8080406@redhat.com> <5762CC5D.5090203@redhat.com> Message-ID: Josh, We have a lot of videos we created for our last two sprints. If you want some videos to play somewhere, then Ranjith might be able to work with you to pick out ones that have made it to the released OpenJDK, .NET CDK and devstudio/devsuite products. Pete On 16 June 2016 at 16:57, Josh Berkus wrote: > Folks, > > So I still don't have anything approaching a full schedule of live > demos. I know a lot of you are putting together video demos ... it's > completely OK to demo the same thing in the live demo area. > > Let me know. > > > -- > -- > Josh Berkus > Project Atomic > Red Hat OSAS > > _______________________________________________ > Container-tools mailing list > Container-tools at redhat.com > https://www.redhat.com/mailman/listinfo/container-tools From ccoleman at redhat.com Thu Jun 16 16:40:34 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Thu, 16 Jun 2016 12:40:34 -0400 Subject: [Devtools] [atomic-devel] [Container-tools] Call for live demos for Atomic Cluster at Summit, Community Central In-Reply-To: <5762D5BC.9040304@redhat.com> References: <57504BCC.9040801@redhat.com> <57504E02.3020705@redhat.com> <57504F99.8010903@redhat.com> <575862F2.8080406@redhat.com> <5762CC5D.5090203@redhat.com> <5762D5BC.9040304@redhat.com> Message-ID: if "oc cluster up" doesn't work on atomic we have problems. On Thu, Jun 16, 2016 at 12:37 PM, Josh Berkus wrote: > On 06/16/2016 09:24 AM, Pete Muir wrote: >> Josh, >> >> We have a lot of videos we created for our last two sprints. If you >> want some videos to play somewhere, then Ranjith might be able to work >> with you to pick out ones that have made it to the released OpenJDK, >> .NET CDK and devstudio/devsuite products. > > No, this is specifically live demos. I'll have a portable Atomic > cluster with me ... including OpenShift, if I can get it working in > time. Thanks, though. > > -- > -- > Josh Berkus > Project Atomic > Red Hat OSAS > From ccoleman at redhat.com Thu Jun 16 19:36:05 2016 From: ccoleman at redhat.com (Clayton Coleman) Date: Thu, 16 Jun 2016 15:36:05 -0400 Subject: [Devtools] [atomic-devel] [Container-tools] Call for live demos for Atomic Cluster at Summit, Community Central In-Reply-To: <5762EBFD.8020105@redhat.com> References: <57504BCC.9040801@redhat.com> <57504E02.3020705@redhat.com> <57504F99.8010903@redhat.com> <575862F2.8080406@redhat.com> <5762CC5D.5090203@redhat.com> <5762D5BC.9040304@redhat.com> <5762EBFD.8020105@redhat.com> Message-ID: You can get the oc client binaries in the scratch/dynamic setup, right? On Thu, Jun 16, 2016 at 2:12 PM, Josh Berkus wrote: > On 06/16/2016 09:40 AM, Clayton Coleman wrote: >> if "oc cluster up" doesn't work on atomic we have problems. >> > > It only works if openshift is installed, which it isn't by default. And > fully containerized openshift on Fedora Atomic Host is still somewhat of > a work in progress (which I'm working on). > > Did you want to do a demo? > > -- > -- > Josh Berkus > Project Atomic > Red Hat OSAS From pchandra at redhat.com Tue Jun 21 06:15:55 2016 From: pchandra at redhat.com (Preeti Chandrashekar) Date: Tue, 21 Jun 2016 11:45:55 +0530 Subject: [Devtools] Upstream-Process for the ADB Ecosystem Meeting - 20 June 2016 Message-ID: Hi all, Yesterday, we had a discussion on the Upstream-Process for the ADB Ecosystem. The issues discussed and the resulting action items are listed below. For the detailed discussion - https://etherpad.openstack.org/p/upstreamprocess *Release Process:* - Fix and communicate Code freeze dates within the team as well as to the QE. - Co-ordinate with QE team to do end to end testing for sanity every week (devsuite, devstudio on Windows and so on); maybe every Wednesday or Thursday. So that the Dev team would know if there are any blockers by every Monday. This needs to be discussed and confirmed with the QE team - Testing, sanity checking needs to be done by developers too before going to QE *Release Cycles:* 3 week release cycle finalized - Every 3rd Thursday - 3 weeks release cycle seems optimal as it helps get in more features, and is in alignment with the sprint. - If sprint ends on Tue; ADB utils needs to be released the Friday before it. All the other components (ADB, VSM etc) should be released together the Monday before. - QE will get it on the same day (Monday) and test simultaneously. QE needs to do an end to end, sanity check each week and highlight blockers if any. *Review process:* - Identify 2 PR-buddies for each week; whose focus for the relevant time period is to troubleshoot/resolve all PRs in the project repo, connect the relevant people, direct the PR to the respective maintainers. This will help in quick PR reviews and quick integration, ideally PR-Review should start the same day. This week Lala and Budhram have volunteered for this. - For documentation/code feature, start the work on a local feature branch, discuss in the GitHub issue or in the developer feature branch fork and send the PR when the first draft is ready. Discussion should happen before the PR, and not on the PR. - Milestones must be set for every 3 weeks and mentioned in the Git hub, so that it is in sync with the Sprint cycle and makes the priority features obvious. Regards, Preeti -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu Jun 23 22:46:58 2016 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 23 Jun 2016 18:46:58 -0400 Subject: [Devtools] Does anyone remember if CordovaSim had iOS support on Windows? Message-ID: I can't remember https://www.youtube.com/watch?v=H5ry5WpziVw&feature=gp-n-y&google_comment_id=z125xb04pw2vdtnod04cdvroiuqitpx4m34 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gercan at redhat.com Thu Jun 23 22:59:29 2016 From: gercan at redhat.com (Gorkem Ercan) Date: Thu, 23 Jun 2016 22:59:29 +0000 (UTC) Subject: [Devtools] Does anyone remember if CordovaSim had iOS support on Windows? In-Reply-To: References: Message-ID: <6A0B7995D8A027D3.01A56D51-9185-4592-8EFD-A89587474E6E@mail.outlook.com> CordovaSim is basically a skinned browser instance that can simulate core Cordova APIs. So it is independent of any native platforms. I think people are confusing it with iOS simulator because we have realistic iOS device skins. On Thu, Jun 23, 2016 at 6:47 PM -0400, "Burr Sutter" wrote: I can't remember https://www.youtube.com/watch?v=H5ry5WpziVw&feature=gp-n-y&google_comment_id=z125xb04pw2vdtnod04cdvroiuqitpx4m34 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu Jun 23 23:01:29 2016 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 23 Jun 2016 19:01:29 -0400 Subject: [Devtools] Does anyone remember if CordovaSim had iOS support on Windows? In-Reply-To: <6A0B7995D8A027D3.01A56D51-9185-4592-8EFD-A89587474E6E@mail.outlook.com> References: <6A0B7995D8A027D3.01A56D51-9185-4592-8EFD-A89587474E6E@mail.outlook.com> Message-ID: Right, I could not remember any specific limitation on CordovaSim. On Thu, Jun 23, 2016 at 6:59 PM, Gorkem Ercan wrote: > > CordovaSim is basically a skinned browser instance that can simulate core > Cordova APIs. So it is independent of any native platforms. I think people > are confusing it with iOS simulator because we have realistic iOS device > skins. > > > > > On Thu, Jun 23, 2016 at 6:47 PM -0400, "Burr Sutter" > wrote: > > I can't remember >> >> >> >> >> https://www.youtube.com/watch?v=H5ry5WpziVw&feature=gp-n-y&google_comment_id=z125xb04pw2vdtnod04cdvroiuqitpx4m34 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Fri Jun 24 18:06:25 2016 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 24 Jun 2016 14:06:25 -0400 Subject: [Devtools] Questions on containers... Message-ID: We are attempting to get a public forum started. I can generate a lot of newbie questions, but we need some folks to answer :-) https://developer.jboss.org/thread/271221 https://developer.jboss.org/thread/271222 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkazako at redhat.com Tue Jun 28 01:35:29 2016 From: alkazako at redhat.com (Alexey Kazakov) Date: Mon, 27 Jun 2016 21:35:29 -0400 Subject: [Devtools] Deploy Docker images on OpenShift 3 with devstudio & CDK Message-ID: <5771D461.3010301@redhat.com> Hi, Here is one more demo from Fred where he deploys Burr's & Rafael's Helloworld-MSA examples to OS 3.2 via CDK 2.1 and devstudio 10 [1] - https://youtu.be/BnUz2TuL25M [1] https://github.com/redhat-helloworld-msa/helloworld-msa -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmusaji at redhat.com Tue Jun 28 10:54:11 2016 From: mmusaji at redhat.com (Mustafa Musaji) Date: Tue, 28 Jun 2016 11:54:11 +0100 Subject: [Devtools] JBoss Tools page errors Message-ID: Images not loading correctly on this page - http://tools.jboss.org/documentation/howto/os3_deployimage.html Cheers Mus -- Mustafa Musaji Solution Architect Red Hat UK Our mission is to be the catalyst in communities of customers, contributors, and partners creating better technology the open source way. Registered in England and Wales under Company Registration No. 03798903 Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From mhusnain at redhat.com Tue Jun 28 11:17:36 2016 From: mhusnain at redhat.com (Misha Husnain Ali) Date: Tue, 28 Jun 2016 21:17:36 +1000 Subject: [Devtools] JBoss Tools page errors In-Reply-To: References: Message-ID: Thanks for reporting this, Mus. I'll review and fix this first thing tomorrow. On Jun 28, 2016 8:54 PM, "Mustafa Musaji" wrote: > Images not loading correctly on this page - > http://tools.jboss.org/documentation/howto/os3_deployimage.html > > Cheers > Mus > -- > Mustafa Musaji > Solution Architect > Red Hat UK > > Our mission is to be the catalyst in communities of customers, > contributors, and partners creating better technology the open source > way. > > Registered in England and Wales under Company Registration No. 03798903 > Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmalina at redhat.com Tue Jun 28 11:30:06 2016 From: mmalina at redhat.com (Martin Malina) Date: Tue, 28 Jun 2016 13:30:06 +0200 Subject: [Devtools] JBoss Tools page errors In-Reply-To: References: Message-ID: <9C3A5AC7-CC8A-448D-944E-1BDD59C926A7@redhat.com> Seems Misha removed these images in error while removing another article: https://github.com/jbosstools/jbosstools-website/commit/5515dc8cfdd915dee690753602e0e68977304e3b This should fix it: https://github.com/jbosstools/jbosstools-website/pull/597 -Martin > On 28. 6. 2016, at 13:17, Misha Husnain Ali wrote: > > Thanks for reporting this, Mus. I'll review and fix this first thing tomorrow. > > On Jun 28, 2016 8:54 PM, "Mustafa Musaji" > wrote: > Images not loading correctly on this page - > http://tools.jboss.org/documentation/howto/os3_deployimage.html > > Cheers > Mus > -- > Mustafa Musaji > Solution Architect > Red Hat UK > > Our mission is to be the catalyst in communities of customers, > contributors, and partners creating better technology the open source > way. > > Registered in England and Wales under Company Registration No. 03798903 > Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhusnain at redhat.com Tue Jun 28 11:34:32 2016 From: mhusnain at redhat.com (Misha Husnain Ali) Date: Tue, 28 Jun 2016 21:34:32 +1000 Subject: [Devtools] JBoss Tools page errors In-Reply-To: <9C3A5AC7-CC8A-448D-944E-1BDD59C926A7@redhat.com> References: <9C3A5AC7-CC8A-448D-944E-1BDD59C926A7@redhat.com> Message-ID: Yes, I was just investigating and this article was added by Fred and so I removed the old os3_* prefix images when removing the outdated OS3 articles. Adding those images back should be all that's needed. Sorry about the confusion, folks. I didn't think anyone but the docs team was adding any articles here. -- Misha Husnain Ali Technical Writer 2, CCS Brisbane On Tue, Jun 28, 2016 at 9:30 PM, Martin Malina wrote: > Seems Misha removed these images in error while removing another article: > > https://github.com/jbosstools/jbosstools-website/commit/5515dc8cfdd915dee690753602e0e68977304e3b > > This should fix it: > https://github.com/jbosstools/jbosstools-website/pull/597 > > -Martin > > On 28. 6. 2016, at 13:17, Misha Husnain Ali wrote: > > Thanks for reporting this, Mus. I'll review and fix this first thing > tomorrow. > On Jun 28, 2016 8:54 PM, "Mustafa Musaji" wrote: > >> Images not loading correctly on this page - >> http://tools.jboss.org/documentation/howto/os3_deployimage.html >> >> Cheers >> Mus >> -- >> Mustafa Musaji >> Solution Architect >> Red Hat UK >> >> Our mission is to be the catalyst in communities of customers, >> contributors, and partners creating better technology the open source >> way. >> >> Registered in England and Wales under Company Registration No. 03798903 >> Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> > _______________________________________________ > Devtools mailing list > Devtools at redhat.com > https://www.redhat.com/mailman/listinfo/devtools > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmalina at redhat.com Tue Jun 28 11:56:36 2016 From: mmalina at redhat.com (Martin Malina) Date: Tue, 28 Jun 2016 13:56:36 +0200 Subject: [Devtools] JBoss Tools page errors In-Reply-To: References: <9C3A5AC7-CC8A-448D-944E-1BDD59C926A7@redhat.com> Message-ID: <1D7218ED-6E67-484D-BED9-52C952348AF2@redhat.com> Fixed. http://tools.jboss.org/documentation/howto/os3_deployimage.html -Martin > On 28. 6. 2016, at 13:34, Misha Husnain Ali wrote: > > Yes, I was just investigating and this article was added by Fred and so I removed the old os3_* prefix images when removing the outdated OS3 articles. Adding those images back should be all that's needed. Sorry about the confusion, folks. I didn't think anyone but the docs team was adding any articles here. > > > -- > Misha Husnain Ali > Technical Writer 2, CCS Brisbane > > On Tue, Jun 28, 2016 at 9:30 PM, Martin Malina > wrote: > Seems Misha removed these images in error while removing another article: > https://github.com/jbosstools/jbosstools-website/commit/5515dc8cfdd915dee690753602e0e68977304e3b > > This should fix it: > https://github.com/jbosstools/jbosstools-website/pull/597 > > -Martin > >> On 28. 6. 2016, at 13:17, Misha Husnain Ali > wrote: >> >> Thanks for reporting this, Mus. I'll review and fix this first thing tomorrow. >> >> On Jun 28, 2016 8:54 PM, "Mustafa Musaji" > wrote: >> Images not loading correctly on this page - >> http://tools.jboss.org/documentation/howto/os3_deployimage.html >> >> Cheers >> Mus >> -- >> Mustafa Musaji >> Solution Architect >> Red Hat UK >> >> Our mission is to be the catalyst in communities of customers, >> contributors, and partners creating better technology the open source >> way. >> >> Registered in England and Wales under Company Registration No. 03798903 >> Directors:Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools >> _______________________________________________ >> Devtools mailing list >> Devtools at redhat.com >> https://www.redhat.com/mailman/listinfo/devtools > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hferents at redhat.com Wed Jun 29 08:22:25 2016 From: hferents at redhat.com (Hardy Ferentschik) Date: Wed, 29 Jun 2016 10:22:25 +0200 Subject: [Devtools] Questions on containers... In-Reply-To: References: Message-ID: <20160629082225.GC10832@nineveh.lan> Hi, On Fri, 24-Jun-2016 14:06, Burr Sutter wrote: > We are attempting to get a public forum started. I can generate a lot of > newbie questions, but we need some folks to answer :-) > > https://developer.jboss.org/thread/271221 OOI, why developer.jboss.org? This is the worst choice possible imo. There is a whole range of things wrong with developer.jboss.org( eg speed and the actual editing experience). But that apart, how do you see anyone signed up for developers.redhat.com contribute to this forum? So I am currently logged in to developers.redhat.com and follow this link - https://developer.jboss.org/en/products/cdk/ - from http://developers.redhat.com/forums/. Looking at the banners I have the impressions I am still in the developers.redhat.com context. But hey, I am logged out. Trying to now log in again, get me to this error page: >>> Duplicate account You are trying to log in via duplicate account. Please use your master account. Master account is hardy.ferentschik. >>> So it seems that there are conflicts between my JBoss account and the Developers Red Hat one. But even then, say I did not have a JBoss account, would I now have to register to one in order to participate in the blog? And how does one know. The whole L&F is kept in a way to suggest you are still on Red Hat Developers. It keeps amazing me how many logins, re-directs, license agreements, etc one has to jump using developers.redhat.com. This is patch work at best. If I'd tried the site having no ties to Red Hat, you'd already lost me. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: