[openstack-dev] [keystone][py3] Usage of httpretty

[Chuck Short]

Hi,

I was wondering for the reason behind the usage httpretty in
python-keystoneclient. It seems to me like a total overkill for a test. It
also has some problems with python3 support that is currently blocking
python3 porting as well.

Regards
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][py3] Usage of httpretty

[Chuck Short]

Hi,

So maybe if it gets to the point where it gets too be much of a porblem we
should just put it on stackforge.

Regards
chuck


On Wed, Nov 20, 2013 at 9:08 PM, Jamie Lennox wrote:

> Chuck,
>
> So it is being used to handle stubbing returns from requests and httplib
> rather than having to having fake handlers in place in our testing code,
> or stubbing out the request library and continually having to update the
> arguments being passed to keep the mocks working. From my looking around
> it is the best library for this sort of job.
>
> When i evalutated it for keystoneclient upstream
> (https://github.com/gabrielfalcao/HTTPretty/ ) was quickly responsive
> and had CI tests that seemed to be checking python 3 support. I haven't
> seen as much happening recently as there are pull requests upstream for
> python 3 fixes that just don't seem to be moving anywhere. The CI for
> python 3 was also commented out at some point.
>
> It also turns out to be a PITA to package correctly. I attempted this
> for fedora, and i know there was someone attempting the same for gentoo.
> I have a pull request upstream that would at least get the dependencies
> under control.
>
> I do not want to go back to stubbing the request library, or having a
> fake client path that is only used in testing. However I have also
> noticed it is the cause of at least some of our python 3 problems.
>
> If there are other libraries out there that can do the same job we
> should consider them though i am holding some hope for upstream.
>
>
> Jamie
>
>
> On Wed, 2013-11-20 at 14:27 -0800, Morgan Fainberg wrote:
> > Chuck,
> >
> > The reason to use httpretty is that it handles everything at the
> > socket layer, this means if we change out urllib for requests or some
> > other transport to make HTTP requests to we don't need to refactor
> > every one of the mock/mox subouts to match the exact set of parameters
> > to be passed.  Httpretty makes managing this significantly easier
> > (hence was the reasoning to move towards it).  Though, I'm sure Jamie
> > Lennox can provide more insight into deeper specifics as he did most
> > of the work to convert it.
> >
> > At least the above is my understanding of the reasoning.
> >
> > --Morgan
> >
> > On Wed, Nov 20, 2013 at 2:08 PM, Dolph Mathews 
> wrote:
> > > I don't have a great answer -- do any projects depend on it other than
> > > python-keystoneclient? I'm happy to see it removed -- I see the
> immediate
> > > benefit but it's obviously not significant relative to python 3
> support.
> > >
> > > BTW, this exact issue is being tracked here-
> > > https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> > >
> > >
> > >
> > >
> > > On Wed, Nov 20, 2013 at 3:28 PM, Chuck Short <
> chuck.sh...@canonical.com>
> > > wrote:
> > >>
> > >> Hi,
> > >>
> > >> I was wondering for the reason behind the usage httpretty in
> > >> python-keystoneclient. It seems to me like a total overkill for a
> test. It
> > >> also has some problems with python3 support that is currently blocking
> > >> python3 porting as well.
> > >>
> > >> Regards
> > >> chuck
> > >>
> > >> ___
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev@lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > -Dolph
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

Hi

Has a decision happened when this meeting is going to take place, assuming
it is still taking place tomorrow.

Regards
chuck


On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman  wrote:

>
> On Nov 18, 2013, at 4:30 PM, Russell Bryant  wrote:
>
> On 11/18/2013 06:30 PM, Dan Smith wrote:
>
> Not having been at the summit (maybe the next one), could somebody
> give a really short explanation as to why it needs to be a separate
> service? It sounds like it should fit within the Nova area. It is,
> after all, just another hypervisor type, or so it seems.
>
>
> But it's not just another hypervisor. If all you want from your
> containers is lightweight VMs, then nova is a reasonable place to put
> that (and it's there right now). If, however, you want to expose the
> complex and flexible attributes of a container, such as being able to
> overlap filesystems, have fine-grained control over what is shared with
> the host OS, look at the processes within a container, etc, then nova
> ends up needing quite a bit of change to support that.
>
> I think the overwhelming majority of folks in the room, after discussing
> it, agreed that Nova is infrastructure and containers is more of a
> platform thing. Making it a separate service lets us define a mechanism
> to manage these that makes much more sense than treating them like VMs.
> Using Nova to deploy VMs that run this service is the right approach,
> IMHO. Clayton put it very well, I think:
>
>  If the thing you want to deploy has a kernel, then you need Nova. If
>  your thing runs on a kernel, you want $new_service_name.
>
> I agree.
>
> Note that this is just another service under the compute project (or
> program, or whatever the correct terminology is this week).
>
>
> The Compute program is correct.  That is established terminology as
> defined by the TC in the last cycle.
>
> So while
> distinct from Nova in terms of code, development should be tightly
> integrated until (and if at some point) it doesn't make sense.
>
>
> And it may share a whole bunch of the code.
>
> Another way to put this:  The API requirements people have for
> containers include a number of features considered outside of the
> current scope of Nova (short version: Nova's scope stops before going
> *inside* the servers it creates, except file injection, which we plan to
> remove anyway).  That presents a problem.  A new service is one possible
> solution.
>
> My view of the outcome of the session was not "it *will* be a new
> service".  Instead, it was, "we *think* it should be a new service, but
> let's do some more investigation to decide for sure".
>
> The action item from the session was to go off and come up with a
> proposal for what a new service would look like.  In particular, we
> needed a proposal for what the API would look like.  With that in hand,
> we need to come back and ask the question again of whether a new service
> is the right answer.
>
> I see 3 possible solutions here:
>
> 1) Expand the scope of Nova to include all of the things people want to
> be able to do with containers.
>
> This is my least favorite option.  Nova is already really big.  We've
> worked to split things out (Networking, Block Storage, Images) to keep
> it under control.  I don't think a significant increase in scope is a
> smart move for Nova's future.
>
> 2) Declare containers as explicitly out of scope and start a new project
> with its own API.
>
> That is what is being proposed here.
>
> 3) Some middle ground that is a variation of #2.  Consider Ironic.  The
> idea is that Nova's API will still be used for basic provisioning, which
> Nova will implement by talking to Ironic.  However, there are a lot of
> baremetal management things that don't fit in Nova at all, and those
> only exist in Ironic's API.
>
> I wanted to mention this option for completeness, but I don't actually
> think it's the right choice here.  With Ironic you have a physical
> resource (managed by Ironic), and then instances of an image running on
> these physical resources (managed by Nova).
>
> With containers, there's a similar line.  You have instances of
> containers (managed either by Nova or the new service) running on
> servers (managed by Nova).  I think there is a good line for separating
> concerns, with a container service on top of Nova.
>
>
> Let's ask ourselves:  How much overlap is there between the current
> compute API and a proposed containers API?  Effectively, what's the
> diff?  How much do we expect this diff to change in the coming years?
>
> The current diff demonstrates a significant clash with the current scope
> of Nova.  I also expect a lot of innovation around containers in the
> next few years, which will result in wanting to do new cool things in
> the API.  I feel that all of this justifies a new API service to best
> position ourselves for the long term.
>
>
> +1
>
> We need to come up with the API first before we decide if this is a new
> service or just something that
> needs to be added

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

On Thu, Nov 21, 2013 at 12:58 PM, Sam Alba  wrote:

> On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman  wrote:
> >
> > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba  wrote:
> >>
> >> I wish we can make a decision during this meeting. Is it confirmed for
> >> Friday 9am pacific?
> >
> >
> > Friday 9am Pacific seems to be the best time for this meeting. Can we use
> > the #openstack-meeting channel for this?
> > If not, then I can find another channel.
> >
> > For the agenda, I propose
> >  - going through https://etherpad.openstack.org/p/containers-service-apiand
> > understand capabilities of all container technologies
> >  + would like the experts on each of those technologies to fill us in
> >  - go over the API proposal and see what we need to change.
>
> I think it's too early to go through the API. Let's first go through
> all options discussed before to support containers in openstack
> compute:
> #1 Have this new compute service for containers (other than Nova)
> #2 Extend Nova virt API to support containers
> #3 Support containers API as a third API for Nova
>
> Depending how it goes, then it makes sense to do an overview of the API I
> think.
>
> What do you guys think?
>

+1 for me


