Re: [openstack-dev] [kolla] LXD driver in nova

[Mark Baker]

There is a python nova-lxd binary (.deb) as part of Ubuntu OpenStack. To
enable this a good place to start is James Page's blog:

https://javacruft.wordpress.com/2017/09/01/openstack-pike-for-ubuntu-16-04-lts/

The cloud archive wiki page is also worth checking:

https://wiki.ubuntu.com/OpenStack/CloudArchive





Best Regards


Mark Baker

On 4 January 2018 at 10:52, Eduardo Gonzalez <dabar...@gmail.com> wrote:

> Hi João,
>
> It would be possible but there is not any  container image with the
> nova-lxc code on it at the moment. (No binary rpm in RDO neither)
>
> Only supported drivers (for now) are: kvm, qemu, vmware and hyperv (xen in
> progress).
>
> Feel free to add lxd as driver into the project :)
>
> Regards
>
> 2018-01-04 11:42 GMT+01:00 João Paulo Sá da Silva <
> joao-sa-si...@alticelabs.com>:
>
>> Hello!
>>
>>
>>
>> Is it possible to use the LXD driver for nova compute instead of the KVM?
>>
>>
>>
>> Kind regards,
>>
>> João
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [containers][magnum] Magnum team at Summit?

[Mark Baker]

Hi Adrian,

I'm unlikely to attend the PTG myself but James Page and other members of
our team will be there who can help cover. Certainly we'd like to better
understand what the cluster drivers need from the underlying operating
system and what we need to do to make sure Ubuntu does all those things
really well.



Best Regards


Mark Baker

On 18 January 2017 at 19:08, Adrian Otto <adrian.o...@rackspace.com> wrote:

>
> On Jan 18, 2017, at 10:48 AM, Mark Baker <mark.ba...@canonical.com> wrote:
>
> Hi Adrian,
>
> Let me know if you have similar questions or concerns about Ubuntu Core
> with Magnum.
>
> Mark
>
>
> Thanks Mark! Is there any chance you, or an Ubuntu Core representative
> could join us for a discussion at the PTG, and/or an upcoming IRC team
> meeting? The topic of supported operating system images for our cluster
> drivers is a current topic of team conversation, and it would be helpful to
> have clarity on what (support/dev/test) resources upstream Linux packagers
> may be able to offer to help guide our conversation.
>
> To give you a sense, we do have a Suse specific k8s driver that has been
> maturing during the Ocata release cycle, our Mesos driver uses Ubuntu
> Server, our Swarm and k8s drivers use Fedora Atomic, and another newer k8s
> driver uses Fedora. The topic of Operating System (OS) support for cluster
> nodes (versus what OS containers are based on) is confusing for many cloud
> operators, so it would be helpful we worked on clarifying the options, and
> involve stakeholders from various OS distributions so that suitable options
> are available for those who prefer to form Magnum clusters from OS images
> composed from one particular OS or another.
>
> Ideally we could have this discussion at the PTG in Atlanta with
> participants like our core reviewers, Josh Berkus, you, our Suse
> contributors, and any other representatives from OS distribution
> organizations who may have an interest in cluster drivers for their
> respective OS types. If that discussion proves productive, we could also
> engage our wider contributor base in a followup IRC team meeting with a
> dedicated agenda item to cover what’s possible, and summarize what various
> stakeholders provided to us as input at the PTG. This might give us a
> chance to source further input from a wider audience than our PTG attendees.
>
> Thoughts?
>
> Thanks,
>
> Adrian
>
>
> On 18 Jan 2017 8:36 p.m., "Adrian Otto" <adrian.o...@rackspace.com> wrote:
>
>> Josh,
>>
>> > On Jan 18, 2017, at 10:18 AM, Josh Berkus <jber...@redhat.com> wrote:
>> >
>> > Magnum Devs:
>> >
>> > Is there going to be a magnum team meeting around OpenStack Summit in
>> > Boston?
>> >
>> > I'm the community manager for Atomic Host, so if you're going to have
>> > Magnum meetings, I'd like to send you some Atomic engineers to field any
>> > questions/issues at the Summit.
>>
>> Thanks for your question. We are planning to have our team design
>> meetings at the upcoming PTG event in Atlanta. We are not currently
>> planning to have any such meetings in Boston. With that said, we would very
>> much like to involve you in an important Atomic related design decision
>> that has recently surfaced, and would like to welcome you to an upcoming
>> Magnum IRC team meeting to meet you and explain our interests and concerns.
>> I do expect to attend the Boston summit myself, so I’m willing to meet you
>> and your engineers on behalf of our team if you are unable to attend the
>> PTG. I’ll reach out to you individually by email to explore our options for
>> an Atomic Host meeting agenda item in the mean time.
>>
>> Regards,
>>
>> Adrian
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [containers][magnum] Magnum team at Summit?

[Mark Baker]

Hi Adrian,

Let me know if you have similar questions or concerns about Ubuntu Core
with Magnum.

Mark

On 18 Jan 2017 8:36 p.m., "Adrian Otto"  wrote:

