Re: Layer-Supervisor

One thing (which I haven't done yet in some of my layers) is to place your supervisorlib in `lib/charms/layer`. A nice first start though! On Thu, Jul 21, 2016 at 4:39 AM, Stuart Bishop wrote: > On 21 July 2016 at 10:40, James Beedy wrote: > > > I'll take all the input/feedback/criticism I can

Re: Layer-Supervisor

A big thanks to those of you who gave feedback! I have made some revisions based on the suggestions I received from a few of you (thank you!), and would like to get a second round of feedback now the modifications have been made -> [layer-supervisor]( https://github.com/jamesbeedy/layer-supervisor

Re: Layer-Supervisor

looks good, one small nit pick, maybe change supervisorlib.py to just supervisor.py. that seems to be the current naming scheme of things On Thu, Jul 21, 2016 at 1:42 PM, James Beedy wrote: > A big thanks to those of you who gave feedback! I have made some revisions > based on the suggestions I

Re: Layer-Supervisor

Greetings James, +1 to Adams suggestion. A question about the readme examples: There's a given example where you're getting a Workers() object but it isn't imported, or declared. Where did it come from? @when('myapp1.supervisor.available', 'myapp2.supervisor.available')def run_workers():

Re: Layer-Supervisor

Thank you all, for your feedback! @alex tracking @adam 10-4 @charles | That all makes sense -the reason I wanted it in lib, was because I was leaving it open to the user of the layer to configure supervisor for their app(s). Would it be preferable to have the user specify a list of ap

Re: Juju Secrets

On 25/07/16 06:32, James Beedy wrote: Proposed Solution: Juju Secrets To give Juju a combative edge on the privacy pinwheel of secrets distribution in the realm of bleeding edge devops tooling, behold my hypothetical proposed solution: |juju secrets|. Juju secrets could be used like so: |juju

Re: Juju Secrets

Tim, Great questions. I feel like I should of expanded a bit more on what a “secret” might be after I sent that off…. To me, a secret is something you don’t want anyone to know - that being said, the best approach for looking at “secrets” might be to think as restrictively as possible. For the s

Re: Apache Aria

Thanks for sending this! I knew it existed, but I didn't know it is in Apache Incubating. 2016-07-22 20:21 GMT+02:00 Tom Barber : > Dunno if it's of any interest to the juju developers but this landed > recently https://wiki.apache.org/incubator/AriaProposal > > Tom > > -- > Juju mailing list > J

Re: Apache Aria

Thanks for sharing. It is heavily pushed by Cloudify and we have discussions on-going for integrating with them. I did not know they pushed for being an Apache project very useful piece of information. Hope this helps, On Tue, Jul 26, 2016 at 11:55 AM, Merlijn Sebrechts wrote: > Thanks for s

Re: Apache Aria

Any idea what an integration would look like? Juju supporting TOSCA models? Aria driving Juju (like it does with Chef)? or something else? 2016-07-26 14:07 GMT+02:00 Nicolas Thomas : > Thanks for sharing. > > It is heavily pushed by Cloudify and we have discussions on-going for > integrating with

Re: Apache Aria

+Arthur from Gigaspaces(newly subscribed to jujulist) can provide more details on Aria and the potential of a juju plugin. There is also upcoming workshop regarding integration between http://getcloudify.org/ (as an NFV orchestrator) leveraging TOSCA for Topology and W

Re: Apache Aria

Thanks Nicolas, thats a really interesting plan! Looking forward to find out more. Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart

Re: BDX <-> Juju

h cluster had been compromised, by spinning up a new Juju deployed elasticsearch cluster immediately, and getting it re-indexed within a few hours - this was overseen by our VP of technology and made a huge impression with our higher ups (first day on the job). I have since created an infrastructure

Re: BDX <-> Juju

lication whose > elasticsearch cluster had been compromised, by spinning up a new Juju > deployed elasticsearch cluster immediately, and getting it re-indexed > within a few hours - this was overseen by our VP of technology and made a > huge impression with our higher ups (first day on t

Re: Juju Secrets

that another layer in the same charm can't get to it)? But we could cut out the ability for anything but software running on that machine to read it. I'm not sure if the cost/benefit is really there, as if you want to deploy 2 units of the software, you have to re-encrypt the original se

Re: Regarding Terms

Just replying publicly to confirm that this was done earlier this morning Thanks Matty On Thu, Aug 11, 2016 at 10:30 AM, Shruthima Almavar wrote: > Hi, > We have sent a request for terms creation through the terms link ( > https://docs.google.com/forms/d/1sOfp0a6KLY9kqnpPeGwHv_ > YQJv7LEbXH1CA

Re: Juju Secrets

ecrets, we encrypt the values with that public key, and > not even the controller has access anymore. Still can't do per-layer > secrets (cause where can a layer store a secret that another layer in the > same charm can't get to it)? But we could cut out the ability for anythin

Re: Bootstraping Rackspace

James, what good timing. The streams with image info is just going through getting setup. https://bugs.launchpad.net/juju/+bug/1625243 It took a bit for the images for trusty/xenial to get setup and the team's working to make it all work out of the box. We had demo streams up for testing and it'

Re: Bootstraping Rackspace

On 19/09/16 16:19, James Beedy wrote: > I am trying to bootstrap the rackspace provider and cannot seem to get > past "ERROR failed to bootstrap model: no image metadata found". Do I > need to generate metadata for rackspace provider? I feel like I need > to get some images in rackspace and generat

Re: Bootstraping Rackspace

Awesome! Thanks! > On Sep 19, 2016, at 7:18 PM, Rick Harding wrote: > > James, what good timing. The streams with image info is just going through > getting setup. > > https://bugs.launchpad.net/juju/+bug/1625243 > > It took a bit for the images for trusty/xenial to get setup and the team's

Re: Bootstraping Rackspace

Thanks, Mark! By interactive bootstrap, do you mean interactive add-credentials? If so, I think it already exists for RAX, but isn't quite spot on yet. It looks like I should be able to get bootstrapped with the information contained in the bug link in Rick's response. ~James > On Sep 19, 2016

Re: Bootstraping Rackspace

On 19/09/16 23:36, James Beedy wrote: > Thanks, Mark! By interactive bootstrap, do you mean interactive > add-credentials? If so, I think it already exists for RAX, but isn't quite > spot on yet. It looks like I should be able to get bootstrapped with the > information contained in the bug link

Re: Thank You!

Thanks Tom, it was a good week and glad you got something out of the time there. I know it's exciting for us in Engineering to directly chat with folks using and abusing our tools. It's exciting to see what you all do with what we've built and to help motivate us to keep at it so that we can take t

Re: Zuul Charm

Hey James, I think this is the best way about it for the time being, discussing what people are working on ahead of it being perfect gives everyone a chance to see what's going on and can help focus people on getting help from others interested! On Wed, Nov 2, 2016 at 10:48 AM James Beedy wrote:

Re: Zuul Charm

As Zuul is an OpenStack project, I'd like to see this developed in line with the other OpenStack Charms. I would be happy to help light the path along the way to ensure that all efforts are as efficient as possible, and that the resultant layer(s), interface(s) and charm(s) can leverage the powerf

Re: Zuul Charm

ie. Project repos would be born, developed and maintained here. :-) https://github.com/openstack?query=charm On Wed, Nov 2, 2016 at 12:28 PM, Ryan Beisner wrote: > As Zuul is an OpenStack project, I'd like to see this developed in line > with the other OpenStack Charms. I would be happy to hel

Re: Crashdump plugin

Nice, one thing you could do is tie this in with sosreport and just run that against the machines. It already has support for juju, lxd, openstack, etc. https://github.com/sosreport/sos And a list of all the plugins we support are here: https://github.com/sosreport/sos/tree/master/sos/plugins On

Re: Crashdump plugin

Hello, Le 04/11/2016 à 03:43, Adam Stokes a écrit : > Nice, one thing you could do is tie this in with sosreport and just run that > against the machines. It already has support for juju, lxd, openstack, etc. > > https://github.com/sosreport/sos > > And a list of all the plugins we support are h

Re: Crashdump plugin

Oooh, nice. Glad to know that pulling relevant info for all those projects with plugins is nice and easy. New build in the ppa with some flags just for anybody who wants to get down and dirty... (-s --enable-sos) & (-S --sos-options), made it optional for now, but if it works well (and maybe we ca

Re: Versioned Resources

On Sun, Nov 13, 2016 at 6:03 PM James Beedy wrote: > Do we have access to managing separate versions of a resource > pragmatically? To give some context, I'm trying to implement rollback > functionality for resources deployed in our applications. Implementing > rollback is proving difficult becau

Re: Juju & Mesos

Oh also, if you ran your workloads on Mesos, you could mix LXC and Docker. I guess people could add LXC support to K8S for the same outcome, either way having a provider that could cope with that would be awesome. On Fri, Nov 18, 2016 at 11:27 AM, Tom Barber wrote: > I'll fork this so we're not

Re: Juju & Mesos

On 18/11/16 11:27, Tom Barber wrote: > Who said Mesos or DC/OS providers and charms wouldn't get official > support? That said currently we're just lacking bandwidth to build > them(I speak entirely as an impartial observer I have no real idea if > they'd get Canonical support, but why not?) ;) We

Re: Juju & Mesos

I'm mostly working with researchers and people developing early prototypes. I can't blame them for using technologies that aren't production ready. That said, I attended pragmatic docker days a while back and there were some companies, like Yelp, who found a good way to run Docker in production so

Re: Juju & Mesos

You mention stateless, thats fine, but for example, if you have sessions in a web app, you'd need to share the sessions etc, so autoscaling isn't really any different to juju add-unit except you've got some stuff to monitor load and do it without user intervention. Also you'll find the flip side to

Re: Juju & Mesos

2016-11-18 15:43 GMT+01:00 Tom Barber : > You mention stateless, thats fine, but for example, if you have sessions > in a web app, you'd need to share the sessions etc, so autoscaling isn't > really any different to juju add-unit except you've got some stuff to > monitor load and do it without use

Re: Juju & Mesos

Okay, it transpires some of my Java guys also know C who knew. Anyway, they have been tasked with adding LXC/LXD support to Apache Mesos which we'll push upstream assuming they want it. My plan is to then extend Marathon to support LXD deployments and from that we'll then build a Juju provide

Re: Juju & Mesos

OMGOMGOMG 2016-11-24 16:47 GMT+01:00 Tom Barber : > Okay, it transpires some of my Java guys also know C who knew. > > Anyway, they have been tasked with adding LXC/LXD support to Apache Mesos > which we'll push upstream assuming they want it. My plan is to then extend > Marathon to support

RE: Deployment Oversight

Was a bit flustered earlier when I sent off this email, I've looked a bit closer at each of the individual problems, thought I would report back with my findings. 1. Job for systemd-sysctl.service failed because the control process exited - This is an error I'm seeing when installing juju (not

Re: Deployment Oversight

I feel you, James We've been battling with weird issues / compatibility problems with the manual provider on private infra for the past year. Just finding out where the problem is requires diving deep into the internals of Juju and the Charms. In the end, we patched our own servers heavily and had

Re: Deployment Oversight

>From what I can tell, there are a number of places where these manual machines differ from our "standard" install. I think the charms can be written defensively around this, but its why you're running into more issues than you normally would. 1. 'noexec' for /tmp. I've heard of this, but as la

Re: Deployment Oversight

That's very true on the items that are different. I wonder if we could work with the CPC team and note the things that are assumed promises when using cloud images so that it'd be easy to build a "patch" for manually provisioned machines. If we know specific packages or configuration is there on ou

Re: Deployment Oversight

Super difficult to document 'the ocean', there will always be fraying at the edges that what worked on clouds fails in the manual case. Mark On 28/11/16 15:49, Rick Harding wrote: > That's very true on the items that are different. I wonder if we could > work with the CPC team and note the thing

Re: Deployment Oversight

I wouldn't want to be in your shoes in a pre-snappy world... I'm amazed that Ubuntu still works so well in the ocean. We found a way to mitigate most of the issues: run everything exclusively in LXC containers. This gave us the standard cloud image that all these Charms are being tested on. This a

Re: Juju & Mesos

+1 This sounds really interesting. Keep me apprised, please? I'd love to see if there's some integration work we can do here (on top of the kubernetes => mesos integration) Charles Butler - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com On Thu, Nov 24, 2016

Re: Deployment Oversight

Merlin, Thanks for your insight here, and I totally agree with you, "running everything in LXD containers is a very good starting point" - simply because we can guarantee that everything works as tested/expected, right? To the extent of trying to hack lxd/lxc networking, I think a generic openvsw

Re: Deployment Oversight

On 28/11/16 17:21, Merlijn Sebrechts wrote: > > What I suggest is that you stop trying to make Juju work in 'the > ocean' and focus the manual environment efforts on one thing: a > multi-machine LXD provider. *Fix the LXD networking and DNS issues and > tell everyone to only use LXD containers in a

Re: Deployment Oversight

Just wanted to let everyone know (thanks to lots of help) that I've rendered a successful manual provider deploy :-) This will be my first production deploy for CreativeDrive, you can take a peek at the success here -> http://paste.ubuntu.com/23551183/ I've created a temporary repo for my prm-web

Re: Deployment Oversight

On 29/11/16 11:26, James Beedy wrote: > Just wanted to let everyone know (thanks to lots of help) that I've > rendered a successful manual provider deploy :-) \o/ > This will be my first production deploy for CreativeDrive, you can > take a peek at the success here -> http://paste.ubuntu.com/2355

Re: Deployment Oversight

Perfect deploys across lxd, ec2, and manual providers! EC2 - http://paste.ubuntu.com/23551492/ LXD - http://paste.ubuntu.com/23551496/ Manual - http://paste.ubuntu.com/23551498/ On Mon, Nov 28, 2016 at 5:28 PM, Anastasia Macmood < anastasia.macm...@canonical.com> wrote: > > > On 29/11/16 11:2

Re: Deployment Oversight

On 28/11/16 21:53, James Beedy wrote: > Perfect deploys across lxd, ec2, and manual providers! > > EC2 - http://paste.ubuntu.com/23551492/ > LXD - http://paste.ubuntu.com/23551496/ > Manual - http://paste.ubuntu.com/23551498/ That's how we like it :) -- Juju mailing list Juju@lists.ubuntu.com Mo

Re: Kubernetes Provider

Same question got asked yesterday(lxd on kub). Marks answer was it's not roadmapped but make it great and someone will make it happen. On 3 Jan 2017 17:18, "James Beedy" wrote: > Is there any work currently being done out there for a kub provider? Has > anyone looked into this yet? > -- > Juju m

Re: Orchestration charms

Hi Simon, I'm glad you asked about this. The need for certain services to operate on the controller for autoscaling and other purposes has come up before. Juju's considering exposing different aspects of the controller as applications -- for monitoring, log access and other aspects of operating th

Re: Kubernetes icon

Thanks Tom, A fix for the broken link has landed a few days ago. Therefore will be fixed with the next release. All the best, Ant. On Mon, 16 Jan 2017 at 10:40 Tom Barber wrote: > Canonical-ers, > > Has anyone clocked the k8s icon in the search box on jujucharms.com has > been broken for about

Re: Kubernetes icon

Also, if you click the link, it tells you 404, maybe you want something else. It looks like it switched from being called "kubernetes" to being called "kubernetes-core", and the quick link didn't get updated. John =:-> On Mon, Jan 16, 2017 at 3:17 PM, Anthony Dillon < anthony.dil...@canonical.co

Re: Kubernetes icon

whilst we're on it Why when you click spark do you end up at: https://jujucharms.com/u/asanjar/spark/ and not cs:apache-spark or whatever the mainline one is? :) Tom On Mon, Jan 16, 2017 at 11:20 AM, John Meinel wrote: > Also, if you click the link, it tells you 404, maybe you want someth

Re: Kubernetes icon

Searching for "spark" the first response is: https://jujucharms.com/apache-spark/10 But you're right that the little icon that you see in the quick list is asanjar/spark. I wonder if it happened to be used more often than the official one. I don't know how that list is generated. John =:-> On M

Re: Kubernetes icon

Funny you should mention that Tom. The branch that landed a few days ago updated the kubernetes link to /canonical-kubernetes and the spark link to /spark. The list was generated before we had a promulgated spark charm. On Mon, 16 Jan 2017 at 11:27 John Meinel wrote: > Searching for "spark" the

Re: Orchestration charms

On 11/01/17 07:03, Casey Marshall wrote: > > On Mon, Jan 9, 2017 at 11:53 AM, Simon Kollberg > mailto:simon.kollb...@elastisys.com>> > wrote: > > Right now, the user needs to manually provide credentials (via the > charm > config) to the CharmScaler enabling it to connect and execute >

Re: Giraf demo

Hi! One really intriguing and fun example of what you can do with giraph is the algorithm of Backstrom and Kleinberg [1] that uses only network structure to order your friends according to their probability of being in a relationship with you. I have implemented it for Giraph (~50 lines of Java co

Re: Giraf demo

On 07/03/17 06:44, Panagiotis Liakos wrote: > In terms of performance, the giraph distribution features examples of > algorithms such as PageRank or ShortestPaths. OK. Are there actions on the charms to kick these off? Also, is the I/O all text based or is there a Giraf GUI? I won't have a lot of

Re: Giraf demo

> OK. Are there actions on the charms to kick these off? > The smoke-test in the charm executes PageRank on a very small graph: https://github.com/panagiotisl/bigtop/blob/master/bigtop-packages/src/charm/giraph/layer-giraph/actions/smoke-test#L54 For some reason the giraph-examples.jar (with Page

Re: User Groups

On 08/03/17 07:52, James Beedy wrote: > Managing users with Juju currently does not scale. Can we associate > users with groups please? > > Find bug here -> https://bugs.launchpad.net/juju/+bug/1671149 Yes, this is on-roadmap. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or

Re: ssh keys

This is definitely on the todo list. It's completely correct that users should be able to manage their own keys. On Wed, Mar 8, 2017 at 11:01 AM James Beedy wrote: > I'm quickly finding myself maintaining users ssh keys. How do people feel > about making ssh keys bound to the user instead of the

Re: Goodbye Opsworks

On Mar 31, 2017 7:06 PM, "James Beedy" wrote: The day has finally come for me to turn down the last of our Opsworks instances for our PRM application. This marks the completion of one of many Opsworks -> Juju conversion projects I've taken on. Thanks everyone for your help along the way! Goodbye

Re: Goodbye Opsworks

Whaow congrats! Do you have a blog post in the work for this explaining the process? Best, Sam -- Samuel Cozannet Cloud, Big Data and IoT Strategy Team Business Development - Cloud and ISV Ecosystem Changing the Future of Cloud Ubuntu / Canonical UK LTD

Re: Goodbye Opsworks

Nice work, bdx :) On Fri, Mar 31, 2017 at 8:06 PM, James Beedy wrote: > The day has finally come for me to turn down the last of our Opsworks > instances for our PRM application. This marks the completion of one of many > Opsworks -> Juju conversion projects I've taken on. Thanks everyone for >

Re: Goodbye Opsworks

Any ideas to write a blogpost about it? I'm curious about what problems Juju solves that were hard with opswork and your experience in making the switch. 2017-04-01 3:06 GMT+02:00 James Beedy : > The day has finally come for me to turn down the last of our Opsworks > instances for our PRM applica

Re: Goodbye Opsworks

Sam & MerIijn, I'll be working on a blog post for it this week, I'll ping the list when it's ready. > On Apr 3, 2017, at 7:11 AM, Merlijn Sebrechts > wrote: > > Any ideas to write a blogpost about it? I'm curious about what problems Juju > solves that were hard with opswork and your experien

Re: Thank you!

A very big +1 Any official word on what this will mean for Juju? 2017-04-20 12:43 GMT+02:00 Tom Barber : > I'll probably get whipped for doing this as its been playing on my mind > and I feel it needs doing. > > Hopefully those who have left the company in the last few weeks haven't > completely

Re: Thank you!

On Thu, Apr 20, 2017 at 7:08 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > > > Any official word on what this will mean for Juju? > The changes you hear about don't change the direction of Juju. We're still focused on building a great platform for modeling and solving the software

Re: Thank you!

What about speed an velocity? Does a more focused Canonical mean more resources for Juju? -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Re: Thank you!

On 20/04/17 13:27, Merlijn Sebrechts wrote: > What about speed an velocity? Does a more focused Canonical mean more > resources for Juju? With good reason the team is unlikely to be comfortable answering your question, but I am happy to do so. Juju is essential to our success with large customer

Re: CDK + Deis

Hi James, Deis is definitely on my map, I am happy to participate in the effort. Afaik, the 2 main issues are * getting Postgresql and Minio to have persistent storage. * Managing the expectation of ELB vs Ingress. This is pretty easy on AWS, I guess a little less on the metal bc LB. Not sure on

Re: CDK + Deis

On 22/04/17 00:44, Samuel Cozannet wrote: > Deis is definitely on my map, I am happy to participate in the effort. > Afaik, the 2 main issues are > * getting Postgresql and Minio to have persistent storage. > * Managing the expectation of ELB vs Ingress. I think it's an excellent thing to offer,

Re: Gitlab & SSL

Awesome! Is the code of gitlab online somewhere? https://github.com/osbi/layer-gitlab seems to be outdated. 2017-04-26 14:19 GMT+02:00 Tom Barber : > Hey folks > > After some prodding from Rick I updated my Gitlab charm and ensured it > worked with Tengu's fantastic new SSL termination proxy char

Re: Gitlab & SSL

Yeah thats the place, hadn't pushed it. Still got some more work to clean up the config setting a bit, and me and Chuck were mulling over exposing the CI and Docker Repo which I currently don't do. One thing we'd like is Gitlab <-> EasyRSA connectivity and then to K8S so you can setup a private do

Re: Search results

> On 27 Apr 2017, at 14:44, Tom Barber wrote: > > Of course getting them recommended is also something you guys want to happen > and something a lot of the community charms are working towards, but this > seems unnecessarily restrictive. Hey Tom, we agree with you, and we are working on impr

Re: Python-Django

The python-Django charm is largely outdated in many respects. I have been meaning to do a deep dive on it and turn it into something usable (there have been a few attempts at this over the years we can also look at). I can apply some of the goodies I've developed for my rails-layer in the Django

Re: GUI Props

Happy to hear you like the new features in the release, James. You're right, current account page is just a start and we're excited about the things that are yet to come. SSH keys handling is on that list for sure. Thank you and the rest of the community for providing feedback and feature requests

Re: set_remote() <-> get_local()?

get/set_remote deal with relation data sent over the wire. get/set_local never leave the unit in question and are simply there as a way to associate information locally with a given remote unit. Generally speaking, get/set_local aren't actually what you want, and I wouldn't recommend using them.

Re: docker -> lxdbr0

This definitely sounds interesting. You included the layer python code, but not the "daemon.json.j2" file. Isn't that part of getting the networking config in place? John =:-> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy wrote: > On integrating docker and lxd deployed apps ... > > My charm in

Re: docker -> lxdbr0

It's in the comments at the top of the gist. > On Jun 20, 2017, at 10:31 PM, John Meinel wrote: > > This definitely sounds interesting. > > You included the layer python code, but not the "daemon.json.j2" file. Isn't > that part of getting the networking config in place? > > John > =:-> > >

Re: docker -> lxdbr0

Gotcha. Though I will say that looks more like its a bogus comment about a file that this isn't. But I see what you're doing. John =:-> On Wed, Jun 21, 2017 at 5:29 PM, James Beedy wrote: > It's in the comments at the top of the gist. > > On Jun 20, 2017, at 10:31 PM, John Meinel wrote: > > T

Re: docker -> lxdbr0

It really does ... don't know why I didn't just add the extra file. I've fixed this. Thanks! > On Jun 21, 2017, at 6:32 AM, John Meinel wrote: > > Gotcha. Though I will say that looks more like its a bogus comment about a > file that this isn't. But I see what you're doing. > > John > =:-> >

Re: Upgrading juju2

On 13/06/17 04:25, Mario Splivalo wrote: > Hi, ladies and lads! > > I am verifying the juju upgrade procedure and I ran into some > ‘misunderstandings’ which I’m hoping could be clarified out here. > > I am running juju 2.0.0 and the plan is to upgrade it to the latest 2.1 > version, which is cur

Re: new ceilometer

Hi Giuseppe, First of all, thank you for looking into writing a gnocchi charm! There is already an ongoing effort from James Page on charming gnocchi: https://github.com/openstack-charmers/charm-gnocchi https://github.com/openstack-charmers/charm-interface-gnocchi https://review.openstack.org/#/

Re: kubectl run

This works for me: kubectl run -it db2express-c --port=5 --env DB2INST1_PASSWORD=db2inst1 --env LICENSE=accept --image ibmcom/db2express-c:latest -- bash On Thu, Aug 31, 2017 at 3:17 PM, Micheal B wrote: > Trying to convert a Docker run to kubectl > > > > Working thru > > > > https://hub.do

Re: kubectl run

Thank you! From: Tim Van Steenburgh Date: Thursday, August 31, 2017 at 3:33 PM To: Micheal B Cc: juju Subject: Re: kubectl run This works for me: kubectl run -it db2express-c --port=5 --env DB2INST1_PASSWORD=db2inst1 --env LICENSE=accept --image ibmcom/db2express-c:latest

Re: PostgreSQL PITR

Awesome feature and write-up, thanks Stuart! On Fri, Sep 1, 2017 at 10:28 AM, Stuart Bishop wrote: > Hi. > > The PostgreSQL charm has some point in time recovery features we have > been using on production. I've put together a walk through of the > feature for others who might be interested in u

Re: External IP's

Hi Micheal, You don't get the external IP automatically because the k8s cloud-provider flag is not automatically set to vsphere for you (yet). When you deploy to AWS with conjure-up, we set the k8s cloud-provider for you so that you can use AWS features like ELBs and EBS. We intend to add this na

Re: External IP's

https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1 Best regards, Alex Goretoy Goretoy Web Services - CEO a...@goretoy.com https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1 Senior Solutions Architect Entrepreneur

Re: vsphere support

Hi 6.0 should work. It does for me and even 6.5. I already have offered the devs that they can use my environment to sort out all the open bugs. But so far nobody was willing to do so. What i did maybe helpful do you... #!/bin/bash maas - machines add-chassis chassis_type='vmware' usern

Re: vsphere support

Hi Serge, >From my perspective Juju will continue getting more support for vSphere provider as VMware is used by some customers that do not want to go with a full-blown bare-metal deployment and just have spare VMs. I personally had to do a deployment of K8s on ESX (don't remember which version t

Re: vsphere support

Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): > Hi > > 6.0 should work. It does for me and even 6.5. Ok - like I say I only have the one 6.0 so not ideal, but a starting point. > I already have offered the devs that they can use my environment to > sort out

Re: vsphere support

Hi Thats typical me. I implied that you use maas and have trouble setting it up with juju as a cloud. Pardon me. Thats how i work ;-) BR   Christian Quoting "Serge E. Hallyn" : Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): Hi 6.0 should work. It

Re: vsphere support

Well if using MAAS would be easier, I'm happy to do that. I actually just hadn't considered it a possibility, but I see at https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh that it may be :) I wonder what would be the difference in range of charms that I ca

Re: vsphere support

There really shouldn't be any difference in the charms that are deploy-able on MAAS vs vSphere. The Juju team has made a lot of strides in 2.2 and the upcoming 2.3 release to support vSphere directly. MAAS management of vSphere is slightly different than Juju if I recall correctly, but shouldn't im

Re: vsphere support

Hi I have a openstack charm installation and kubernetes cluster running currently. I  remember trying vsphere support as well but it didnt work. sorry but that just came to my mind. so i was bound to use maas in order to use vsphere and juju. BR   Christian Quoting "Serge E. Hallyn"

Re: vsphere support

Quoting Dmitrii Shcherbakov (dmitrii.shcherba...@canonical.com): > Hi Serge, > > >From my perspective Juju will continue getting more support for vSphere > provider as VMware is used by some customers that do not want to go with a > full-blown bare-metal deployment and just have spare VMs. Ok, th

Re: vsphere support

On Wed, Oct 4, 2017 at 12:09 PM Serge E. Hallyn wrote: > Hi, > > I've inherited a few vsphere machines where I was hoping to use juju > to fire off openstack etc. I've been trying to use the vsphere > provider (which I was excited to see existed), but am seeing a few > inconsistencies, so had a

<    1   2   3   4   5   6   7   8   9   10   >