>
>
> >> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short  >
> >> wrote:
> >> > Hi
> >> >
> >> > Has a decision happened when this meeting is going to take place,
> >> > assuming
> >> > it is still taking place tomorrow.
> >> >
> >> > Regards
> >> > chuck
> >> >
> >> >
> >> > On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman 
> wrote:
> >> >>
> >> >>
> >> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant 
> wrote:
> >> >>
> >> >> On 11/18/2013 06:30 PM, Dan Smith wrote:
> >> >>
> >> >> Not having been at the summit (maybe the next one), could somebody
> >> >> give a really short explanation as to why it needs to be a separate
> >> >> service? It sounds like it should fit within the Nova area. It is,
> >> >> after all, just another hypervisor type, or so it seems.
> >> >>
> >> >>
> >> >> But it's not just another hypervisor. If all you want from your
> >> >> containers is lightweight VMs, then nova is a reasonable place to put
> >> >> that (and it's there right now). If, however, you want to expose the
> >> >> complex and flexible attributes of a container, such as being able to
> >> >> overlap filesystems, have fine-grained control over what is shared
> with
> >> >> the host OS, look at the processes within a container, etc, then nova
> >> >> ends up needing quite a bit of change to support that.
> >> >>
> >> >> I think the overwhelming majority of folks in the room, after
> >> >> discussing
> >> >> it, agreed that Nova is infrastructure and containers is more of a
> >> >> platform thing. Making it a separate service lets us define a
> mechanism
> >> >> to manage these that makes much more sense than treating them like
> VMs.
> >> >> Using Nova to deploy VMs that run this service is the right approach,
> >> >> IMHO. Clayton put it very well, I think:
> >> >>
> >> >>  If the thing you want to deploy has a kernel, then you need Nova. If
> >> >>  your thing runs on a kernel, you want $new_service_name.
> >> >>
> >> >> I agree.
> >> >>
> >> >> Note that this is just another service under the compute project (or
> >> >> program, or whatever the correct terminology is this week).
> >> >>
> >> >>
> >> >> The Compute program is correct.  That is established terminology as
> >> >> defined by the TC in the last cycle.
> >> >>
> >> >> So while
> >> >> distinct from Nova in terms of code, development should be tightly
> >> >> integrated until (and if at some point) it doesn't make sense.
> >> >>
> >> >>
> >> >> And it may share a whole bunch of the code.
> >> >>
> >> >> Another way to put this:  The API requirements people have for
> >> >> containers include a number of features considered outside of the
> >> >> current scope of Nova (short version: Nova's sc

Re: [openstack-dev] RFC: Potential to increase min required libvirt version to 0.9.11 ?

[Chuck Short]

Hi,


On Fri, Nov 22, 2013 at 3:29 PM, Jeremy Stanley  wrote:

> On 2013-11-20 03:50:03 + (+), Tom Fifield wrote:
> > Just confirming that the documentation for Ubuntu sets users up
> > with the Cloud Archive. In Havana, Libvirt is 1.1.1 and qemu is
> > 1.5.0. I've added a row to the table.
>
> There's a change currently up for review to (yet once more) try
> using Ubuntu Cloud Archive for the testing we perform on Ubuntu
> Precise (which is most of the testing we do as a project at the
> moment).
>
> https://review.openstack.org/48226
>
> Unfortunately, the last time we tried we ran into a buggy version of
> libvirt there.
>
> https://launchpad.net/bugs/1228977
>
> At the moment, we're still looking for confirmation that
> nova-compute no longer locks up with the latest libvirt in UCA
> (1.1.1). I'm going to run some manual tests, but anyone who can
> pitch in and confirm this bug is completely flushed out now would be
> most appreciated. I certainly don't want to introduce yet another
> nondeterministic bug into our integrated gate tests, especially
> after everything else we've been through in that regard this week.
> --
>

This should be fixed in the cloud archive, please let me know if you still
have problems.

> Jeremy Stanley
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Keystone client support for Py3K

[Chuck Short]

Hi,

There is a gate for python-keystoneclient for py33. I have been trying to
port it over to python3 but its blocked on httpretty right now not being
pyhon3 compatible.

Regards
chuck


On Mon, Nov 25, 2013 at 3:25 PM, Flavio Percoco  wrote:

> Greetings,
>
> I noticed there's no Py3K gate for keysotneclient so, I just wanted to
> know what's the state of $subject and if there's any milestone for it.
>
> We're working on keeping Marconi's client Py3K compliant and this is,
> unfortunately, the only bit that's not supported. As for now, we
> disable keystone auth when running under Py3K.
>
> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Package from Debian for Devstack?

[Chuck Short]

On Mon, Dec 2, 2013 at 6:21 PM, Sean Dague  wrote:

> On 12/02/2013 06:15 PM, Adam Young wrote:
> > In order to provide Devstack a better certificate management example, we
> > want to make devstack capable of calling Certmaster.
> >
> > This package is in Debian, but not in Ubuntu.
> >
> > For example
> > http://packages.debian.org/experimental/certmaster
> >
> > How does one go about installing a package like this for devstack? Do we
> > need to get it into the underlying distro, or is a cross distro install
> > acceptable?
> >
> > I've tested it by hand and it install and works fine when
> > pre-installed.  Its just a distribution problem.
>
> That means it works, right now. But not being in the distro means there
> are no guaruntees of it working in the future.
>
> Honestly, at this point I'd -1 an add like this. I think pulling a
> package out of experimental is not really inspiring confidence. I'd
> suggest looking for a package available in Ubuntu natively.
>
> -Sean


Hi,

So the way that the package syncs works from Debian to Ubuntu is that a
package usually moves from Experimental->Unstable->Testing, Ubuntu usually
picks the package up in Unstable and gets placed in Universe (usually).
However that doesnt mean that the package will hit the cloud archive as
well.

Regards
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Package from Debian for Devstack?

[Chuck Short]

On Tue, Dec 3, 2013 at 3:51 PM, Adam Young  wrote:

>  On 12/02/2013 08:20 PM, Chuck Short wrote:
>
>
>
>
> On Mon, Dec 2, 2013 at 6:21 PM, Sean Dague  wrote:
>
>> On 12/02/2013 06:15 PM, Adam Young wrote:
>> > In order to provide Devstack a better certificate management example, we
>> > want to make devstack capable of calling Certmaster.
>> >
>> > This package is in Debian, but not in Ubuntu.
>> >
>> > For example
>> > http://packages.debian.org/experimental/certmaster
>> >
>> > How does one go about installing a package like this for devstack? Do we
>> > need to get it into the underlying distro, or is a cross distro install
>> > acceptable?
>> >
>> > I've tested it by hand and it install and works fine when
>> > pre-installed.  Its just a distribution problem.
>>
>>  That means it works, right now. But not being in the distro means there
>> are no guaruntees of it working in the future.
>>
>> Honestly, at this point I'd -1 an add like this. I think pulling a
>> package out of experimental is not really inspiring confidence. I'd
>> suggest looking for a package available in Ubuntu natively.
>>
>
> Yeah, wasn't suggesting we do that long term, just pointing out that it is
> a release issue, not a current code issue.
>
>
>
>> -Sean
>
>
>  Hi,
>
>  So the way that the package syncs works from Debian to Ubuntu is that a
> package usually moves from Experimental->Unstable->Testing, Ubuntu usually
> picks the package up in Unstable and gets placed in Universe (usually).
> However that doesnt mean that the package will hit the cloud archive as
> well.
>
> How does a package make these transitions?  Certmaster has been in
> Experimental since 2009.
>
>
It looks unmaintained to me, it never got out of experimental.

>
> Regards
> chuck
>
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Chuck Short]

On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov  wrote:

> On 11/19/2013 05:52 PM, Peter Feiner wrote:
> > On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short 
> wrote:
> >> Hi
> >>
> >>
> >> On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner 
> wrote:
> >>>
> >>> A substantive reason for switching from mox to mock is the derelict
> >>> state of mox releases. There hasn't been a release of mox in three
> >>> years: the latest, mox-0.5.3, was released in 2010 [1, 2]. Moreover,
> >>> in the past 3 years, substantial bugs have been fixed in upstream mox.
> >>> For example, with the year-old fix to
> >>> https://code.google.com/p/pymox/issues/detail?id=16, a very nasty bug
> >>> in nova would have been caught by an existing test [3].
> >>>
> >>> Alternatively, a copy of the upstream mox code could be added in-tree.
> >>>
> >> Please no, I think we are in an agreement with mox3 and mock.
> >
> > That's cool. As long as the mox* is phased out, the false-positive
> > test results will be fixed.
> >
> > Of course, there's _another_ alternative, which is to retrofit mox3
> > with the upstream mox fixes (e.g., the bug I cited above exists in
> > mox3). However, the delta between mox3 and upstream mox is pretty huge
> > (I just checked), so effort is probably better spent switching to
> > mock. To that end, I plan on changing the tests I cited above.
> >
>
> Resurrecting this thread because of an interesting review that came up
> yesterday [1].
>
> It seems that our lack of a firm decision on what to do with the mocking
> framework has left people confused. In hope to help - I'll give my view
> of where things are now and what we should do going forward, and
> hopefully we'll reach some consensus on this.
>
> Here's the breakdown:
>
> We should abandon mox:
> * It has not had a release in over 3 years [2] and a patch upstream for 2
> * There are bugs that are impacting the project with it (see above)
> * It will not be ported to python 3
>
> Proposed path forward options:
> 1) Port nova to mock now:
>   * Literally unmanageable - huge review overhead and regression risk
> for not so much gain (maybe) [1]
>
> 2) Opportunistically port nova (write new tests using mock, when fixing
> tests, move them to mock):
>  * Will take a really long time to move to mock, and is not really a
> solution since we are stuck with mock for an undetermined period of time
> - it's what we are doing now (kind of).
>
> 3) Same as 2) but move current codebase to mox3
>  * Buys us py3k compat, and fresher code
>  * Mox3 and mox have diverged and we would need to backport mox fixes
> onto the mox3 three and become de-facto active maintainers (as per Peter
> Feiner's last email - that may not be so easy).
>
>
So I thought we cleared this up already. We convert the current codebase
over to mox3, new tests should be done in mock. Eventually we start
converting over code to use mock.



> I think we should follow path 3) if we can, but we need to:
>
> 1) Figure out what is the deal with mox3 and decide if owning it will
> really be less trouble than porting nova. To be hones - I was unable to
> even find the code repo for it, only [3]. If anyone has more info -
> please weigh in. We'll also need volunteers
>
>
Monty and I did this last cycle, its apart of the openstack project,
although its not available in gerrit. Which should be fixed so we can start
getting bug fixes in for it.