> Josh,
>
> > On Jan 18, 2017, at 10:18 AM, Josh Berkus  wrote:
> >
> > Magnum Devs:
> >
> > Is there going to be a magnum team meeting around OpenStack Summit in
> > Boston?
> >
> > I'm the community manager for Atomic Host, so if you're going to have
> > Magnum meetings, I'd like to send you some Atomic engineers to field any
> > questions/issues at the Summit.
>
> Thanks for your question. We are planning to have our team design meetings
> at the upcoming PTG event in Atlanta. We are not currently planning to have
> any such meetings in Boston. With that said, we would very much like to
> involve you in an important Atomic related design decision that has
> recently surfaced, and would like to welcome you to an upcoming Magnum IRC
> team meeting to meet you and explain our interests and concerns. I do
> expect to attend the Boston summit myself, so I’m willing to meet you and
> your engineers on behalf of our team if you are unable to attend the PTG.
> I’ll reach out to you individually by email to explore our options for an
> Atomic Host meeting agenda item in the mean time.
>
> Regards,
>
> Adrian
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Mark Baker]

Certainly the aim is to support upgrades between LTS releases.
Getting a meaningful keynote slot at an OpenStack summit is more of a
challenge.

On 6 Nov 2015 9:27 pm, "Jonathan Proulx" <j...@csail.mit.edu> wrote:
>
> On Fri, Nov 06, 2015 at 05:28:13PM +, Mark Baker wrote:
> :Worth mentioning that OpenStack releases that come out at the same time
as
> :Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) are
> :supported for 5 years by Canonical so are already kind of an LTS. Support
> :in this context means patches, updates and commercial support (for a
fee).
> :For paying customers 3 years of patches, updates and commercial support
for
> :April releases, (Kilo, O, Q etc..) is also available.
>
> 
> And Canonical will support a live upgarde directly from Essex to
> Icehouse and Icehouse to Mitaka?
>
> I'd love to see Shuttleworth do that that as a live keynote, but only
> on a system with at least hundres on nodes and many VMs...
> 
>
> That's where LTS falls down conceptually we're struggling to make
> single release upgrades work at this point.
>
> I do agree LTS for release would be great but honestly OpenStack isn't
> Mature enough for that yet.
>
> -Jon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Mark Baker]

Worth mentioning that OpenStack releases that come out at the same time as
Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) are
supported for 5 years by Canonical so are already kind of an LTS. Support
in this context means patches, updates and commercial support (for a fee).
For paying customers 3 years of patches, updates and commercial support for
April releases, (Kilo, O, Q etc..) is also available.



Best Regards


Mark Baker

On Fri, Nov 6, 2015 at 5:03 PM, James King <ja...@agentultra.com> wrote:

> +1 for some sort of LTS release system.
>
> Telcos and risk-averse organizations working with sensitive data might not
> be able to upgrade nearly as fast as the releases keep coming out. From the
> summit in Japan it sounds like companies running some fairly critical
> public infrastructure on Openstack aren’t going to be upgrading to Kilo any
> time soon.
>
> Public clouds might even benefit from this. I know we (Dreamcompute) are
> working towards tracking the upstream releases closer… but it’s not
> feasible for everyone.
>
> I’m not sure whether the resources exist to do this but it’d be a nice to
> have, imho.
>
> > On Nov 6, 2015, at 11:47 AM, Donald Talton <donaldtal...@fico.com>
> wrote:
> >
> > I like the idea of LTS releases.
> >
> > Speaking to my own deployments, there are many new features we are not
> interested in, and wouldn't be, until we can get organizational (cultural)
> change in place, or see stability and scalability.
> >
> > We can't rely on, or expect, that orgs will move to the CI/CD model for
> infra, when they aren't even ready to do that for their own apps. It's
> still a new "paradigm" for many of us. CI/CD requires a considerable
> engineering effort, and given that the decision to "switch" to OpenStack is
> often driven by cost-savings over enterprise virtualization, adding those
> costs back in via engineering salaries doesn't make fiscal sense.
> >
> > My big argument is that if Icehouse/Juno works and is stable, and I
> don't need newer features from subsequent releases, why would I expend the
> effort until such a time that I do want those features? Thankfully there
> are vendors that understand this. Keeping up with the release cycle just
> for the sake of keeping up with the release cycle is exhausting.
> >
> > -Original Message-
> > From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> > Sent: Thursday, November 05, 2015 11:15 PM
> > To: OpenStack Development Mailing List
> > Cc: openstack-operat...@lists.openstack.org
> > Subject: [Openstack-operators] [stable][all] Keeping Juno "alive" for
> longer.
> >
> > Hello all,
> >
> > I'll start by acknowledging that this is a big and complex issue and I
> do not claim to be across all the view points, nor do I claim to be
> particularly persuasive ;P
> >
> > Having stated that, I'd like to seek constructive feedback on the idea
> of keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.
> >
> > Acknowledging my affiliation/bias:  I work for Rackspace in the private
> cloud team.  We support a number of customers currently running Juno that
> are, for a variety of reasons, challenged by the Kilo upgrade.
> >
> > Here is a summary of the main points that have come up in my
> conversations, both for and against.
> >
> > Keep Juno:
> > * According to the current user survey[1] Icehouse still has the
> >   biggest install base in production clouds.  Juno is second, which makes
> >   sense. If we EOL Juno this month that means ~75% of production clouds
> >   will be running an EOL'd release.  Clearly many of these operators have
> >   support contracts from their vendor, so those operators won't be left
> >   completely adrift, but I believe it's the vendors that benefit from
> keeping
> >   Juno around. By working together *in the community* we'll see the best
> >   results.
> >
> > * We only recently EOL'd Icehouse[2].  Sure it was well communicated,
> but we
> >   still have a huge Icehouse/Juno install base.
> >
> > For me this is pretty compelling but for balance 
> >
> > Keep the current plan and EOL Juno Real Soon Now:
> > * There is also no ignoring the elephant in the room that with HP
> stepping
> >   back from public cloud there are questions about our CI capacity, and
> >   keeping Juno will have an impact on that critical resource