Re: [Openstack-operators] Windows images

Hi Abel, Getting CloudBaseInit to work the way we wanted required quiet an effort (Mathieu Gagné could talk you through) and we build our own images. However licencing is relatively simple: we use a KMS server that activates the licences. Cheers, Le 2014-11-14 16:56, Abel Lopez a écrit : I

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

>On 15 November 2014 07:57, Kris G. Lindgren wrote: >> I personally am hoping for a clear definition of what "stable" actually >> means. > >Congruence on that is critical. Agreed. > >> I know we (Godaddy) try to stay on stable releases and not >> run on trunk, I assume a majority of other op

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

On 15 November 2014 07:57, Kris G. Lindgren wrote: > I personally am hoping for a clear definition of what "stable" actually > means. Congruence on that is critical. > I know we (Godaddy) try to stay on stable releases and not > run on trunk, I assume a majority of other operators do as well. S

[Openstack-operators] Windows images

I spoke at length about Linux images at the Paris summit, I'm curious about what others are doing with Windows images. The closest thing I can think of is Redhat, which is "free" to use, but requires an entitlement for support. Windows requires a license to use. How do others deal with registrat

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

>> I do agree that we do not have a way to enforce this but the >> community could find one, I'm sure. > [...] > > as a community the > feedback loop we have to solicit non-voluntary resource dedication > is somewhat limited (we can ask the Foundation Board, "hidden > influencers" and other member

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

On 2014-11-15 07:22:32 +1100 (+1100), Roland Chan wrote: > On 15/11/2014 1:46 am, "Jeremy Stanley" wrote: > > the truth is that work on these projects is entirely voluntary > > and we have no effective way to enforce a decree like that. > > I don't think that's entirely correct. A large, potentia

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

Just an aside: One thing that I noticed is there seems to be a disconnect as to what "operators" see as technical debt and what developers see as technical debt. Personally, I see technical debt more inline with projects having xxx bug backlog, ___ feature while implemented is done in a less t

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

On 15/11/2014 1:46 am, "Jeremy Stanley" wrote: > the truth is that work on these projects is entirely > voluntary and we have no effective way to enforce a decree like > that. I don't think that's entirely correct. A large, potentially overwhelming, majority of committers seem to be paid to work

Re: [Openstack-operators] Latest stable OpenStack version

Awesome! Upgrade time :) Thanks! On 14 Nov 2014 19:57, "Abel Lopez" wrote: > Juno is considered "Stable" > https://www.openstack.org/software/juno/ > > On Nov 14, 2014, at 11:46 AM, Alex Leonhardt > wrote: > > Hi all, > > I was wondering what the latest stable OpenStack version is? Is it still

Re: [Openstack-operators] Latest stable OpenStack version

Juno is considered "Stable" https://www.openstack.org/software/juno/ > On Nov 14, 2014, at 11:46 AM, Alex Leonhardt wrote: > > Hi all, > > I was wondering what the latest stable OpenStack version is? Is it still > Icehouse? > > Thanks > Alex > _

[Openstack-operators] Latest stable OpenStack version

Hi all, I was wondering what the latest stable OpenStack version is? Is it still Icehouse? Thanks Alex ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] cloud-init: ssh-keys for host changed after global reboot

Can u open a bug with cloud-init with logs of what happened (/var/log/cloud-init.log) I don't believe this should happen (unless the instance id changed), There was a bug in an older version of cloud-init that may have caused this so knowing the cloud-init version would be good to. Thanks, Jo

[Openstack-operators] OpenStack Community Weekly Newsletter (Post Paris)

How Operators Can Get Involved in Kilo #OpenStackSummit Maish Saidel-Keesing participated in the Ops Summit: How to get involved in Kilo

Re: [Openstack-operators] Monasca: Monitoring as a Service (at scale)

Hi Zee, We also operate Nagios for our internal operational monitoring in HP's public cloud and have a lot of experience with it. One of the motivations for developing Monasca is based on the problems we encountered with Nagios, of which scale, data retention, management/administration and elas

Re: [Openstack-operators] Monasca: Monitoring as a Service (at scale)

Hi David, We currently don't build debs hosted for public consumption. This is something we could work on in the future. Regards --Roland From: David Medberry mailto:openst...@medberry.net>> Date: Friday, November 14, 2014 at 8:45 AM To: Roland Hochmuth mailto:roland.hochm...@hp.com>> Cc: "open

Re: [Openstack-operators] Monasca: Monitoring as a Service (at scale)

Hi Roland, Thanks! Where are the Ubuntu packages? We don't allow pip-only packages in our environment? -dave On Fri, Nov 14, 2014 at 8:02 AM, Hochmuth, Roland M wrote: > Hi Ops Folks, I want to let you all know about a relatively new > open-source monitoring project called "Monasca", which is

[Openstack-operators] Monasca: Monitoring as a Service (at scale)

Hi Ops Folks, I want to let you all know about a relatively new open-source monitoring project called "Monasca", which is monitoring-as-a-service (at scale). Monasca was initially developed to address many of the problems, experiences and lessons learned from operating our operational monitoring

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

On 2014-11-14 20:08:25 +1100 (+1100), Roland Chan wrote: > Re the first 6 months of backporting: "should" would be better > than "may" and "will" would be best. "may' sets an expectation > that looks a lot like a shrug. It's fine as a lower bound on > backporting behaviour, but as an expectation se

Re: [Openstack-operators] cloud-init: ssh-keys for host changed after global reboot

We do not use config drive, only metadata server. I think it somehow related to non-working (for some time) metadata server and standalone instances booted without metadata (we reboot them after, but cloud-init still can mess up...) On 11/14/2014 04:21 AM, Abel Lopez wrote: Haven't seen that m

[Openstack-operators] Fwd: [openstack-dev] [all] config options not correctly deprecated

Hello, For those who aren't scrutinizing the openstack-dev mailing list, Derek Higgins from the TripleO team found an "interesting" behavior in oslo.config: it doesn't log warnings when deprecated options are used [1]. I'm pretty sure that at some point, deprecated options used to be logged but app

Re: [Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

Hi Tom Re the first 6 months of backporting: "should" would be better than "may" and "will" would be best. "may' sets an expectation that looks a lot like a shrug. It's fine as a lower bound on backporting behaviour, but as an expectation setter it's pretty weak. -- Roland Chan Aptira On 14 No

[Openstack-operators] Fwd: [openstack-dev] [stable] Organizational changes to support stable branches

Hi Ops, Please see below excerpt from developer ML email regarding changes to stable branches. I think this is going to make life better :) Thanks to those of you who participated in the discussions at the summit. The stable team always needs help, so if you're interested in finding out more, you