> 2) Make better testing guidelines when using mock, and maybe add some
> testing helpers (like we do already have for mox) that will make porting
> existing tests easier. mreidem already put this on this weeks nova
> meeting agenda - so that might be a good place to discuss all the issues
> mentioned here as well.
>
> We should really take a stronger stance on this soon IMHO, as this comes
> up with literally every commit.
>

totally


>
> Cheers,
>
> Nikola
>
> [1] https://review.openstack.org/#/c/59694/
> [2] https://pypi.python.org/pypi/mox
> [3] https://pypi.python.org/pypi/mox3/0.7.0
>
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystoneclient] [Keystone] Last released version of keystoneclient does not work with python33

[Chuck Short]

On Wed, Dec 4, 2013 at 6:29 PM, Jamie Lennox  wrote:

> Adrian,
>
> The main blocker for the time being with keystoneclient and py3 is our
> use of a library called HTTPretty in our testing - on which there is a
> very recent thread. There is upstream work to make this py3 compatible
> but i'm not sure how quickly it's moving.
>
> Any code in keystoneclient itself that is not py33 compatible should be
> considered a bug - but obviously due to the missed testing we don't pick
> this up very often.
>
> There is no timeline at the moment, however anyone with py33 experience
> looking to make this happen faster could contribute to this branch on
> github: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help
> upstream. Once there is a py33 release available keystoneclient will not
> be far behind.
>
> Jamie
>
>
I have been working on getting python-keystoneclient compatible with py33,
and there has some work been done. However getting httpretty py33
compatible is just the first step , there is a whole bunch of fixes that
need to be done before the tests pass with py33. The differences for hmac
in python-keystoneclient comes to mind.

>
> On Wed, 2013-12-04 at 20:59 +, Adrian Otto wrote:
> > Dolph,
> >
> >
> > Is anyone already focusing on py33 compatibility for
> > python-keystoneclient? Has that effort been scoped? I'd like to judge
> > whether it's reasonable to expect us to patch it up to be compatible
> > in the near term, or relax our expectations. For Solum, we are trying
> > to make all our code py33 compatible from the start, so we take it
> > seriously when the py33 gate fails. Please advise.
> >
> >
> > Thanks,
> >
> >
> > Adrian
> >
> > On Dec 4, 2013, at 12:24 PM, Dolph Mathews 
> >  wrote:
> >
> > >
> > > On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov
> > >  wrote:
> > > Hi,
> > >
> > >
> > > I have failed tests in gate-solum-python33 because
> > > kesytoneclient fails to import xmlrpclib.
> > > The exact error is:
> > > "File
> > >
> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py",
> line 42, in 
> > > 2013-11-28 18:27:12.655 | import xmlrpclib
> > > 2013-11-28 18:27:12.655 | ImportError: No module named
> > > 'xmlrpclib
> > > "
> > > This issue appeared because of xmlrpclib was renamed in
> > > python33.
> > > Is there any plan to release a new version
> > > of keystoneclient with the fix for that issue? As I see it
> > > is fixed in master.
> > >
> > >
> > > If there is no new release for keystoneclient can you
> > > recommend any workaround for this issue?
> > >
> > >
> > >
> > >
> > > I'd be happy to make a release keystoneclient, but I don't believe
> > > that's the only issue with python 3 at the moment (at least on the
> > > CLI?). For example:
> > >
> > >
> > >   https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> > >
> > >
> > > In the current master, the above issue is only reproducible after
> > > syncing oslo (otherwise it fails on yet another python 3
> > > incompatibility).
> > >
> > >
> > > Thanks
> > > Georgy
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Sphinx 1.2 incompatibility (failing -docs jobs)

[Chuck Short]

On Tue, Dec 10, 2013 at 5:57 PM, James E. Blair wrote:

> Hi,
>
> Sphinx 1.2 was just released and it is incompatible with distutils in
> python 2.7.  See these links for more info:
>
>
> https://bitbucket.org/birkenfeld/sphinx/pull-request/193/builddoc-shouldnt-fail-on-unicode-paths/diff
>   http://bugs.python.org/issue19570
>
> This has caused all -docs jobs to fail.  This morning we merged a change
> to openstack/requirements to pin Sphinx to version 1.2:
>
>   https://review.openstack.org/#/c/61164/
>
> Sergey Lukjanov, Clark Boylan, and Jeremy Stanley finished up the
> automatic requirements proposal job (Thanks!), and so now updates have
> been automatically proposed to all projects that subscribe:
>
>   https://review.openstack.org/#/q/topic:openstack/requirements,n,z
>
> Once those changes merge, -docs jobs for affected projects should start
> working again.
>
> Note that requirements updates for stable branches are proceeding
> separately; you can track their progress here:
>
>
> https://review.openstack.org/#/q/I0487b4eca8f2755b882689289e3cdf429729b1fb,n,z
>
> -Jim
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Hi,

i am seeing this issue already on Icehouse builds on trusty already, We are
shipping python-sphinx 1.2~b3 and we were getting the same error. We worked
around it in our builds by using sphinx-build rather than using python
setup.py build_sphinx in our packages.

Regards
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

Hi,

I have definitely seen a drop off in the proposed Container-Service API
discussion. I think peple are still mauling over the ideas that were
presented so far. However with looking at the discussion so far, and
possibly trying to get the discussion going again, I don't think we are at
the point where a totally separate Container-Service API is needed yet.

Regards
chuck


On Thu, Dec 12, 2013 at 12:59 PM, Rick Harris wrote:

> Hi all,
>
> Was wondering if there's been any more work done on the proposed
> Container-Service (Capsule?) API?
>
> Haven't seen much on the ML on this, so just want to make sure the current
> plan is still to have a draft of the Capsule API, compare the delta to the
> existing Nova API, and determine whether a separate service still makes
> sense for the current use-cases.
>
> Thanks!
>
> Rick
>
>
> On Fri, Nov 22, 2013 at 2:35 PM, Russell Bryant wrote:
>
>> On 11/22/2013 02:29 PM, Krishna Raman wrote:
>> >
>> > On Nov 22, 2013, at 10:26 AM, Eric Windisch > > > wrote:
>> >
>> >> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman > >> > wrote:
>> >>> Reminder: We are meting in about 15 minutes on #openstack-meeting
>> >>> channel.
>> >>
>> >> I wasn't able to make it. Was meeting-bot triggered? Is there a log of
>> >> today's discussion?
>> >
>> > Yes. Logs are
>> > here:
>> http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html
>>
>> Yep, I used the 'nova' meeting topic for this one.  If the meeting turns
>> in to a regular thing, we should probably switch it to some sort of
>> sub-team type name ... like nova-containers.
>>
>> --
>> Russell Bryant
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Docker] Environment variables

[Chuck Short]

Hi Russel,

I have something that is pushing it for to stay in nova (at least the
compute drivers). I should have a gerrit branch for people to review soon.

Regards
chuck


On Mon, Dec 16, 2013 at 10:07 AM, Russell Bryant  wrote:

> On 12/16/2013 09:27 AM, Daniel Kuffner wrote:
> > Hi All,
> >
> > I have submitted a new blueprint which addresses the a common pattern
> > in the docker world. A usual pattern in the docker world is to use
> > environment variables to configure a container.
> >
> > docker run -e "SQL_URL=postgres://user:password@/db" my-app
> >
> > The nova docker driver doesn't support to set any environment
> > variables. To work around this issue I used cloud-init which works
> > fine. But this approach has of course the drawback that a) I have to
> > install the cloud init service. and b) my docker container doesn't
> > work outside of openstack.
> >
> > I propose to allow a user to set docker environment variables via nova
> > instance metadata. The metadata key should have a prefix like ENV_
> > which can be used to determine all environment variables. The prefix
> > should be removed and the remainder key and vaule will be injected.
> >
> > The metadata can unfortunately not be set in horizon but can be used
> > from the nova command line tool and from heat. Example heat:
> >
> > myapp:
> > Type: OS::Nova::Server
> > Properties:
> >   flavor: m1.small
> >   image: my-app:latest
> >   meta-data:
> > - ENV_SQL_URL: postgres://user:password@/db
> > - ENV_SOMETHING_ELSE: Value
> >
> >
> > Let me know what you think about that.
> >
> > Blueprint:
> https://blueprints.launchpad.net/nova/+spec/docker-env-via-meta-data
>
> Thanks for starting the discussion.  More people should do this for
> their blueprints.  :-)
>
> One of the things we should be striving for is to provide as consistent
> of an experience as we can across drivers.  Right now, we have the
> metadata service and config drive, and neither of those are driver
> specific.  In the case of config drive, whether it's used or not is
> exposed through the API.  As you point out, the meta-data service does
> technically work with the docker driver.
>
> I don't think we should support environment variables like this
> automatically.  Instead, I think it would be more appropriate to add an
> API extension for specifying env vars.  That way the behavior is more
> explicit and communicated through the API.  The env vars would be passed
> through all of the appropriate plumbing and down to drivers that are
> able to support it.
>
> This is all also assuming that containers support is staying in Nova and
> not a new service.  That discussion seems to have stalled.  Is anyone
> still pushing on that?  Any updates?
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] MariaDB support

[Chuck Short]

On Fri, Jan 24, 2014 at 2:05 PM, Steven Dake  wrote:

> On 01/24/2014 11:47 AM, Clint Byrum wrote:
>
>> Excerpts from Tim Bell's message of 2014-01-24 10:32:26 -0800:
>>
>>> We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to
>>> have MariaDB as the default MySQL-like DB.
>>>
>>> Can someone summarise the status of the OpenStack in terms of
>>>
>>>
>>> -What MySQL-flavor is/are currently tested in the gate ?
>>>
>>> -What is supported by the current code ?
>>>
>>> -Is there an agreed long term direction and if there are
>>> transitions, when will these occur ?
>>>
>>>  Tim it is worth noting that, for the most part, MariaDB 5.5 is going to
>> work 99.9% the same as MySQL 5.5, which is, I believe, what is tested
>> in the gate (since it is just what you get when apt-get installing
>> mysql-server on Ubuntu). I have only heard of a few optimizer quirks in
>> MariaDB that make it any different to vanilla MySQL.
>>
>> I do think that while we've been able to make some assumptions about
>> this compatibility for a while, with MariaDB becoming a proper fork and
>> not just a derivative, we will likely need to start testing both.
>>
> My understanding is later versions of MySQL change the on disk format and
> possibly some other compatibility functionality, making testing both a
> necessity since Red Hat ships Maria and Ubuntu plans to stick with MySQL.


Actually we have given the user the option to either run MySQL or Mariadb
on their server since it is both in the archive.


>
>  ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bug Triage - Woo Hoo!!

[Chuck Short]

Hi,

I would like to own ec2 as well.

thanks
chuck


On Fri, Feb 28, 2014 at 11:52 AM, Tracy Jones  wrote:

>
>
> Hi Folks -   We had our 1st Bug Scrub meeting and it was a great success.
>  We concentrated on tagging all of the untagged bugs with appropriate tags.
>  The work is not complete, so if you would like to help out - please take a
> look 
> here
>  and
> tag away.
>
>
> This table shows the official tags we are using, along with owners, count
> of un-triaged bugs, and count of triaged bugs.  Please scan this list for
> your name and do the following
>
> 1.  are you the right owner?  If not let me know
> 2.  triage your New bugs - there are instructions 
> here
> 3.  please do this at least weekly if not more.
>
>
> If you see a NO OWNER for an area you would like to own,* please let me
> know*.   I'm looking for volunteers - we only need 5 more people to cover
> everything
>
> Once we reach FF our focus moves from BP to bugs so you'll be hearing from
> me more and more until we release icehouse.  :-D
>
>
>
>Tag Owner New Not-New  wat russellb 48 617  network  arosen 16 47
> libvirt  kchamart 15 90  testing NO OWNER 10 38  compute  melwitt 7 51
> cells  comstud 5 12  ec2 NO OWNER 5 27  volumes  ndipanov 4 12  api  cyeoh
> 3 84  console NO OWNER 3 5  db  dripton 2 46  docker  ewindisch 2 16  lxc
>  zul 2 3  oslo  allison 2 7  baremetal  devananda 1 38  hyper-v
>  alexpilotti 1 17  novaclient  alaski 1 0  conductor  dansmith 0 3
> nova-manage NO OWNER 0 8  postgresql  dripton 0 0  rootwrap  ttx 0 1
> scheduler NO OWNER 0 9  unified-objects  dansmith 0 0  vmware  hartsocks 0
> 64  xenserver  johnthetubaguy 0 44   127 1239
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable] 2014.2.2 Stable freeze annoucnement

[Chuck Short]

Hi All

We will be freezing the stable juno branches next Friday Jun 30 2015. In
order to release on February 6th, 2015. I would like all interested parties
to review current changes and propose new ones as soon as possible so we
can get things ready for release.

If you have any questions please let me know.

chuck
__
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] [depfreeze][horizon] Exception for lesscpy>=0.10.1

[Chuck Short]

Hi,

Could you possibly add whats new in the changelog as well?

Thanks
chuck


On Wed, Mar 26, 2014 at 8:14 AM, Sascha Peilicke wrote:

> Hi,
>
> there's been a review up for some time [0] that wants to raise the version
> of
> lesscpy to 0.10.1. It's specific to horizon and contains some important
> fixes
> that we'll likely want to include. So I'd like to ask for an exception for
> this one.
>
> [0] https://review.openstack.org/#/c/70619/
> --
> Viele Grüße,
> Sascha Peilicke
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Containers][Nova] Containers Team Mid-Cyle Meetup to join Nova Meetup

[Chuck Short]

Hi Adrian,

The link says July 28 to July 31st, so I am assuming that you meant July
not August right?

chuck


On Fri, Jul 11, 2014 at 5:32 PM, Adrian Otto 
wrote:

> Containers Team,
>
> We have decided to hold our Mid-Cycle meetup along with the Nova Meetup in
> Beaverton, Oregon on Aug 28-31.The Nova Meetup is scheduled for Aug 28-30.
>
>
> https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-11878128803
>
> Those of us interested in Containers topic will use one of the breakout
> rooms generously offered by Intel. We will also stay on Thursday to focus
> on implementation plans and to engage with those members of the Nova Team
> who will be otherwise occupied on Aug 28-30, and will have a chance to
> focus entirely on Containers on the 31st.
>
> Please take a moment now to register using the link above, and I look
> forward to seeing you there.
>
> Thanks,
>
> Adrian Otto
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

[Chuck Short]

On Thu, Jul 17, 2014 at 8:13 AM, Mark McLoughlin  wrote:

> On Thu, 2014-07-17 at 09:58 +0100, Daniel P. Berrange wrote:
> > On Thu, Jul 17, 2014 at 08:46:12AM +1000, Michael Still wrote:
> > > Top posting to the original email because I want this to stand out...
> > >
> > > I've added this to the agenda for the nova mid cycle meetup, I think
> > > most of the contributors to this thread will be there. So, if we can
> > > nail this down here then that's great, but if we think we'd be more
> > > productive in person chatting about this then we have that option too.
> >
> > FYI, I'm afraid I won't be at the mid-cycle meetup since it clashed with
> > my being on holiday. So I'd really prefer if we keep the discussion on
> > this mailing list where everyone has a chance to participate.
>
> Same here. Pre-arranged vacation, otherwise I'd have been there.
>
> Mark.
>
>
Ill be there.


>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Preparing for 2014.1.2 -- branches freeze Aug 7

[Chuck Short]

Hi All-

We have frozen the stable/icehouse branches for intergrated projects for
release Thurs August 7th in preparation for the 2014.1.2 stable release You
can view the current queue of proposed patches on gerrit [1]. I'd like to
request all interested parties review current bugs affecting Havana and
help ensure any relevant fixes be proposed soon and merged by Thursday, or
notify the stable-maint team of anything critical that may land late.

Thanks
chuck

[1] https://review.openstack.org/#/q/status:open+branch:stable/havana,n,z
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps

[Chuck Short]

Hi,

Why not use python-dateutil?

Regards
chuck


On Wed, Oct 23, 2013 at 11:34 AM, Mark Washenberger <
mark.washenber...@markwash.net> wrote:

> Hi folks!
>
> In the images api, we depend on iso8601 to parse some dates and times.
> Recently, since version 0.1.4, python-iso8601 added support for a few more
> formats, and we finally got some other issues nailed down by 0.1.8. Maybe
> the fact that these formats weren't supported before was a bug. I don't
> really know.
>
> This puts us in an awkward place, however. With the help of our unit
> tests, we noticed that, if you switch from 0.1.8 back to 0.1.4 in your
> deployment, your image api will lose support for certain datetime formats
> like -MM-DD (where the time part is assumed to be all zeros). This
> obviously creates a (perhaps small) compatibility concern.
>
> Here are our alternatives:
>
> 1) Adopt 0.1.8 as the minimum version in openstack-requirements.
> 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and
> just fix the tests so they don't care about these extra formats)
> 3) Make Glance work with the added formats even if 0.1.4 is installed.
>
> As of yesterday we were resolved to do #3, trying to be good citizens. But
> it appears that to do so requires essentially reimplementing a large swath
> of iso8601 0.1.8 in glance itself. Gross!
>
> So, I'd like to suggest that we instead adopt option #1, or alternatively
> agree that option #2 is no big deal, we can all go back to sleep. Thoughts?
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Chuck Short]

Hi

On Tue, Nov 12, 2013 at 4:24 PM, Mark McLoughlin  wrote:

> On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:
> > Maybe we should have some 60% rule... that is: If you change more than
> > half of a test... you should *probably* rewrite the test in Mock.
>
> A rule needs a reasoning attached to it :)
>
> Why do we want people to use mock?
>
> Is it really for Python3? If so, I assume that means we've ruled out the
> python3 port of mox? (Ok by me, but would be good to hear why) And, if
> that's the case, then we should encourage whoever wants to port mox
> based tests to mock.
>
>
The upstream maintainer is not going to port mox to python3 so we have a
fork of mox called mox3. Ideally, we would drop the usage of mox in favour
of mock so we don't have to carry a forked mox.


> Or maybe it has nothing to do with Python3 at all? Maybe we just like
> mock more? But do we like it enough to have a mixture of mock and mox
> across the codebase?
>
> Mark.
>
> > - Original Message -
> > > From: "John Garbutt" 
> > > To: "Mark McLoughlin" , "OpenStack Development
> Mailing List (not for usage questions)"
> > > 
> > > Sent: Tuesday, November 12, 2013 9:31:25 AM
> > > Subject: Re: [openstack-dev] [nova] Do we have some guidelines for
> mock, stub, mox when writing unit test?
> > >
> > > On 11 November 2013 23:18, Mark McLoughlin  wrote:
> > > > On Mon, 2013-11-11 at 12:07 +, John Garbutt wrote:
> > > >> On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)
> > > >>  wrote:
> > > >> > Hi
> > > >> >
> > > >> >>Generally mock is supposed to be used over mox now for python 3
> support.
> > > >> >
> > > >> > That is my understanding too
> > > >>
> > > >> +1
> > > >>
> > > >> But I don't think we should waste all our time re-writing all our
> mox
> > > >> and stub tests. Lets just leave this to happen organically for now
> as
> > > >> we add and refactor tests. We probably need to take the hit at some
> > > >> point, but that doesn't feel like we should do that right now.
> > > >
> > > > Hmm, I don't follow this stance.
> > > >
> > > > Adding Python3 support is a goal we all share.
> > > >
> > > > If we're saying that the use of mox stands in the way of that goal,
> but
> > > > that we'd really prefer if people didn't work on porting tests from
> mox
> > > > to mock yet ... then are we saying we don't value people working on
> > > > porting to Python3?
> > > >
> > > > And if we plan to use a Python3 compatible version of mox[1], then
> isn't
> > > > the Python3 argument irrelevant and saying "use mock for new tests"
> just
> > > > means we'll end up with a mixture of mox and mock?
> > >
> > > Good point, I forgot about the port of mox to python3.
> > >
> > > I liked the idea of "prefer mock", with a view that at some point in
> > > the future there is only a small amount of mox related code left, that
> > > can easily get moved to mock.
> > >
> > > I guess its a trade off between review capacity, risk of breaking
> > > existing tests, and risk of never reaching that end goal.
> > >
> > > We already have stubs and mox, which do tend to fight each other,
> > > adding a third does seem like a bad plan, unless there is a very good
> > > reason, which I always had in my head as python3 support. Hmm... I do
> > > prefer mock to mox, but not that strongly.
> > >
> > > John
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Chuck Short]

http://lists.openstack.org/pipermail/openstack-dev/2013-July/012474.html


On Tue, Nov 12, 2013 at 4:27 PM, Shawn Hartsock wrote:

> Good point.
>
> I assume someone made a comparison similar to this:
> * http://garybernhardt.github.io/python-mock-comparison/
>
> ... and evangelized a choice. I had assumed that Mock vs mox was not
> merely based on Python3 support but had something to do with Mock versus
> Mox. Does anyone have that context in their head? Would they mind sharing
> it?
>
> # Shawn Hartsock
>
>
> - Original Message -
> > From: "Mark McLoughlin" 
> > To: "Shawn Hartsock" 
> > Cc: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Tuesday, November 12, 2013 4:24:08 PM
> > Subject: Re: [openstack-dev] [nova] Do we have some guidelines for mock,
> stub, mox when writing unit test?
> >
> > On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:
> > > Maybe we should have some 60% rule... that is: If you change more than
> > > half of a test... you should *probably* rewrite the test in Mock.
> >
> > A rule needs a reasoning attached to it :)
> >
> > Why do we want people to use mock?
> >
> > Is it really for Python3? If so, I assume that means we've ruled out the
> > python3 port of mox? (Ok by me, but would be good to hear why) And, if
> > that's the case, then we should encourage whoever wants to port mox
> > based tests to mock.
> >
> > Or maybe it has nothing to do with Python3 at all? Maybe we just like
> > mock more? But do we like it enough to have a mixture of mock and mox
> > across the codebase?
> >
> > Mark.
> >
> > > - Original Message -
> > > > From: "John Garbutt" 
> > > > To: "Mark McLoughlin" , "OpenStack Development
> Mailing
> > > > List (not for usage questions)"
> > > > 
> > > > Sent: Tuesday, November 12, 2013 9:31:25 AM
> > > > Subject: Re: [openstack-dev] [nova] Do we have some guidelines for
> mock,
> > > > stub, mox when writing unit test?
> > > >
> > > > On 11 November 2013 23:18, Mark McLoughlin 
> wrote:
> > > > > On Mon, 2013-11-11 at 12:07 +, John Garbutt wrote:
> > > > >> On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)
> > > > >>  wrote:
> > > > >> > Hi
> > > > >> >
> > > > >> >>Generally mock is supposed to be used over mox now for python 3
> > > > >> >>support.
> > > > >> >
> > > > >> > That is my understanding too
> > > > >>
> > > > >> +1
> > > > >>
> > > > >> But I don't think we should waste all our time re-writing all our
> mox
> > > > >> and stub tests. Lets just leave this to happen organically for
> now as
> > > > >> we add and refactor tests. We probably need to take the hit at
> some
> > > > >> point, but that doesn't feel like we should do that right now.
> > > > >
> > > > > Hmm, I don't follow this stance.
> > > > >
> > > > > Adding Python3 support is a goal we all share.
> > > > >
> > > > > If we're saying that the use of mox stands in the way of that
> goal, but
> > > > > that we'd really prefer if people didn't work on porting tests
> from mox
> > > > > to mock yet ... then are we saying we don't value people working on
> > > > > porting to Python3?
> > > > >
> > > > > And if we plan to use a Python3 compatible version of mox[1], then
> > > > > isn't
> > > > > the Python3 argument irrelevant and saying "use mock for new tests"
> > > > > just
> > > > > means we'll end up with a mixture of mox and mock?
> > > >
> > > > Good point, I forgot about the port of mox to python3.
> > > >
> > > > I liked the idea of "prefer mock", with a view that at some point in
> > > > the future there is only a small amount of mox related code left,
> that
> > > > can easily get moved to mock.
> > > >
> > > > I guess its a trade off between review capacity, risk of breaking
> > > > existing tests, and risk of never reaching that end goal.
> > > >
> > > > We already have stubs and mox, which do tend to fight each other,
> > > > adding a third does seem like a bad plan, unless there is a very good
> > > > reason, which I always had in my head as python3 support. Hmm... I do
> > > > prefer mock to mox, but not that strongly.
> > > >
> > > > John
> > > >
> > > > ___
> > > > OpenStack-dev mailing list
> > > > OpenStack-dev@lists.openstack.org
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Chuck Short]

On Tue, Nov 12, 2013 at 4:49 PM, Mark McLoughlin  wrote:

> On Tue, 2013-11-12 at 16:42 -0500, Chuck Short wrote:
> >
> > Hi
> >
> >
> > On Tue, Nov 12, 2013 at 4:24 PM, Mark McLoughlin 
> > wrote:
> > On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:
> > > Maybe we should have some 60% rule... that is: If you change
> > more than
> > > half of a test... you should *probably* rewrite the test in
> > Mock.
> >
> >
> > A rule needs a reasoning attached to it :)
> >
> > Why do we want people to use mock?
> >
> > Is it really for Python3? If so, I assume that means we've
> > ruled out the
> > python3 port of mox? (Ok by me, but would be good to hear why)
> > And, if
> > that's the case, then we should encourage whoever wants to
> > port mox
> > based tests to mock.
> >
> >
> >
> > The upstream maintainer is not going to port mox to python3 so we have
> > a fork of mox called mox3. Ideally, we would drop the usage of mox in
> > favour of mock so we don't have to carry a forked mox.
>
> Isn't that the opposite conclusion you came to here:
>
> http://lists.openstack.org/pipermail/openstack-dev/2013-July/012474.html
>
> i.e. using mox3 results in less code churn?
>
> Mark.
>
>
>
Yes that was my original position but I though we agreed in thread (further
on) that we would use mox3 and then migrate to mock further on.

Regards
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Introducing the new OpenStack service for Containers

[Chuck Short]

Hi

I am excited to see containers getting such traction in the openstack
project.


On Mon, Nov 18, 2013 at 7:30 PM, Russell Bryant  wrote:

> On 11/18/2013 06:30 PM, Dan Smith wrote:
> >> Not having been at the summit (maybe the next one), could somebody
> >> give a really short explanation as to why it needs to be a separate
> >> service? It sounds like it should fit within the Nova area. It is,
> >> after all, just another hypervisor type, or so it seems.
> >
> > But it's not just another hypervisor. If all you want from your
> > containers is lightweight VMs, then nova is a reasonable place to put
> > that (and it's there right now). If, however, you want to expose the
> > complex and flexible attributes of a container, such as being able to
> > overlap filesystems, have fine-grained control over what is shared with
> > the host OS, look at the processes within a container, etc, then nova
> > ends up needing quite a bit of change to support that.
> >
> > I think the overwhelming majority of folks in the room, after discussing
> > it, agreed that Nova is infrastructure and containers is more of a
> > platform thing. Making it a separate service lets us define a mechanism
> > to manage these that makes much more sense than treating them like VMs.
> > Using Nova to deploy VMs that run this service is the right approach,
> > IMHO. Clayton put it very well, I think:
> >
> >   If the thing you want to deploy has a kernel, then you need Nova. If
> >   your thing runs on a kernel, you want $new_service_name.
> >
> > I agree.
> >
> > Note that this is just another service under the compute project (or
> > program, or whatever the correct terminology is this week).
>
> The Compute program is correct.  That is established terminology as
> defined by the TC in the last cycle.
>
> > So while
> > distinct from Nova in terms of code, development should be tightly
> > integrated until (and if at some point) it doesn't make sense.
>
> And it may share a whole bunch of the code.
>
> Another way to put this:  The API requirements people have for
> containers include a number of features considered outside of the
> current scope of Nova (short version: Nova's scope stops before going
> *inside* the servers it creates, except file injection, which we plan to
> remove anyway).  That presents a problem.  A new service is one possible
> solution.
>
> My view of the outcome of the session was not "it *will* be a new
> service".  Instead, it was, "we *think* it should be a new service, but
> let's do some more investigation to decide for sure".
>
> The action item from the session was to go off and come up with a
> proposal for what a new service would look like.  In particular, we
> needed a proposal for what the API would look like.  With that in hand,
> we need to come back and ask the question again of whether a new service
> is the right answer.
>
> I see 3 possible solutions here:
>
> 1) Expand the scope of Nova to include all of the things people want to
> be able to do with containers.
>
> This is my least favorite option.  Nova is already really big.  We've
> worked to split things out (Networking, Block Storage, Images) to keep
> it under control.  I don't think a significant increase in scope is a
> smart move for Nova's future.
>
>
This is my least favorite option. Like a lot of other responses already I
see a lot of code duplication  because Nova and the new nova container's
project. This just doesn't include the scheduler but  things like config
driver, etc.


> 2) Declare containers as explicitly out of scope and start a new project
> with its own API.
>
> That is what is being proposed here.
>
> 3) Some middle ground that is a variation of #2.  Consider Ironic.  The
> idea is that Nova's API will still be used for basic provisioning, which
> Nova will implement by talking to Ironic.  However, there are a lot of
> baremetal management things that don't fit in Nova at all, and those
> only exist in Ironic's API.
>

This is my preferred choice  as well. If we could leverage the existing
nova API and extend it to include containers and features that users who
use containers in their existing production environment wants.

>
> I wanted to mention this option for completeness, but I don't actually
> think it's the right choice here.  With Ironic you have a physical
> resource (managed by Ironic), and then instances of an image running on
> these physical resources (managed by Nova).
>
> With containers, there's a similar line.  You have instances of
> containers (managed either by Nova or the new service) running on
> servers (managed by Nova).  I think there is a good line for separating
> concerns, with a container service on top of Nova.
>
>
> Let's ask ourselves:  How much overlap is there between the current
> compute API and a proposed containers API?  Effectively, what's the
> diff?  How much do we expect this diff to change in the coming years?
>
> The current diff demonstrates a significant clash with the cu

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Chuck Short]

Hi


On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner  wrote:

> A substantive reason for switching from mox to mock is the derelict
> state of mox releases. There hasn't been a release of mox in three
> years: the latest, mox-0.5.3, was released in 2010 [1, 2]. Moreover,
> in the past 3 years, substantial bugs have been fixed in upstream mox.
> For example, with the year-old fix to
> https://code.google.com/p/pymox/issues/detail?id=16, a very nasty bug
> in nova would have been caught by an existing test [3].
>
> Alternatively, a copy of the upstream mox code could be added in-tree.
>
> Please no, I think we are in an agreement with mox3 and mock.



> [1] mox releases: https://code.google.com/p/pymox/downloads/list
> [2] mox on pypi: https://pypi.python.org/pypi/mox
> [3] see comments 5 and 6 in https://bugs.launchpad.net/nova/+bug/1251792
>
> On Wed, Nov 13, 2013 at 2:24 PM, Matt Riedemann
>  wrote:
> >
> >
> > On 11/12/2013 5:04 PM, Chuck Short wrote:
> >>
> >>
> >>
> >>
> >> On Tue, Nov 12, 2013 at 4:49 PM, Mark McLoughlin  >> <mailto:mar...@redhat.com>> wrote:
> >>
> >> On Tue, 2013-11-12 at 16:42 -0500, Chuck Short wrote:
> >>  >
> >>  > Hi
> >>  >
> >>  >
> >>  > On Tue, Nov 12, 2013 at 4:24 PM, Mark McLoughlin
> >> mailto:mar...@redhat.com>>
> >>
> >>  > wrote:
> >>  > On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:
> >>  > > Maybe we should have some 60% rule... that is: If you
> >> change
> >>  > more than
> >>  > > half of a test... you should *probably* rewrite the
> test
> >> in
> >>  > Mock.
> >>  >
> >>  >
> >>  > A rule needs a reasoning attached to it :)
> >>  >
> >>  > Why do we want people to use mock?
> >>  >
> >>  > Is it really for Python3? If so, I assume that means
> we've
> >>  > ruled out the
> >>  > python3 port of mox? (Ok by me, but would be good to hear
> >> why)
> >>  > And, if
> >>  > that's the case, then we should encourage whoever wants
> to
> >>  > port mox
> >>  > based tests to mock.
> >>  >
> >>  >
> >>  >
> >>  > The upstream maintainer is not going to port mox to python3 so we
> >> have
> >>  > a fork of mox called mox3. Ideally, we would drop the usage of
> mox
> >> in
> >>  > favour of mock so we don't have to carry a forked mox.
> >>
> >> Isn't that the opposite conclusion you came to here:
> >>
> >>
> >>
> http://lists.openstack.org/pipermail/openstack-dev/2013-July/012474.html
> >>
> >> i.e. using mox3 results in less code churn?
> >>
> >> Mark.
> >>
> >>
> >>
> >> Yes that was my original position but I though we agreed in thread
> >> (further on) that we would use mox3 and then migrate to mock further on.
> >>
> >> Regards
> >> chuck
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > So it sounds like we're good with using mox for new tests again? Given
> Chuck
> > got it into global-requirements here:
> >
> >
> https://github.com/openstack/requirements/commit/998dda263d7c7881070e3f16e4523ddcd23fc36d
> >
> > We can stave off the need to transition everything from mox to mock?
> >
> > I can't seem to find the nova blueprint to convert everything from mox to
> > mock, maybe it was obsoleted already.
> >
> > Anyway, if mox(3) is OK and we don't need to use mock, it seems like we
> > could add something to the developer guide here because I think this
> > question comes up frequently:
> >
> > http://docs.openstack.org/developer/nova/devref/unit_tests.html
> >
> > Does anyone disagree?
> >
> > BTW, I care about this because I've been keeping in mind the mox/mock
> > transition when doing code reviews and giving a -1 when new tests are
> using
> > mox (since I thought that was a no-no now).
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] AMQP Version upgrade plans?

[Chuck Short]

Hi

On Mon, Jul 08, 2013 at 03:11:02PM +, Mac Innes, Kiall wrote:
> If you have a recent version of kombu, and amqp[1] rather than amqplib 
> installed, things will just start using AMQP 0.9.1.
> 
> Ubuntu doesn't package a new enough Kombu, and they don't package "amqp" 
> at all.. Not sure about other distro's.
> 

Actually saucy has the latest and greatest and it will be backported
to the cloud archive when havana-2 is out.

https://launchpad.net/ubuntu/+source/kombu

> Thanks,
> Kiall
> 
> [1]: https://pypi.python.org/pypi/amqp
> 
> 
> On 24/06/13 19:12, Sunjeet Singh wrote:
> >
> >
> > OpenStack currently uses AMQP 0.8. Are there any plans to upgrade?
> >
> >
> > Thank you,
> > Sunjeet
> >
> >
> >
> >
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Quantum to Neutron migration guide

[Chuck Short]

Hi,

I was wondering if there is a Quantum to Neutron migration guide that we
can provide our users.

Thanks
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Usage of mox through out the Openstack project.

[Chuck Short]

Hi,


The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test
suites in the Openstack project is quite extensive. This is probably due to
the fact that it is the most familiar mocking object framework for most
python developers.

However there is big drawback with using mox across all of the OpenStack
projects is that it is not python3 compatible. This makes python3
compliance problematic because we want the test suites to be compatible as
well.

While thinking about this problem for a while now, while helping porting
OpenStack over to python3 there is a couple of options that as a project
can do as a whole:

1. Change mox usage to more python3 friendly such as mock. (
https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of
code churn in the projects as we move away from mox to mock.

2. Use the python3 fork called pymox (https://github.com/emonty/pymox).
This project has reasonable compatibility with mox and is python3
compatible. Using this option causes less code churn. IMHO this would be
the better option.

I would like to hear peoples opinion on this.

Thanks
chuck
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] oslo.version and pbr

[Chuck Short]

Hi


On Sun, Aug 4, 2013 at 2:24 PM, Dean Troyer  wrote:

> On Sunday, August 4, 2013, Monty Taylor wrote:
>>
>> - make an oslo.version library based on the current code in pbr
>
>
> +1
>
>
>> - bring the nova version code over, and keep its depend on oslo.config
>>
>
> +1 (code reuse), -1 (depend on oslo.config)
>
>
>> That way, pbr can go back to being a build-time need - and the people
>> who want the runtime version discovery code probably won't mind also
>> consuming oslo.config.
>>
>
> IIRC none of the CLIs currently use oslo.config, I'd prefer to keep it
> that way.  It looks like the only thing in any of the lib repos that uses
> it is keystone's auth_token.  I wish there was a way to exclude that for
> end-users installing just the CLIs from pypi.  Packaged installs should/do
> properly separate that.
>
>

Actually python-keystoneclient depends on oslo.config.


> Also, now that pbr doesn't need setuptools-git or d2to1 any more, I
>> think as soon as the version code is split into oslo.version, I'd like
>> to release a 1.0 of pbr and call it both done and API stable.
>
>
> +1
>
> dt
>
> --
> Dean Troyer
> dtro...@gmail.com
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova-lxd]Nova-lxd with Linuxbridge

[Chuck Short]

Hi,

Currently it only works with OVS mode, there is a patch lying around for
Linuxbridge agent support that needs to be integrated.

Thanks
chuck

On Fri, May 20, 2016 at 8:47 AM, Gyorgy Szombathelyi <
gyorgy.szombathe...@doclerholding.com> wrote:

> Hi!
>
> I just have a simple question: is nova-lxd supposed to work with the
> Linuxbridge agent?
> As I see, the LXD driver creates veth interface pairs, and vif.py connects
> it to a normal linux bridge. However the Linuxbridge agent code scans only
> for tap devices.
> So the question is: Should the LXD driver create a tap device, bridged
> with that veth?
>
> Br,
> György
>
> __
> 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-dev] [all][stable][release] 2015.1.2

[Chuck Short]

Hi,

We would like to do a stable/kilo branch release, next Thursday. In order
to do that I would like to freeze the branches on Friday. Cut some test
tarballs on Tuesday and release on Thursday. Does anyone have an opinnon on
this?

Thanks
chuck
__
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] [all][stable][release] 2015.1.2

[Chuck Short]

Hi,

I would like to freeze the branches on Wednesday and get a release out
early next week. Are we okay with that?

Thanks
chuck

On Wed, Sep 23, 2015 at 8:47 PM, Chuck Short 
wrote:

> Hi,
>
> We would like to do a stable/kilo branch release, next Thursday. In order
> to do that I would like to freeze the branches on Friday. Cut some test
> tarballs on Tuesday and release on Thursday. Does anyone have an opinnon on
> this?
>
> Thanks
> chuck
>
__
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-dev] [all][stable][release] 2015.1.2

[Chuck Short]

Hi,
stable/kilo is now frozen. I expect to do a release on Tuesday. If you need
to include something please let me know.

Thanks
chuck
__
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] [all][stable][release] 2015.1.2

[Chuck Short]

Hi

Im just in the last stages of release 2015.1.2. I dont think anything is
stopping us from opening it up agian. The tabrlls have been created. So go
for it.

Chuck

On Tue, Oct 13, 2015 at 2:46 PM, Matt Riedemann 
wrote:

>
>
> On 10/7/2015 7:42 PM, Chuck Short wrote:
>
>> Hi,
>> stable/kilo is now frozen. I expect to do a release on Tuesday. If you
>> need to include something please let me know.
>>
>> Thanks
>> chuck
>>
>>
>> __
>> 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
>>
>>
> Looks like the 2015.1.2 tag is up and now we need to bump the version to
> 2015.1.3 in setup.cfg for the projects, I don't see a series up for that
> yet but it's blocking anything from passing tests on stable/kilo now.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
>
> 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] [all][stable][release] 2015.1.2

[Chuck Short]

On Wed, Oct 14, 2015 at 5:01 AM, Thierry Carrez 
wrote:

> Ihar Hrachyshka wrote:
> > Chuck, have you forgotten about three more repositories for neutron-*aas?
>

My apologies they are available now.

>
> Yeah, if those have fixes they should have been tagged as well.
>
> Also we'll want a change to openstack/releases to include 2015.1.2 in
> release history.
>
> --
> Thierry Carrez (ttx)
>
>
> __
> 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] [puppet] Ubuntu problems + Help needed

[Chuck Short]

Hi Mohammed,

I might be able to help where can I find this info?

Thanks
chuck

On Wed, Dec 20, 2017 at 12:03 PM, Mohammed Naser 
wrote:

> Hi everyone,
>
> I'll get right into the point.
>
> At the moment, the Puppet OpenStack modules don't have much
> contributors which can help maintain the Ubuntu support.  We deploy on
> CentOS (so we try to get all the fixes in that we can) and there is a
> lot of activity from the TripleO team as well which does their
> deployments on CentOS which means that the CentOS support is very
> reliable and CI is always sought after.
>
> However, starting a while back, we started seeing occasional failures
> with Ubuntu deploys which lead us set the job to non-voting.  At the
> moment, the Puppet integration jobs for Ubuntu are always failing
> because of some Tempest issue.  This means that with every Puppet
> change, we're wasting ~80 minutes of CI run time for a job that will
> always fail.
>
> We've had a lot of support from the packaging team at RDO (which are
> used in Puppet deployments) and they run our integration before
> promoting packages which makes it helpful in finding issues together.
> However, we do not have that with Ubuntu neither has there been anyone
> who is taking initiative to look and investigate those issues.
>
> I understand that there are users out there who use Ubuntu with Puppet
> OpenStack modules.  We need your help to come and try and clear those
> issues out. We'd be more than happy to give assistance to lead you in
> the right way to help fix those issues.
>
> Unfortunately, if we don't have any folks stepping up to resolving
> this, we'll be forced to drop all CI for Ubuntu and make a note to
> users that Ubuntu is not fully tested and hope that as users run into
> issues, they can contribute fixes back (or that someone can work on
> getting Ubuntu gating working again).
>
> Thanks for reading through this, I am quite sad that we'd have to drop
> support for such a major operating system, but there's only so much we
> can do with a much smaller team.
>
> Thank you,
> Mohammed
>
> __
> 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] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Chuck Short]

+1

Regards
chuck

On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang 
wrote:

> There are two projects to solve the issue that run OpenStack on
> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> leverage helm tool for orchestration. There is some different perspective
> at the beginning, which results in the two teams could not work together.
>
> But recently, the difference becomes too small. and there is also no active
> contributor in the kolla-kubernetes project.
>
> So I propose to retire kolla-kubernetes project. If you are still
> interested in running OpenStack on kubernetes, please refer to
> openstack-helm project.
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [horizon] Scheduling switch to django >= 2.0

[Chuck Short]

Hi

On Sat, Jun 2, 2018 at 9:50 PM, Akihiro Motoki  wrote:

> Updates on Django 2.0 support.
>
> * 18 of 29 affected repositories now support Django 2.0
> * 4 repositories have pending patches.
> * 3 repositories below need help from individual project teams as I don't
> have actual running environments of them.
>* heat-dashboard https://review.openstack.org/#/c/567591/
>* murano-dashboard https://review.openstack.org/#/c/571950/
>* watcher-dashboard
> * 4 repositories below needs more help as there seems no python3 support
> or projects looks inactive.
>monasca-ui, cloudkitty-dashboard, karbor-dashboard,
> group-based-policy-ui
>
>
Monasca-ui has python3 support however the CI hasn't been enabled.


> global-requirements and upper-constraints changes are also proposed.
> Considering good progress in general, I believe we can land requirements
> changes soon.
> https://review.openstack.org/#/q/topic:django-version+(
> status:open+OR+status:merged)
>
> Detail progress is found at https://etherpad.openstack.
> org/p/django20-support
>
> Thanks,
> Akihiro
>
> 2018年5月15日(火) 4:21 Ivan Kolodyazhny :
>
>> Hi all,
>>
>> From the Horizon's perspective, it would be good to support Django 1.11
>> as long as we can since it's an LTS release [2].
>> Django 2.0 support is also extremely important because of it's the first
>> step in a python3-only environment and step forward on supporting
>> next Django 2.2 LTS release which will be released next April.
>>
>> We have to be careful to not break existing plugins and deployments by
>> introducing new Django version requirement.
>> We need to work more closely with plugins teams to getting everything
>> ready for Django 2.0+ before we change our requirements.txt.
>> I don't want to introduce any breaking changes for current plugins so we
>> need to to be sure that each plugin supports Django 2.0. It means
>> plugins have to have voting Django 2.0 jobs on their gates at least. I'll
>> do my best on this effort and will work with plugins teams to do as
>> much as we can in Rocky timeframe.
>>
>> [2] https://www.djangoproject.com/download/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki 
>> wrote:
>>
>>>
>>>
>>> 2018年5月14日(月) 21:42 Doug Hellmann :
>>>
 Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900:
 > 2018年5月12日(土) 3:04 Doug Hellmann :
 >
 > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900:
 > > > Hi zigo and horizon plugin maintainers,
 > > >
 > > > Horizon itself already supports Django 2.0 and horizon unit test
 covers
 > > > Django 2.0 with Python 3.5.
 > > >
 > > > A question to all is whether we change the upper bound of Django
 from
 > > <2.0
 > > > to <2.1.
 > > > My proposal is to bump the upper bound of Django to <2.1 in
 Rocky-2.
 > > > (Note that Django 1.11 will continue to be used for python 2.7
 > > environment.)
 > >
 > > Do we need to cap it at all? We've been trying to express our
 > > dependencies without caps and rely on the constraints list to
 > > test using a common version because this offers the most
 flexibility as
 > > we move to newer versions over time.
 > >
 >
 > The main reason we cap django version so far is that django minor
 version
 > releases
 > contain some backward incompatible changes and also drop deprecated
 > features.
 > A new django minor version release like 1.11 usually breaks horizon
 and
 > plugins
 > as horizon developers are not always checking django deprecations.

 OK. Having the cap in place makes it more complicated to test
 upgrading, and then upgrade. Because we no longer synchronize
 requirements, changing openstack/requirements does not trigger the
 bot to propose the same change to all of the projects using the
 dependency. Someone will have to do that by hand in the future, as we
 are doing with eventlet right now
 (https://review.openstack.org/#/q/topic:uncap-eventlet).

 Without the cap, we can test the upgrade by proposing a constraint
 update and running the horizon (and/or plugin) unit tests. When those
 tests pass, we can then step forward all at once by approving the
 constraint change.

>>>
>>> Thanks for the detail context.
>>>
>>> Honestly I am not sure which is better to cap or uncap the django
>>> version.
>>> We can try uncapping now and see what happens in the community.
>>>
>>> cross-horizon-(py27|py35) jobs of openstack/requirements checks
>>> if horizon works with a new version. it works for horizon, but perhaps
>>> it potentially
>>> break horizon plugins as it takes time to catch up with such changes.
>>> On the other hand, a version bump in upper-constraints.txt would be
>>> a good trigger for horizon plugin maintainers to sync all requirements.
>>>
>>> In addition, requirements a

[openstack-dev] [keystone] webob 1.7

[Chuck Short]

Hi

We have been expericing problems with newer versions of webob (webob 1.7).
Reading the changelog, it seems that the upstream developers have
introduced some backwards incompatibility with previous versions of webob
that seems to be hitting keystone and possibly other projects as well
(nova/glance in particular). For keystone this bug has been reported in bug
#1657452. I would just like to get more developer's eyes on this particular
issue and possibly get a fix. I suspect its starting to hit other distros
as well or already have hit.

Thanks
chuck
__
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] [keystone] webob 1.7

[Chuck Short]

Hi Ian,

I just read the bug report and I don't think the correct fix for this issue
is to blacklist webob 1.7.0.
The reason for this is that multiple distros are already using webob 1.7.
Also projects like keystonemiddleware have made backwards compatible changes
to accomodate newer versions of webob.

Regards
chuck

On Wed, Jan 18, 2017 at 9:08 AM, Ian Cordasco 
wrote:

> -Original Message-
> From: Chuck Short 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: January 18, 2017 at 08:01:46
> To: OpenStack Development Mailing List 
> Subject:  [openstack-dev] [keystone] webob 1.7
>
> > Hi
> >
> > We have been expericing problems with newer versions of webob (webob
> 1.7).
> > Reading the changelog, it seems that the upstream developers have
> > introduced some backwards incompatibility with previous versions of webob
> > that seems to be hitting keystone and possibly other projects as well
> > (nova/glance in particular). For keystone this bug has been reported in
> bug
> > #1657452. I would just like to get more developer's eyes on this
> particular
> > issue and possibly get a fix. I suspect its starting to hit other distros
> > as well or already have hit.
>
> Hey Chuck,
>
> This is also affecting Glance
> (https://bugs.launchpad.net/glance/+bug/1657459). I suspect what we'll
> do for now is blacklist the 1.7.x releases in openstack/requirements.
> It seems a bit late in the cycle to bump the minimum version to 1.7.0
> so we can safely fix this without having to deal with
> incompatibilities between versions.
>
> --
> Ian Cordasco
>
> __
> 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-dev] [monasca] License for monasca-statsd

[Chuck Short]

Hi,

I was looking at packaging monasca-statsd since it is a dependency for
designate, however when I look at the license for it,it says Apache-2.
However the LICENSE file included in the source  is that the software is
provided as is...etc etc. Could we get some clarification please?

Thanks
chuck
__
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] [monasca] License for monasca-statsd

[Chuck Short]

On Thu, Nov 3, 2016 at 3:55 PM, Jeremy Stanley  wrote:

> On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> > I was looking at packaging monasca-statsd since it is a dependency for
> > designate, however when I look at the license for it,it says Apache-2.
> > However the LICENSE file included in the source  is that the software is
> > provided as is...etc etc. Could we get some clarification please?
>
> It looks like https://review.openstack.org/123315 added that
> LICENSE file when originally setting up the monasca-statsd repo a
> couple years ago. I see a variety of Datadog repositories in
> circulation using that license, and they seem to refer to it as "a
> simplified BSD license" (which is certainly what it looks like to me
> as well). However, all the individual files added in that change
> which declare a license in their headers seem to use Apache License
> 2.0, which I agree is confusing. Hopefully the Datadog license was
> added here in error, and we've not actually been shipping an
> incorrectly-licensed derivative of their software this entire time?
> --
> Jeremy Stanley
>
> __
> 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
>
>

Hi,

I have checked the version on pypi and tarballs.openstack.org and all the
versions from monasca-statsd from 1.0.0 onwards provide the incorrect
LICENSE file.

chuck
__
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