Re: [openstack-dev] [Solum] Working group on language packs

[Clint Byrum]

Excerpts from Clayton Coleman's message of 2013-11-22 21:43:40 -0800:
> 
> > On Nov 22, 2013, at 9:54 PM, Monty Taylor  wrote:
> > 
> > 
> > 
> >> On 11/22/2013 11:34 AM, Clayton Coleman wrote:
> >> I have updated the language pack (name subject to change) blueprint
> >> with the outcomes from the face2face meetings, and drafted a
> >> specification that captures the discussion so far.  The spec is
> >> centered around the core idea of transitioning base images into
> >> deployable images (that can be stored in Nova and sent to Glance).
> >> These are *DRAFT* and are intended for public debate.
> >> 
> >> https://blueprints.launchpad.net/solum/+spec/lang-pack 
> >> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
> >> 
> >> Please take this opportunity to review these documents and offer
> >> criticism and critique via the ML - I will schedule a follow up deep
> >> dive for those who expressed interest in participation [1] after US
> >> Thanksgiving.
> > 
> > Hi!
> > 
> > I'd strongly suggest looking at the diskimage-builder project that's
> > part of the TripleO program. Someone has already done a POC of turning
> > it in to an aaS, and there are already people working on tying
> > diskimage-builder elements and heat templates. Given that OpenStack has
> > prior art and work in this direction, you should be able to accelerate
> > getting to your goals pretty quickly.
> 
> diskimage-builder is definitely a primary tool choice for an openstack 
> deployer creating vm images, and should certainly be promoted where possible. 
>  I'll add an example to the doc.
> 
> The spec does try to be agnostic to the actual image creation technology in 
> play - organizations using containers or Windows images may have alternative 
> preferences about the underlying mechanism by which they generate images.  
> Decoupling the image creation from how the image is used is a key goal, 
> especially since organizations often want to separate environment preparation 
> and development along role lines.

Windows images are special, yes. For those, perhaps chat with the Murano
folk?

Containers will work fine in diskimage-builder. One only needs to hack
in the ability to save in the container image format rather than qcow2.

I actually think diskimage-builder would be really useful for container
building, as it doesn't make any assumptions about things like having a
kernel. In fact we've discussed the possibility of using lxc to do the
image builds instead of chroot so that the builds would be more
isolated from the build host.

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

Re: [openstack-dev] [Solum] Working group on language packs

[Clayton Coleman]

> On Nov 22, 2013, at 9:54 PM, Monty Taylor  wrote:
> 
> 
> 
>> On 11/22/2013 11:34 AM, Clayton Coleman wrote:
>> I have updated the language pack (name subject to change) blueprint
>> with the outcomes from the face2face meetings, and drafted a
>> specification that captures the discussion so far.  The spec is
>> centered around the core idea of transitioning base images into
>> deployable images (that can be stored in Nova and sent to Glance).
>> These are *DRAFT* and are intended for public debate.
>> 
>> https://blueprints.launchpad.net/solum/+spec/lang-pack 
>> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
>> 
>> Please take this opportunity to review these documents and offer
>> criticism and critique via the ML - I will schedule a follow up deep
>> dive for those who expressed interest in participation [1] after US
>> Thanksgiving.
> 
> Hi!
> 
> I'd strongly suggest looking at the diskimage-builder project that's
> part of the TripleO program. Someone has already done a POC of turning
> it in to an aaS, and there are already people working on tying
> diskimage-builder elements and heat templates. Given that OpenStack has
> prior art and work in this direction, you should be able to accelerate
> getting to your goals pretty quickly.

diskimage-builder is definitely a primary tool choice for an openstack deployer 
creating vm images, and should certainly be promoted where possible.  I'll add 
an example to the doc.

The spec does try to be agnostic to the actual image creation technology in 
play - organizations using containers or Windows images may have alternative 
preferences about the underlying mechanism by which they generate images.  
Decoupling the image creation from how the image is used is a key goal, 
especially since organizations often want to separate environment preparation 
and development along role lines.

> 
>> [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
>> 
>> 
>> 
>> 
>> 
>> 
>> ___ 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] 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] RFC: Potential to increase min required libvirt version to 0.9.11 ?

[Monty Taylor]

On 11/22/2013 01:02 PM, Daniel P. Berrange wrote:
> On Wed, Nov 20, 2013 at 04:02:02PM +0100, Ralf Haferkamp wrote:
>> On Wed, Nov 20, 2013 at 04:33:22PM +1300, Robert Collins wrote:
>>> On 20 November 2013 08:02, Daniel P. Berrange  wrote:
 Currently the Nova libvirt driver is declaring that it wants a minimum
 of libvirt 0.9.6.
>>> ...
 If there are other distros I've missed which expect to support deployment
 of Icehouse please add them to this list. Hopefully there won't be any
 with libvirt software older than Ubuntu 12.04 LTS


 The reason I'm asking this now, is that we're working to make the libvirt
 python module a separate tar.gz that can build with multiple libvirt
 versions, and I need to decide how ancient a libvirt we should support
 for it.
>>>
>>> Fantastic!!!
>>>
>>> The Ubuntu cloud archive
>>> https://wiki.ubuntu.com/ServerTeam/CloudArchive is how OpenStack is
>>> delivered by Canonical for Ubuntu LTS users. So I think you can go
>>> with e.g. 0.9.11 or even 0.9.12 depending on what the Suse folk say.
>> I think 0.9.11 is fine for us. I am not worried too much about 0.9.12 either
>> since openSUSE 12.2 (which has 0.9.11) will reach its EOL soon. I also added
>> SLES to the table on:
>> https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
> 
> Thanks, it looks like from the libvirt side, we are only going to be
> able to provide a standalone  libvirt-python on PyPI that works
> back to version 0.9.11.  Prior to 0.9.11 libvirt did not install its
> API description, which is a pre-requisite for the python bindings
> to build.
> 
> Fortunately 0.9.11 lines up with all the distros we've got listed
> so far.

I, for one, welcome our new libvirt overlords.

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

Re: [openstack-dev] [Cinder][Glance] OSLO update

[Monty Taylor]

On 11/20/2013 07:04 AM, Roman Bogorodskiy wrote:
> I know it was brought up on the list a number of times, but...
> 
> If we're talking about storing commit ids for each module and writing
> some shell scripts for that, isn't it a chance to reconsider using git
> submodules?

No. They're too complex. We don't allow merge commits because they're
too easy to mess up. Even seasoned (and I mean SEASONED git devs) shy
away from submodules because the semantics are tricky.

We have 1600 devs - advanced git features lead us to death. (I say this
as the person who fields questions about basic git features)

> On Wed, Nov 20, 2013 at 12:37 PM, Elena Ezhova  > wrote:
> 
> 
> 20.11.2013, 06:18, "John Griffith"  >:
> 
> 
> On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin  > wrote:
> 
> >  On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote:
> >>  Random OSLO updates with no list of what changed, what got fixed etc
> >>  are unlikely to get review attention - doing such a review is
> >>  extremely difficult. I was -2ing them and asking for more info, but
> >>  they keep popping up. I'm really not sure what the best way of
> >>  updating from OSLO is, but this isn't it.
> >  Best practice is to include a list of changes being synced, for
> example:
> >
> >https://review.openstack.org/54660
> >
> >  Every so often, we throw around ideas for automating the
> generation of
> >  this changes list - e.g. cinder would have the oslo-incubator
> commit ID
> >  for each module stored in a file in git to tell us when it was last
> >  synced.
> >
> >  Mark.
> >
> >  _
> 
> __
> >  OpenStack-dev mailing list
> >  OpenStack-dev@lists.openstack.org
> 
> >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Been away on vacation so I'm afraid I'm a bit late on this... but;
> 
> I think the point Duncan is bringing up here is that there are some
> VERY large and significant patches coming from OSLO pulls.  The DB
> patch in particular being over 1K lines of code to a critical
> portion
> of the code is a bit unnerving to try and do a review on.  I realize
> that there's a level of trust that goes with the work that's done in
> OSLO and synchronizing those changes across the projects, but I
> think
> a few key concerns here are:
> 
> 1. Doing huge pulls from OSLO like the DB patch here are nearly
> impossible to thoroughly review and test.  Over time we learn a lot
> about real usage scenarios and the database and tweak things as
> we go,
> so seeing a patch set like this show up is always a bit
> unnerving and
> frankly nobody is overly excited to review it.
> 
> 2. Given a certain level of *trust* for the work that folks do
> on the
> OSLO side in submitting these patches and new additions, I think
> some
> of the responsibility on the review of the code falls on the OSLO
> team.  That being said there is still the issue of how these changes
> will impact projects *other* than Nova which I think is sometimes
> neglected.  There have been a number of OSLO synchs pushed to Cinder
> that fail gating jobs, some get fixed, some get abandoned, but in
> either case it shows that there wasn't any testing done with
> projects
> other than Nova (PLEASE note, I'm not referring to this particular
> round of patches or calling any patch set out, just stating a
> historical fact).
> 
> 3. We need better documentation in commit messages explaining
> why the
> changes are necessary and what they do for us.  I'm sorry but in my
> opinion the answer "it's the latest in OSLO and Nova already has it"
> is not enough of an answer in my opinion.  The patches mentioned in
> this thread in my opinion met the minimum requirements because
> they at
> least reference the OSLO commit which is great.  In addition I'd
> like
> to see something to address any discovered issues or testing
> done with
> the specific projects these changes are being synced to.
> 
> I'm in no way saying I don't want Cinder to play nice with the
> common
> code or to get in line with the way other projects do things but
> I am
> saying that I think we have a ways to go in terms of better
> communication here and in terms of OSLO code actually keeping in
> mind
> the entire OpenStack eco-system as opposed to just changes that were
> needed/

Re: [openstack-dev] [Solum] Working group on language packs

[Monty Taylor]

On 11/22/2013 11:34 AM, Clayton Coleman wrote:
> I have updated the language pack (name subject to change) blueprint
> with the outcomes from the face2face meetings, and drafted a
> specification that captures the discussion so far.  The spec is
> centered around the core idea of transitioning base images into
> deployable images (that can be stored in Nova and sent to Glance).
> These are *DRAFT* and are intended for public debate.
> 
> https://blueprints.launchpad.net/solum/+spec/lang-pack 
> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
>
>  Please take this opportunity to review these documents and offer
> criticism and critique via the ML - I will schedule a follow up deep
> dive for those who expressed interest in participation [1] after US
> Thanksgiving.

Hi!

I'd strongly suggest looking at the diskimage-builder project that's
part of the TripleO program. Someone has already done a POC of turning
it in to an aaS, and there are already people working on tying
diskimage-builder elements and heat templates. Given that OpenStack has
prior art and work in this direction, you should be able to accelerate
getting to your goals pretty quickly.

> [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
> 
> 
> 
> 
> 
> 
> ___ 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] [Solum] git-Integration working group

[Adrian Otto]

Monty,

On Nov 22, 2013, at 6:24 PM, Monty Taylor 
 wrote:

> On 11/22/2013 05:37 PM, Krishna Raman wrote:
>> Hello all,
>> 
>> I would like to kickoff the Git integration discussion. Goal of this
>> subgroup is to go through the git-integration blueprint [1] and break it
>> up into smaller blueprints that we can execute on.
>> 
>> We have to consider 2 workflows:
>>   1) For Milestone 1, pull based git workflow where user uses a public
>> git repository (possibly on github) to trigger the build
>>   2) For later milestones, a push based workflow where the git
>> repository is maintained by Solum
> 
> Hi!

Hi, thanks for chiming in here.

> I'm a little disappointed that we've decided to base the initial
> workflow on something that is not related to the world-class git-based
> developer tooling that the OpenStack project has already produced. We
> have a GIANT amount of tooling in this space, and it's all quite
> scalable. There is also the intent by 3 or 4 different groups to make it
> more re-usable/re-consumable, including thoughts in making sure that we
> can drive it from and have it consume heat.

The initial work will be something pretty trivial. It's just a web hook on a 
git push. The workflow in this case is not customizable, and has basically no 
features. The intent is to iterate on this to make it much more compelling over 
time, soon after the minimum integration, we will put a real workflow system in 
place. We did discuss Zuul and Nodepool, and nobody had any objection to 
learning more about those. This might be a bit early in our roadmap to be 
pulling them in, but if there is an easy way to use them early in our 
development, we'd like to explore that.

>> Devdatta has created 2 blueprints for consideration: [2] [3]
>> 
>> I have set up a doodle to poll for a /recurring/ meeting time for this
>> subgroup: http://doodle.com/7wypkzqe9wep3d33#table   (Timezone support
>> is enabled)
>> 
>> Currently the plan is to try G+ hangouts to run this meetings and scribe
>> on #solum. This will limit us to a
>> max of 10 participants. If we have more interest, we will need to see
>> how to change the meetings.
> 
> We have IRC meeting channels for meetings. They are logged - and they
> have the benefit that they do not require non-Open Source software to
> access. If you have them in IRC, the team from OpenStack who is already
> working on developer workflow around git can potentially participate.
> 
> I don't mean to be negative, but if you want to be a PaaS for OpenStack,
> I would strongly consider not using G+ when we have IRC, and I would
> strongly suggest engaging with the Infra projects that already know how
> to do git-based workflow and action triggering.

We just finished holding the Solum Community Design Workshop in San Francisco. 
We had both irc and G+ in addition to etherpad for shared notetaking. What we 
found is that that collaboration was faster and more effective when we used the 
G+ tool. The remote participants had a strong preference for it, and requested 
that we use it for the breakout meetings as well. The breakout design meetings 
will have a scribe who will transcribe the interaction in IRC so it will also 
be logged.

Please recognize that we have not yet considered an alternate point of view on 
either of these subjects yet, because one has not been raised until now. I'm 
open to suggestions for how best to engage the experts on git integration so we 
can benefit from the expertise in our community.

Thanks,

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

Re: [openstack-dev] How to stage client major releases in Gerrit?

[Monty Taylor]

On 11/22/2013 09:57 AM, Dolph Mathews wrote:
> 
> On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez  > wrote:
> 
> Robert Collins wrote:
> > I don't understand why branches would be needed here *if* the breaking
> > changes don't impact any supported release of OpenStack.
> 
> Right -- the trick is what does "supported" mean in that case.
> 
> When the client libraries were first established as separate
> deliverables, they came up with a blanket statement that the latest
> version could always be used with *any* version of openstack you may
> have. The idea being, if some public cloud was still stuck in pre-diablo
> times, you could still use the same library to address both this public
> cloud and the one which was 2 weeks behind Havana HEAD.
> 
> 
> I'm curious about the historical circumstance of this requirement --
> were the services supported "master, minus two releases" at the time?
> 
> We're not testing more than two stable releases against the latest
> clients in CI today, so I find it odd that we still bother with this
> claim, without demonstrating that it's true.

The design of this comes from an end-user perspective.

If Alice wants to use a cloud, Bob, Alice should download the current
python-glanceclient library, provide it with her credentials, and it
should work, regardless of what version of OpenStack Bob's operator
happens to be running.

The reason for the above is that any other approach is a TERRIBLE end
user experience. (As a person who currently is involved with running a
scalable cloud application on two OpenStack clouds that are wildly
different versions, I can tell you, needing to install different client
library versions to talk to them would be madness.

That's about outbound API versions though. That means that master
*client must always be able to speak to every extant API version.

This question is actually about python API consumption, and when we made
the policy, we did discuss that were a breaking change to be made in the
Python API, clearly the semver Major version should be bumped.

Unfortunately for this conversation, we stopped with Brian Waldon's
assertion of the major version bump and did not design a system to
handle it. We do not currently have the machinery to handle it. At the
very latest, we would need to design a modification to how zuul and
devstack-gate construct collections of changesets.

That said - we need to think about the questions raised above in terms
of support of python API. But, more importantly, we should really think
long and hard about breaking the python API, even with a major version
bump, because no matter how you do it, it's disruptive to library consumers.

> --
> Thierry Carrez (ttx)
> 
> ___
> 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

Re: [openstack-dev] [Solum] git-Integration working group

[Rajesh Ramchandani]

From: Monty Taylor 
Sent: Friday, November 22, 2013 6:24 PM
To: openstack-dev@lists.openstack.org; Adrian Otto
Subject: Re: [openstack-dev] [Solum] git-Integration working group

On 11/22/2013 05:37 PM, Krishna Raman wrote:
> Hello all,
>
> I would like to kickoff the Git integration discussion. Goal of this
> subgroup is to go through the git-integration blueprint [1] and break it
> up into smaller blueprints that we can execute on.
>
> We have to consider 2 workflows:
>1) For Milestone 1, pull based git workflow where user uses a public
> git repository (possibly on github) to trigger the build
>2) For later milestones, a push based workflow where the git
> repository is maintained by Solum

Hi!

>I'm a little disappointed that we've decided to base the initial
>workflow on something that is not related to the world-class git-based
>developer tooling that the OpenStack project has already produced. We
>have a GIANT amount of tooling in this space, and it's all quite
>scalable.

RR: Can you provide some pointers to the tooling / Workflow you suggesting?

Thanks


 There is also the intent by 3 or 4 different groups to make it
more re-usable/re-consumable, including thoughts in making sure that we
can drive it from and have it consume heat.

> Devdatta has created 2 blueprints for consideration: [2] [3]
>
> I have set up a doodle to poll for a /recurring/ meeting time for this
> subgroup: http://doodle.com/7wypkzqe9wep3d33#table   (Timezone support
> is enabled)
>
> Currently the plan is to try G+ hangouts to run this meetings and scribe
> on #solum. This will limit us to a
> max of 10 participants. If we have more interest, we will need to see
> how to change the meetings.

We have IRC meeting channels for meetings. They are logged - and they
have the benefit that they do not require non-Open Source software to
access. If you have them in IRC, the team from OpenStack who is already
working on developer workflow around git can potentially participate.

I don't mean to be negative, but if you want to be a PaaS for OpenStack,
I would strongly consider not using G+ when we have IRC, and I would
strongly suggest engaging with the Infra projects that already know how
to do git-based workflow and action triggering.

___
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] How to stage client major releases in Gerrit?

[Monty Taylor]

On 11/22/2013 06:55 PM, Mark Washenberger wrote:
> 
> 
> 
> On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins
> mailto:robe...@robertcollins.net>> wrote:
> 
> On 22 November 2013 22:31, Thierry Carrez  > wrote:
> > Robert Collins wrote:
> >> I don't understand why branches would be needed here *if* the
> breaking
> >> changes don't impact any supported release of OpenStack.
> >
> > Right -- the trick is what does "supported" mean in that case.
> >
> > When the client libraries were first established as separate
> > deliverables, they came up with a blanket statement that the latest
> > version could always be used with *any* version of openstack you may
> > have. The idea being, if some public cloud was still stuck in
> pre-diablo
> > times, you could still use the same library to address both this
> public
> > cloud and the one which was 2 weeks behind Havana HEAD.
> 
> Huh. There are two different directions we use the client in.
> 
> Client install -> cloud API (of arbitrary version A)
> 
> Server install (of arbitrary version B) using the Python library ->
> cloud API (version B)
> 
> From a gating perspective I think we want to check
> that:
>  - we can use the client against some set of cloud versions A
>  - that some set of version B where servers running cloud version B
> can use the client against cloud version B
> 
> But today we don't test against ancient versions of A or B.
> 
> If we were to add tests for such scenarios, I'd strongly argue that we
> only add then for case A. Where we are using the client lib in an
> installed cloud, we don't need to test that it can still be used
> against pre-diablo etc: such installed clouds can keep using the old
> client lib.
> 
> 
> I'm afraid that if a critical bug is found in the old client lib, the
> current path for fixing it is to ask people to update to the latest
> client version, even internally to their old cloud. So would that cause
> a branch for backporting fixes?

The plan is that the current client libs should always be installable.
So we would not (and never have) make a branch for backporting fixes.

> FWIW, I don't think the changes glanceclient needs in v1 will break the
> 'B' case above. But it does raise a question--if they did, would it be
> sufficient to backport a change to adapt old supported stable B versions
> of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO
> is okay. 

I'm not sure I follow all the pronouns. Could you re-state this again, I
think I know what you're asking, but I'd like to be sure.

> 
> So assuming you agree with that assertion, where do we need a branch
> here?
> 
> -Rob
> 
> --
> Robert Collins mailto:rbtcoll...@hp.com>>
> Distinguished Technologist
> HP Converged Cloud
> 
> ___
> 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] [Solum] git-Integration working group

[Monty Taylor]

On 11/22/2013 05:37 PM, Krishna Raman wrote:
> Hello all,
> 
> I would like to kickoff the Git integration discussion. Goal of this
> subgroup is to go through the git-integration blueprint [1] and break it
> up into smaller blueprints that we can execute on.
> 
> We have to consider 2 workflows:
>1) For Milestone 1, pull based git workflow where user uses a public
> git repository (possibly on github) to trigger the build
>2) For later milestones, a push based workflow where the git
> repository is maintained by Solum

Hi!

I'm a little disappointed that we've decided to base the initial
workflow on something that is not related to the world-class git-based
developer tooling that the OpenStack project has already produced. We
have a GIANT amount of tooling in this space, and it's all quite
scalable. There is also the intent by 3 or 4 different groups to make it
more re-usable/re-consumable, including thoughts in making sure that we
can drive it from and have it consume heat.

> Devdatta has created 2 blueprints for consideration: [2] [3]
> 
> I have set up a doodle to poll for a /recurring/ meeting time for this
> subgroup: http://doodle.com/7wypkzqe9wep3d33#table   (Timezone support
> is enabled)
> 
> Currently the plan is to try G+ hangouts to run this meetings and scribe
> on #solum. This will limit us to a
> max of 10 participants. If we have more interest, we will need to see
> how to change the meetings.

We have IRC meeting channels for meetings. They are logged - and they
have the benefit that they do not require non-Open Source software to
access. If you have them in IRC, the team from OpenStack who is already
working on developer workflow around git can potentially participate.

I don't mean to be negative, but if you want to be a PaaS for OpenStack,
I would strongly consider not using G+ when we have IRC, and I would
strongly suggest engaging with the Infra projects that already know how
to do git-based workflow and action triggering.

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

Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova

[Matt Riedemann]

On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote:

On 11/22/2013 06:01 PM, Christopher Yeoh wrote:


On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:

 ...
 21:51:42  i just hope that the version discovery mechanism
 is smart enough to realize when it's handed a versioned endpoint,
 and happily run with that
 ...
 21:52:00  (by calling that endpoint and doing proper discovery)
 ...
 21:52:24  dolphm: yeah, need to handle that gracefully ...



Just one point here (and perhaps I'm misunderstanding what was meant),
but if the catalog points to a versioned endpoint
shouldn't we just use that version rather than trying to discover what
other versions may be
available. Although we'll have cases of it just being set to a versioned
endpoint because thats how it
has been done in the past I think we should be making the assumption
that if we're pointed to a specific version,
that is the one we should be using.


Agreed, and I think that's what Dolph and I meant.



That also covers the override case that was expressed a few different 
times in this thread, giving the admin the ability to pin his 
environment to the version he knows and trusts during, for example, 
upgrades, and then slowly transitioning to a newer API.  The nice thing 
with that approach is it should keep config options with hard-coded 
versions out of nova.conf which is what was being proposed in the 
glance and cinder v2 blueprint patches.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] How to stage client major releases in Gerrit?

[Jeremy Stanley]

On 2013-11-22 16:18:10 -0800 (-0800), Mark Washenberger wrote:
> Cool. Is this documentation essentially explaining how to keep a
> feature branch up to date with master? (spoiler warning:
> carefully use merge commits?)

Yes, the assumption there is that you want to do development work on
your 2.0 release in a feature branch while continuing to fix bugs in
1.x on your master branch, merge minimal patches from master into
your feature branch as you continue to shape it, and then merge the
feature branch back to master once you're ready to deprecate 1.x and
release 2.0.

I'm not necessarily suggesting that's the right pattern for
deprecation and introducing backward-incompatible changes, just
explaining how we've used feature branches as a pattern elsewhere.
Others (Robert?) will also point out that you're likely going to
encounter just as many issues from developing this on a separate
branch as you would working inline on master and hiding feature
changes behind switches, so the added complexity here may not gain
you any real convenience.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Brian Elliott]

+1

Solid reviewer!

Sent from my iPad

> On Nov 22, 2013, at 2:53 PM, Russell Bryant  wrote:
> 
> Greetings,
> 
> I would like to propose adding Matt Riedemann to the nova-core review team.
> 
> Matt has been involved with nova for a long time, taking on a wide range
> of tasks.  He writes good code.  He's very engaged with the development
> community.  Most importantly, he provides good code reviews and has
> earned the trust of other members of the review team.
> 
> https://review.openstack.org/#/dashboard/6873
> https://review.openstack.org/#/q/owner:6873,n,z
> https://review.openstack.org/#/q/reviewer:6873,n,z
> 
> Please respond with +1/-1, or any further comments.
> 
> Thanks,
> 
> -- 
> 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] How to stage client major releases in Gerrit?

[Mark Washenberger]

On Fri, Nov 22, 2013 at 12:03 PM, Jeremy Stanley  wrote:

> On 2013-11-22 10:34:40 +0100 (+0100), Thierry Carrez wrote:
> > It can be created on request by release management members (or
> > infra-core team). I /think/ that by default it would get tested against
> > master in other branches.
>
> More details at...
>
> https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits >
>

Cool. Is this documentation essentially explaining how to keep a feature
branch up to date with master? (spoiler warning: carefully use merge
commits?)


>
> --
> 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] How to stage client major releases in Gerrit?

[Mark Washenberger]

On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins
wrote:

> On 22 November 2013 22:31, Thierry Carrez  wrote:
> > Robert Collins wrote:
> >> I don't understand why branches would be needed here *if* the breaking
> >> changes don't impact any supported release of OpenStack.
> >
> > Right -- the trick is what does "supported" mean in that case.
> >
> > When the client libraries were first established as separate
> > deliverables, they came up with a blanket statement that the latest
> > version could always be used with *any* version of openstack you may
> > have. The idea being, if some public cloud was still stuck in pre-diablo
> > times, you could still use the same library to address both this public
> > cloud and the one which was 2 weeks behind Havana HEAD.
>
> Huh. There are two different directions we use the client in.
>
> Client install -> cloud API (of arbitrary version A)
>
> Server install (of arbitrary version B) using the Python library ->
> cloud API (version B)
>
> From a gating perspective I think we want to check
> that:
>  - we can use the client against some set of cloud versions A
>  - that some set of version B where servers running cloud version B
> can use the client against cloud version B
>
> But today we don't test against ancient versions of A or B.
>
> If we were to add tests for such scenarios, I'd strongly argue that we
> only add then for case A. Where we are using the client lib in an
> installed cloud, we don't need to test that it can still be used
> against pre-diablo etc: such installed clouds can keep using the old
> client lib.
>

I'm afraid that if a critical bug is found in the old client lib, the
current path for fixing it is to ask people to update to the latest client
version, even internally to their old cloud. So would that cause a branch
for backporting fixes?

FWIW, I don't think the changes glanceclient needs in v1 will break the 'B'
case above. But it does raise a question--if they did, would it be
sufficient to backport a change to adapt old supported stable B versions
of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is
okay.


>
> So assuming you agree with that assertion, where do we need a branch here?
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> 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][Glance] Support of v1 and v2 glance APIs in Nova

[Russell Bryant]

On 11/22/2013 06:01 PM, Christopher Yeoh wrote:
> 
> On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann
> mailto:mrie...@linux.vnet.ibm.com>> wrote:
> 
> ...
> 21:51:42  i just hope that the version discovery mechanism
> is smart enough to realize when it's handed a versioned endpoint,
> and happily run with that
> ...
> 21:52:00  (by calling that endpoint and doing proper discovery)
> ...
> 21:52:24  dolphm: yeah, need to handle that gracefully ...
> 
> 
> 
> Just one point here (and perhaps I'm misunderstanding what was meant),
> but if the catalog points to a versioned endpoint
> shouldn't we just use that version rather than trying to discover what
> other versions may be
> available. Although we'll have cases of it just being set to a versioned
> endpoint because thats how it
> has been done in the past I think we should be making the assumption
> that if we're pointed to a specific version,
> that is the one we should be using.

Agreed, and I think that's what Dolph and I meant.

-- 
Russell Bryant

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Chris Friesen]

On 11/22/2013 02:29 PM, Russell Bryant wrote:


I honestly don't understand why openstack@ and openstack-operators@ are
different lists.  Perhaps openstack@ just needs better use of topic
tagging ...


Wouldn't openstack@ be the logical place for end-users to hang out, 
while openstack-operators@ is for the actual cloud providers?


Chris


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

Re: [openstack-dev] [Solum] Working group on language packs

[Adrian Otto]

The breakout meeting schedule poll is published here (dates will be published 
here once they are selected):
https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Language_Pack_Working_Group_Series

If you would like to join the working group, please:

1) Subscribe to the lang-pack blueprint: 
https://blueprints.launchpad.net/solum/+spec/lang-pack
2) Participate in the doodle poll currently published on the wiki page 
referenced above to help select the best time for the meetings.

Thanks,

Adrian


For those interested in joining this working group,
On Nov 22, 2013, at 8:34 AM, Clayton Coleman  wrote:

> I have updated the language pack (name subject to change) blueprint with the 
> outcomes from the face2face meetings, and drafted a specification that 
> captures the discussion so far.  The spec is centered around the core idea of 
> transitioning base images into deployable images (that can be stored in Nova 
> and sent to Glance).  These are *DRAFT* and are intended for public debate.  
> 
> https://blueprints.launchpad.net/solum/+spec/lang-pack
> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts
> 
> Please take this opportunity to review these documents and offer criticism 
> and critique via the ML - I will schedule a follow up deep dive for those who 
> expressed interest in participation [1] after US Thanksgiving.
> 
> [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
> 
> 
> 
> 
> 
> 
> ___
> 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][Glance] Support of v1 and v2 glance APIs in Nova

[Christopher Yeoh]

On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann
wrote:

> ...
> 21:51:42  i just hope that the version discovery mechanism is
> smart enough to realize when it's handed a versioned endpoint, and happily
> run with that
> ...
> 21:52:00  (by calling that endpoint and doing proper discovery)
> ...
> 21:52:24  dolphm: yeah, need to handle that gracefully ...
>
>

Just one point here (and perhaps I'm misunderstanding what was meant), but
if the catalog points to a versioned endpoint
shouldn't we just use that version rather than trying to discover what
other versions may be
available. Although we'll have cases of it just being set to a versioned
endpoint because thats how it
has been done in the past I think we should be making the assumption that
if we're pointed to a specific version,
that is the one we should be using.

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

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Joe Gordon]

+1


On Fri, Nov 22, 2013 at 2:41 PM, Christopher Yeoh  wrote:

>
>
> +1
>
>
> On Sat, Nov 23, 2013 at 7:23 AM, Russell Bryant wrote:
>
>> Greetings,
>>
>> I would like to propose adding Matt Riedemann to the nova-core review
>> team.
>>
>> Matt has been involved with nova for a long time, taking on a wide range
>> of tasks.  He writes good code.  He's very engaged with the development
>> community.  Most importantly, he provides good code reviews and has
>> earned the trust of other members of the review team.
>>
>> https://review.openstack.org/#/dashboard/6873
>> https://review.openstack.org/#/q/owner:6873,n,z
>> https://review.openstack.org/#/q/reviewer:6873,n,z
>>
>> Please respond with +1/-1, or any further comments.
>>
>> Thanks,
>>
>> --
>> 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] Proposal to add Matt Riedemann to nova-core

[Christopher Yeoh]

+1

On Sat, Nov 23, 2013 at 7:23 AM, Russell Bryant  wrote:

> Greetings,
>
> I would like to propose adding Matt Riedemann to the nova-core review team.
>
> Matt has been involved with nova for a long time, taking on a wide range
> of tasks.  He writes good code.  He's very engaged with the development
> community.  Most importantly, he provides good code reviews and has
> earned the trust of other members of the review team.
>
> https://review.openstack.org/#/dashboard/6873
> https://review.openstack.org/#/q/owner:6873,n,z
> https://review.openstack.org/#/q/reviewer:6873,n,z
>
> Please respond with +1/-1, or any further comments.
>
> Thanks,
>
> --
> 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] [Solum] git-Integration working group

[Krishna Raman]

Hello all,

I would like to kickoff the Git integration discussion. Goal of this subgroup 
is to go through the git-integration blueprint [1] and break it up into smaller 
blueprints that we can execute on.

We have to consider 2 workflows:
   1) For Milestone 1, pull based git workflow where user uses a public git 
repository (possibly on github) to trigger the build
   2) For later milestones, a push based workflow where the git repository is 
maintained by Solum

Devdatta has created 2 blueprints for consideration: [2] [3]

I have set up a doodle to poll for a recurring meeting time for this subgroup: 
http://doodle.com/7wypkzqe9wep3d33#table   (Timezone support is enabled)

Currently the plan is to try G+ hangouts to run this meetings and scribe on 
#solum. This will limit us to a
max of 10 participants. If we have more interest, we will need to see how to 
change the meetings.

Thanks
Krishna

[1] https://blueprints.launchpad.net/solum/+spec/git-integration
[2] https://blueprints.launchpad.net/solum/+spec/solum-git-push
[3] https://blueprints.launchpad.net/solum/+spec/solum-git-pull___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Sylvain Bauza]

> 
> De : Robert Collins [robe...@robertcollins.net]
> Date d'envoi : jeudi 21 novembre 2013 21:58
> À : OpenStack Development Mailing List
> Objet : [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest
> proposal for an external scheduler in our lifetime
>
> https://etherpad.openstack.org/p/icehouse-external-scheduler
>
> I'm looking for 4-5 folk who have:
>  - modest Nova skills
>  - time to follow a fairly mechanical (but careful and detailed work
> needed) plan to break the status quo around scheduler extraction
>
> And of course, discussion galore about the idea :)
>
> Cheers,
> Rob
>
>
Hi Rob,

I can also add Climate as a separate Stackforge project which could get
benefits from querying a scheduler service for electing some compute-hosts
based on what we call a 'reservation request' [1]
By the way, you mentioned the original BP for Climate [2] in the etherpad,
which does let me thinking we are on the same page.

That said, I would really love joining the team for delivering the new
service, but unfortunately, I will only be able to commit myself on my
personal spare time.

Anyway, I'm following the discussion, whatever the outcome is.

-Sylvain

[1] https://etherpad.openstack.org/p/NovaIcehouse-ClimateInteractions
[2]
https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Mark McLoughlin]

On Fri, 2013-11-22 at 15:53 -0500, Russell Bryant wrote:
> Greetings,
> 
> I would like to propose adding Matt Riedemann to the nova-core review team.
> 
> Matt has been involved with nova for a long time, taking on a wide range
> of tasks.  He writes good code.  He's very engaged with the development
> community.  Most importantly, he provides good code reviews and has
> earned the trust of other members of the review team.
> 
> https://review.openstack.org/#/dashboard/6873
> https://review.openstack.org/#/q/owner:6873,n,z
> https://review.openstack.org/#/q/reviewer:6873,n,z
> 
> Please respond with +1/-1, or any further comments.

+1, definitely a great addition to the team

Mark.


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

[openstack-dev] [OSSG][OSSN] Authenticated users are able to update passwords without providing their current password

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Authenticated users are able to update passwords without providing
their current password
- ---

### Summary ###
An authenticated user is able to change their password without
providing their current password. This allows compromised
authentication tokens to be used to permanently compromise a user account.

### Affected Services / Software ###
Horizon, Keystone, Identity, Grizzly

### Discussion ###
Horizon allows a user to change their own password, which uses the
Identity API to perform the password change. A user is required to
supply their current password to successfully perform a password
change. This requirement prevents a malicious user from stealing a
user's authentication token and changing that user's password to
permanently compromise their account. With this additional password
check, a compromised authentication token only compromises the user
account until the token is no longer valid due to expiration or
revocation.

When using the Identity v3 API, a user is able to successfully change
their password without supplying the correct current password. This
leaves users vulnerable to permanently compromised accounts if their
authentication token is compromised. The Identity v2 API is not
vulnerable to this issue, as it has a separate API call for updating
user passwords that properly validates the current password.

### Recommended Actions ###
In the OpenStack Grizzly release, a user is allowed to update the
attributes in their own entry by default. It is recommended that you
restrict user updates to only be allowed by admin users. This is done
by setting the "update_user" policy to "admin_required" in Keystone's
policy.json file. Here is an example snippet of a properly configured
policy.json file:

-  begin example policy.json snippet 
"identity:get_user": [["rule:admin_required"]],
"identity:list_users": [["rule:admin_required"]],
"identity:create_user": [["rule:admin_required"]],
"identity:update_user": [["rule:admin_required"]],
"identity:delete_user": [["rule:admin_required"]],
-  end example policy.json snippet 

This change has the side-effect of restricting a user from updating
any of their own attributes, not just their password.

In the OpenStack Havana release, the default policy is to only allow
admin users to update attributes in user entries. In addition, Horizon
will not allow a user to change their own password if it is using the
Identity v3 API, even if Keystone is configured to allow users to
update their own entries. Despite this restriction in Horizon, it is
recommended to leave the default "update_user" policy setting as is,
as an attacker could target Keystone directly without using Horizon to
initiate a password change.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4471
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSj9ZNAAoJEJa+6E7Ri+EVGLsH/1j3E6fiO/QInwO2bx7stVHN
27KWvP/8GcLzgNNYN9qMcJExCA5ZbmOXIJlzOR12x/7hrNMkShaaC+VQTYwInn0e
TQ0AESwdb08Wv4GeFDOuc2sliYrH9JR5Lr8/kjGFsmSZ3O4Pyl4AGBrXUDehoVCZ
rq3cSC9+utn11o+lY9BZigbufBCBdWHKKoJ93wEdnTkjl6cQAekqLJyTXLltR5x/
7vSz4e0bYKLyKFZ5BLdPn2gR7pFfnjhlG+oZR0TwGYSCDLJeFFY5tkUKbc2hyGwi
DqPp1escgHTDzXm2gUXWOHs8k0yitHq9JL62VXqL2lbWvbb/HJsCD87JUrFVLUo=
=OLH1
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova

[Matt Riedemann]

On Thursday, November 21, 2013 9:56:41 AM, Matt Riedemann wrote:



On 11/3/2013 5:22 AM, Joe Gordon wrote:


On Nov 1, 2013 6:46 PM, "John Garbutt" mailto:j...@johngarbutt.com>> wrote:
 >
 > On 29 October 2013 16:11, Eddie Sheffield
mailto:eddie.sheffi...@rackspace.com>>
wrote:
 > >
 > > "John Garbutt" mailto:j...@johngarbutt.com>>
said:
 > >
 > >> Going back to Joe's comment:
 > >>> Can both of these cases be covered by configuring the keystone
catalog?
 > >> +1
 > >>
 > >> If both v1 and v2 are present, pick v2, otherwise just pick
what is in
 > >> the catalogue. That seems cool. Not quite sure how the multiple
glance
 > >> endpoints works in the keystone catalog, but should work I assume.
 > >>
 > >> We hard code nova right now, and so we probably want to keep that
route too?
 > >
 > > Nova doesn't use the catalog from Keystone when talking to Glance.
There is a config value "glance_api_servers" which defines a list of
Glance servers that gets randomized and cycled through. I assume that's
what you're referring to with "we hard code nova." But currently there's
nowhere in this path (internal nova to glance) where the keystone
catalog is available.
 >
 > Yes. I was not very clear. I am proposing we change that. We could
try
 > shoehorn the multiple glance nodes in the keystone catalog, then
cache
 > that in the context, but maybe that doesn't make sense. This is a
 > separate change really.

FYI:  We cache the cinder endpoints from keystone catalog in the context
already. So doing something like that with glance won't be without
president.

 >
 > But clearly, we can't drop the direct configuration of glance servers
 > for some time either.
 >
 > > I think some of the confusion may be that Glanceclient at the
programmatic client level doesn't talk to keystone. That happens happens
higher in the CLI level which doesn't come into play here.
 > >
 > >> From: "Russell Bryant" mailto:rbry...@redhat.com>>
 > >>> On 10/17/2013 03:12 PM, Eddie Sheffield wrote:
 >  Might I propose a compromise?
 > 
 >  1) For the VERY short term, keep the config value and get the
change otherwise
 >  reviewed and hopefully accepted.
 > 
 >  2) Immediately file two blueprints:
 > - python-glanceclient - expose a way to discover available
versions
 > - nova - depends on the glanceclient bp and allowing
autodiscovery of glance
 >  version
 >  and making the config value optional (tho not
deprecated / removed)
 > >>>
 > >>> Supporting both seems reasonable.  At least then *most* people
don't
 > >>> need to worry about it and it "just works", but the override is
there if
 > >>> necessary, since multiple people seem to be expressing a desire
to have
 > >>> it available.
 > >>
 > >> +1
 > >>
 > >>> Can we just do this all at once?  Adding this to glanceclient
doesn't
 > >>> seem like a huge task.
 > >>
 > >> I worry about us never getting the full solution, but it seems
to have
 > >> got complicated.
 > >
 > > The glanceclient side is done, as far as allowing access to the
list of available API versions on a given server. It's getting Nova to
use this info that's a bit sticky.
 >
 > Hmm, OK. Could we not just cache the detected version, to reduce the
 > impact of that decision.
 >
 > >> On 28 October 2013 15:13, Eddie Sheffield
mailto:eddie.sheffi...@rackspace.com>>
wrote:
 > >>> So...I've been working on this some more and hit a bit of a
snag. The
 > >>> Glanceclient change was easy, but I see now that doing this in
nova will require
 > >>> a pretty huge change in the way things work. Currently, the API
version is
 > >>> grabbed from the config value, the appropriate driver is
instantiated, and calls
 > >>> go through that. The problem comes in that the actually glance
server isn't
 > >>> communicated with until very late in the process. Nothing "sees"
the servers at
 > >>> the level where the driver is determined. Also there isn't a
single glance server
 > >>> but a list of them, and in the even of certain communication
failures the list is
 > >>> cycled through until success or a number of retries has passed.
 > >>>
 > >>> So to change this to auto configuring will require turning this
upside down,
 > >>> cycling through the servers at a higher level, choosing the
appropriate driver
 > >>> for that server, and handling retries at that same level.
 > >>>
 > >>> Doable, but a much larger task than I first was thinking.
 > >>>
 > >>> Also, I don't really want the added overhead of getting the api
versions before
 > >>> every call, so I'm thinking that going through the list of
servers at startup and
 > >>> discovering the versions then and caching that somehow would be
helpful as well.
 > >>>
 > >>> Thoughts?
 > >>
 > >> I do worry about that overhead. But with Joe's comment, does it
not
 > >> just boil down to caching the keystone catalog in the context?
 > >>
 > >> I am not a fan of all the specific talk to glance code we have in
 > >> nova, moving more of that into glance

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

[Michael Still]

Could we push to 1.0.0? That would give us live snapshotting...

Michael

On Sat, Nov 23, 2013 at 7:29 AM, 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.
> --
> Jeremy Stanley
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Rackspace Australia

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

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Andrew Laski]

+1

On 11/22/13 at 03:53pm, Russell Bryant wrote:

Greetings,

I would like to propose adding Matt Riedemann to the nova-core review team.

Matt has been involved with nova for a long time, taking on a wide range
of tasks.  He writes good code.  He's very engaged with the development
community.  Most importantly, he provides good code reviews and has
earned the trust of other members of the review team.

https://review.openstack.org/#/dashboard/6873
https://review.openstack.org/#/q/owner:6873,n,z
https://review.openstack.org/#/q/reviewer:6873,n,z

Please respond with +1/-1, or any further comments.

Thanks,

--
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] [Nova] Proposal to add Matt Riedemann to nova-core

[Michael Still]

+1

On Sat, Nov 23, 2013 at 8:11 AM, Dan Smith  wrote:
>> Please respond with +1/-1, or any further comments.
>
> +1 from me -- Matt has been helping a lot lately.
>
> --Dan
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Rackspace Australia

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

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Chris Behrens]

+1

> On Nov 22, 2013, at 12:53 PM, Russell Bryant  wrote:
> 
> Greetings,
> 
> I would like to propose adding Matt Riedemann to the nova-core review team.
> 
> Matt has been involved with nova for a long time, taking on a wide range
> of tasks.  He writes good code.  He's very engaged with the development
> community.  Most importantly, he provides good code reviews and has
> earned the trust of other members of the review team.
> 
> https://review.openstack.org/#/dashboard/6873
> https://review.openstack.org/#/q/owner:6873,n,z
> https://review.openstack.org/#/q/reviewer:6873,n,z
> 
> Please respond with +1/-1, or any further comments.
> 
> Thanks,
> 
> -- 
> 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] How to stage client major releases in Gerrit?

[Robert Collins]

On 22 November 2013 22:31, Thierry Carrez  wrote:
> Robert Collins wrote:
>> I don't understand why branches would be needed here *if* the breaking
>> changes don't impact any supported release of OpenStack.
>
> Right -- the trick is what does "supported" mean in that case.
>
> When the client libraries were first established as separate
> deliverables, they came up with a blanket statement that the latest
> version could always be used with *any* version of openstack you may
> have. The idea being, if some public cloud was still stuck in pre-diablo
> times, you could still use the same library to address both this public
> cloud and the one which was 2 weeks behind Havana HEAD.

Huh. There are two different directions we use the client in.

Client install -> cloud API (of arbitrary version A)

Server install (of arbitrary version B) using the Python library ->
cloud API (version B)

>From a gating perspective I think we want to check
that:
 - we can use the client against some set of cloud versions A
 - that some set of version B where servers running cloud version B
can use the client against cloud version B

But today we don't test against ancient versions of A or B.

If we were to add tests for such scenarios, I'd strongly argue that we
only add then for case A. Where we are using the client lib in an
installed cloud, we don't need to test that it can still be used
against pre-diablo etc: such installed clouds can keep using the old
client lib.

So assuming you agree with that assertion, where do we need a branch here?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Dan Smith]

> Please respond with +1/-1, or any further comments.

+1 from me -- Matt has been helping a lot lately.

--Dan

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

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

[Aaron Rosen]

+1


On Fri, Nov 22, 2013 at 12:53 PM, Russell Bryant  wrote:

> Greetings,
>
> I would like to propose adding Matt Riedemann to the nova-core review team.
>
> Matt has been involved with nova for a long time, taking on a wide range
> of tasks.  He writes good code.  He's very engaged with the development
> community.  Most importantly, he provides good code reviews and has
> earned the trust of other members of the review team.
>
> https://review.openstack.org/#/dashboard/6873
> https://review.openstack.org/#/q/owner:6873,n,z
> https://review.openstack.org/#/q/reviewer:6873,n,z
>
> Please respond with +1/-1, or any further comments.
>
> Thanks,
>
> --
> 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] [Nova] Proposal to add Matt Riedemann to nova-core

[Russell Bryant]

Greetings,

I would like to propose adding Matt Riedemann to the nova-core review team.

Matt has been involved with nova for a long time, taking on a wide range
of tasks.  He writes good code.  He's very engaged with the development
community.  Most importantly, he provides good code reviews and has
earned the trust of other members of the review team.

https://review.openstack.org/#/dashboard/6873
https://review.openstack.org/#/q/owner:6873,n,z
https://review.openstack.org/#/q/reviewer:6873,n,z

Please respond with +1/-1, or any further comments.

Thanks,

-- 
Russell Bryant

___
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

[Russell Bryant]

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Russell Bryant]

On 11/22/2013 12:55 PM, Lorin Hochstein wrote:
> 
> On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell  > wrote:
> 
> 
> Support those of us running production OpenStack clouds needs to be
> one of the major development concerns as people reflect on
> refactoring along with making sure we don't make OpenStack more
> difficult to install/manage/configure.
> 
> 
> To that end, I recommend posting questions like "We're thinking of
> making large change 'X', how will that affect existing OpenStack
> deployments?" to the openstack-operators mailing list. 
> 
> I know there are several OpenStack operators who don't subscribe to
> openstack or openstack-dev lists because of the enormous traffic volume. 

I honestly don't understand why openstack@ and openstack-operators@ are
different lists.  Perhaps openstack@ just needs better use of topic
tagging ...

-- 
Russell Bryant

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

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

[Jeremy Stanley]

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.
-- 
Jeremy Stanley

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

Re: [openstack-dev] How to stage client major releases in Gerrit?

[Jeremy Stanley]

On 2013-11-22 10:34:40 +0100 (+0100), Thierry Carrez wrote:
> It can be created on request by release management members (or
> infra-core team). I /think/ that by default it would get tested against
> master in other branches.

More details at...

https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits >

-- 
Jeremy Stanley

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Maxime Vidori]

That is a fact all client side development is based on javascript, Node allow 
us to easily execute javascript without a browser. Every time we will have a 
reflexion on the client side, Node will show up, what we are doing is just 
delaying something inevitable and wasting our forces in compromises. Node is 
not the best way, but it is the easiest one, what would we do next time, search 
another alternative in python, if it is buggy we will have to maintain it. You 
are right Node is currently fancy, but less is fancy, angular is fancy but they 
provides some ease and that is why we choose them.

- Original Message -
From: "Jordan OMara" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, November 22, 2013 7:22:12 PM
Subject: Re: [openstack-dev] [horizon] Javascript development improvement

On 22/11/13 12:06 -0500, Julie Pichon wrote:
>I don't think Selenium is going away, and efforts have started around
>using it as well for our integration tests [0]. Looking at the current
>AngularJS patch up for review, it is testable without requiring
>NodeJS. 

While the Angular modules are testable in QUnit, it would be a boon to use the
testing patterns common with most Angular projects.  It would make new
developers, familiar with Angular but not Horizon, immediately familiar with the
workflow.

QUnit is acceptable, but karma/jasmine is preferable

> From the initial mailing list discussion [1], my understanding
>is that we're planning on using a specific AngularJS feature, not
>rewriting everything with it. Changing our build system to accommodate
>this seems like getting a bit ahead of ourselves.
>
>[1] 
>http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html

To be clear, we're using a specific feature of Angular (the directive) to
introduce it into the existing Django templates; that's not the only feature of
Angular we're using. There are controllers & services behind the directive, but
using a directive is the cleanest way of integrating these features with the
existing templates.

-- 
Jordan O'Mara 
Red Hat Engineering, Raleigh 

___
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] [Infra] Support for PCI Passthrough

[Jeremy Stanley]

On 2013-11-22 08:59:16 + (+), Tan, Lin wrote:
[...]
> Our module only works on the compute node that enables VT-d and
> contains special PCIs which support the SR-IOV.
> 
> So is it possible to
> 
> 1. setup compute node which enables pci passthrough.
> 
> 2. modify the testing schedule logic allow the pci testing case
> be scheduled to that machine
[...]

If you're asking about our official test infrastructure for the
OpenStack project, I believe this is infeasible for now. We
currently perform testing within generic virtual machines provided
by HPCloud and Rackspace, so the Nova compute nodes we build and
test are already running under virtualization and in turn manage
only paravirtualized QEMU instances.

In the near term, your best bet is to run your own test
infrastructure supporting the hardware features you require and
report advisory results back on proposed changes:

http://ci.openstack.org/third_party.html

For a longer term solution, you may want to consult with the TripleO
project with regards to their bare-metal test plan:

https://wiki.openstack.org/wiki/TripleO/TripleOCloud

-- 
Jeremy Stanley

___
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

[Krishna Raman]

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

> 
> Thank you,
> Eric Windisch
> 
> ___
> 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] [Ironic][Cinder] Attaching Cinder volumes to baremetal instance

[Rohan Kanade]

Hey guys, just starting out with Ironic, had a silly question.

Can we attach bootable or non bootable plain cinder volumes during either
provisioning of the baremetal instance or after provisioning the baremetal
instance?

I have seen a "attach_volume" method in the "LibvirtVolumeDriver" of the
nova baremetal driver. So got curious.

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

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Yathiraj Udupi (yudupi)]

I would definitely like to take part in this discussion and also
contribute where I can.  I was part of the scheduler sessions in the
recent summit along with Debo Dutta, Gary Kotton, and Mike Spreitzer and
we had proposed sessions on smart resource placement, and also the
instance group API work for nova.  We have been discussing this at our
weekly scheduler meetings as well.
I am also in the process of contributing a Solver Scheduler - a
constraints-solver based way of finding optimal resource placements in
openstack. 
In our smart resource placement proposal, we discussed a high level
overview of scheduling considering cross services, and it hints at how the
scheduler should sit outside as a separate service.  But we decided to
start within Nova first.

This work of separating the scheduler is very promising, and I definitely
would like to be involved in this effort.

Thanks,
Yathi. 

‹

On 11/21/13, 12:58 PM, "Robert Collins"  wrote:

>https://etherpad.openstack.org/p/icehouse-external-scheduler
>
>I'm looking for 4-5 folk who have:
> - modest Nova skills
> - time to follow a fairly mechanical (but careful and detailed work
>needed) plan to break the status quo around scheduler extraction
>
>And of course, discussion galore about the idea :)
>
>Cheers,
>Rob
>
>-- 
>Robert Collins 
>Distinguished Technologist
>HP Converged Cloud
>
>___
>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][Oslo] Future of Key Distribution Server, Trusted Messaging

[Mark McLoughlin]

On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:
> Russell Bryant wrote:
> > [...]
> > I'm not thrilled about the prospect of this going into a new project for
> > multiple reasons.
> > 
> >  - Given the priority and how long this has been dragging out, having to
> > wait for a new project to make its way into OpenStack is not very appealing.
> > 
> >  - A new project needs to be able to stand on its own legs.  It needs to
> > have a reasonably sized development team to make it sustainable.  Is
> > this big enough for that?
> 
> Having it in Barbican (and maybe have Barbican join under the identity
> program) would mitigate the second issue. But the first issue stands,
> and I share your concerns.

Yes, I agree. It's disappointing that this change of plans looks like
its going to push out the ability of an OpenStack deployment to be
secured.

If this becomes a Barbican API, then we might be able to get the code
working quickly ... but it will still be some time before Barbican is an
integrated project, and so securing OpenStack will only be possible if
you use this non-integrated project.

Mark.


___
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

[Eric Windisch]

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?

Thank you,
Eric Windisch

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Jordan OMara]

On 22/11/13 12:06 -0500, Julie Pichon wrote:

I don't think Selenium is going away, and efforts have started around
using it as well for our integration tests [0]. Looking at the current
AngularJS patch up for review, it is testable without requiring
NodeJS. 


While the Angular modules are testable in QUnit, it would be a boon to use the
testing patterns common with most Angular projects.  It would make new
developers, familiar with Angular but not Horizon, immediately familiar with the
workflow.

QUnit is acceptable, but karma/jasmine is preferable


From the initial mailing list discussion [1], my understanding
is that we're planning on using a specific AngularJS feature, not
rewriting everything with it. Changing our build system to accommodate
this seems like getting a bit ahead of ourselves.

[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html


To be clear, we're using a specific feature of Angular (the directive) to
introduce it into the existing Django templates; that's not the only feature of
Angular we're using. There are controllers & services behind the directive, but
using a directive is the cleanest way of integrating these features with the
existing templates.

--
Jordan O'Mara 
Red Hat Engineering, Raleigh 


pgpVLkAm0WvI6.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] future fate of nova-network?

[Daniel P. Berrange]

On Fri, Nov 22, 2013 at 12:55:48PM -0500, Lorin Hochstein wrote:
> On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell  wrote:
> 
> >
> > Support those of us running production OpenStack clouds needs to be one of
> > the major development concerns as people reflect on refactoring along with
> > making sure we don't make OpenStack more difficult to
> > install/manage/configure.
> >
> >
> To that end, I recommend posting questions like "We're thinking of making
> large change 'X', how will that affect existing OpenStack deployments?" to
> the openstack-operators mailing list.
> 
> I know there are several OpenStack operators who don't subscribe to
> openstack or openstack-dev lists because of the enormous traffic volume.

That's a good point, I should have asked that list about the proposal
to increase the min required libvirt version too. I've posted to it now...

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

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

[Daniel P. Berrange]

On Wed, Nov 20, 2013 at 04:02:02PM +0100, Ralf Haferkamp wrote:
> On Wed, Nov 20, 2013 at 04:33:22PM +1300, Robert Collins wrote:
> > On 20 November 2013 08:02, Daniel P. Berrange  wrote:
> > > Currently the Nova libvirt driver is declaring that it wants a minimum
> > > of libvirt 0.9.6.
> > ...
> > > If there are other distros I've missed which expect to support deployment
> > > of Icehouse please add them to this list. Hopefully there won't be any
> > > with libvirt software older than Ubuntu 12.04 LTS
> > >
> > >
> > > The reason I'm asking this now, is that we're working to make the libvirt
> > > python module a separate tar.gz that can build with multiple libvirt
> > > versions, and I need to decide how ancient a libvirt we should support
> > > for it.
> > 
> > Fantastic!!!
> > 
> > The Ubuntu cloud archive
> > https://wiki.ubuntu.com/ServerTeam/CloudArchive is how OpenStack is
> > delivered by Canonical for Ubuntu LTS users. So I think you can go
> > with e.g. 0.9.11 or even 0.9.12 depending on what the Suse folk say.
> I think 0.9.11 is fine for us. I am not worried too much about 0.9.12 either
> since openSUSE 12.2 (which has 0.9.11) will reach its EOL soon. I also added
> SLES to the table on:
> https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix

Thanks, it looks like from the libvirt side, we are only going to be
able to provide a standalone  libvirt-python on PyPI that works
back to version 0.9.11.  Prior to 0.9.11 libvirt did not install its
API description, which is a pre-requisite for the python bindings
to build.

Fortunately 0.9.11 lines up with all the distros we've got listed
so far.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Lorin Hochstein]

On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell  wrote:

>
> Support those of us running production OpenStack clouds needs to be one of
> the major development concerns as people reflect on refactoring along with
> making sure we don't make OpenStack more difficult to
> install/manage/configure.
>
>
To that end, I recommend posting questions like "We're thinking of making
large change 'X', how will that affect existing OpenStack deployments?" to
the openstack-operators mailing list.

I know there are several OpenStack operators who don't subscribe to
openstack or openstack-dev lists because of the enormous traffic volume.

Lorin

-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] meaning of resource_id in a meter

[Doug Hellmann]

On Thu, Nov 21, 2013 at 2:37 PM, Gordon Chung  wrote:

>
> > In all cases, these are free string fields. `user_id' and `project_id'
> > map to Keystone _most of the time_,
>
> i'm sort of torn between the two -- which is why i brought it up i guess.
> i like the flexibility of having resource as a free string field but the
> difference between resource and project/user fields is that we can query
> directly on Resources. when we get a Resource, we get a list of associated
> Meters and if we don't set resource_id in a consistent manner, i worry we
> may be losing some relational information between Meters that groupings
> based off consistent resource_id can provide.
>

The tuple (project id, source, resource id) is expected to be unique so
that those values combined with a specific meter provide useful information
about the resource. Beyond that unique constraint, I'm not sure we apply
any rules, although check the SQL schema to make sure the resource id field
isn't a short VARCHAR.

Doug



>
> cheers,
> gordon chung
>
> openstack, ibm software standards
> email: chungg [at] ca.ibm.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] [Oslo] Improving oslo-incubator update.py

[Doug Hellmann]

On Fri, Nov 22, 2013 at 11:24 AM, Duncan Thomas wrote:

> On 22 November 2013 14:59, Ben Nemec  wrote:
>
> > One other thought I had was to add the ability to split one Oslo sync up
> > into multiple commits, either one per module, or even one per Oslo commit
> > for some really large module changes (I'm thinking of the 1000 line db
> sync
> > someone mentioned recently).  It would be more review churn, but at
> least it
> > would keep the changes per review down to a more reasonable level.   I'm
> not
> > positive it would be beneficial, but I thought I'd mention it.
>
> Cinder (often but not always me) tends to reject merges that do more
> that one module at a time, because it makes it far harder to review
> and spot problems, so some from of automation of this would be great.
>

There are times when the commits are related, but in general this seems
like a good practice.

Doug



>
> --
> Duncan Thomas
>
> ___
> 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] future fate of nova-network?

[Tim Bell]

Starting from the existing code also makes migration for production 
environments currently using the code much easier.

Support those of us running production OpenStack clouds needs to be one of the 
major development concerns as people reflect on refactoring along with making 
sure we don't make OpenStack more difficult to install/manage/configure.

Tim

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: 22 November 2013 17:33
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> 
> On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote:
> > On 11/22/2013 11:17 AM, Jonathan Proulx wrote:
> > > To add to the screams of others removing features from nova-network
> > > to achieve parity with neutron is a non starter, and it rather
> > > scares me to hear it suggested.
> >
> > -1 from me too, so everyone can take a deep breath on this.  :-)
> >
> > > Providing feature parity and easy cut over *should have been*
> > > priority
> > > 1 when quantum split out of nova as it was for cinder (which was a
> > > delightful and completely unnoticable transition)
> >
> > +1
> >
> > I think the experience with Neutron provides us some very good insight
> > for future project splits/replacements.  We're working on establishing
> > more clear requirements for project incubation and graduation in the TC.
> >  One note I put down was that we should require that projects stay
> > completely focused on being able to deprecate their replacement before
> > adding *anything* else whenever possible.
> >
> > A good example is the current discussion around a new scheduling
> > service.  There have been lots of big ideas around this.  Robert
> > Collins just started a thread about a proposal to start this project
> > but with a very strict scope of being able to replace nova-scheduler,
> > and *nothing* more until that's completely done.  I like that approach 
> > quite a bit.
> 
> I'd suggest something even stronger. If we want to split out code into a new 
> project, we should always follow the approach used for
> cinder.
> ie the existing fully functional code should be pulled out as is, and work 
> then progress from there. That ensures we'd always have feature
> parity from the very start. Yes, you might have to then do a large amount of 
> refactoring to get to where you want to be, but IMHO that's
> preferrable to starting something from scratch and forgetting to cover 
> existing use cases.
> 
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
> 
> ___
> 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] [Oslo] Improving oslo-incubator update.py

[Doug Hellmann]

On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco  wrote:

> Greetings,
>
> Based on the recent discussion that came out about not having enough
> information in the commit message when syncing oslo-incubator modules,
> I was thinking that besides encouraging people to write better commit
> messages, we could also improve the script we use to sync those
> modules.
>
> Some of the changes that I've been thinking of:
>
>1) Store the commit sha from which the module was copied from.
>Every project using oslo, currently keeps the list of modules it
>is using in `openstack-modules.conf` in a `module` parameter. We
>could store, along with the module name, the sha of the commit it
>was last synced from:
>
>module=log,commit
>
>or
>
>module=log
>log=commit
>

The second form will be easier to manage. Humans edit the module field and
the script will edit the others.



>
>2) Add an 'auto-commit' parameter to the update script that will
>generate a commit message with the short log of the commits where
>the modules being updated were modified. Soemthing like:
>
>Syncing oslo-incubator modules
>
>log.py:
>commit1: short-message
>commit2: short-message
>commit3: short-message
>
>lockutils:
>commit4: short-message
>commit5: short-message
>
> #1 will help with figuring out when was the last time a module was
> updated and what changes have been introduced since then.
>
> #2 won't be the recommended way for writing commit messages. Oslo
> incubator syncs can have different side-effects in every project.
> However, it could be useful for trivial syncs.
>

It looks like #2 would be a good way to start with commit messages, and
just leave it up to the person doing the merge to add the "why" information.

Doug



>
> Thoughts?
>
> 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] [Cinder][Glance] OSLO update

[Doug Hellmann]

On Fri, Nov 22, 2013 at 11:21 AM, Duncan Thomas wrote:

> On 22 November 2013 12:27, Elena Ezhova  wrote:
> > But what if I want to update some module that consists of ten or even
> more
> > files (like rpc or db) and each of these files has quite a long change
> log?
> > In that case the commit message may turn out to be really long even if
> only
> > commit ids and names are included.
>
>
> A message that is too long is definitely a better problem to have than
> a message that is missing important details.
>

If we are talking about merging only part of oslo into a consuming project,
then we can't just keep track of the "last" revision that was merged,
because that won't necessarily include all of the changes. Elena, were you
planning to keep a separate revision for each entry under openstack/common
(not every file, just the files and directories at that level)?


>
> To turn the question round, how can a reviewer review a change that
> includes ten or even more files without any information on what
> changed and why? rpc and db are extremely difficult imports to review,
> and I've found problems in the last two I looked at.
>

Problems in the code, or in the way the code was merged?

Doug



>
> ___
> 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] L3 advanced features blueprint mapping to IETF and IEEE standards

[Carl Baldwin]

Nachi,

I'm sorry to have missed this meeting.  In my jet-lagged state, I
somehow got it on my calendar for last night rather than last Tuesday
night (my local time, MST).  I have an interest in the dynamic routing
area of neutron and I would like to be involved.

Will this meeting be weekly?  I'll go read through the meeting log.

Carl Baldwin

On Thu, Nov 7, 2013 at 11:18 PM, Nachi Ueno  wrote:
> Hi folks
>
> let's use #openstack-meeting on the meetings.
>
> I have also created an etherpad for this discussion
> (If you have any slide, please link to the page)
>
> https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse
>
> Best
> Nachi
>
>
>
> 2013/11/8 Pedro Roque Marques :
>> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m
>> in Japan and 6 a.m CET on the 20th.
>> It is not ideal but i suspect we will have interest in participating from
>> both Europe and Asia.
>> I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP
>> MPLS blueprint) as agenda organizers; please drop us a note if you intend to
>> attend and wether you would like to present something to the group.
>>
>>   Pedro.
>>
>> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober 
>> wrote:
>>
>>
>>
>> From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com]
>> Colin,
>> "The nice thing about standards is that there are so many of them to choose
>> from."
>>
>> For instance, if you take this Internet Draft:
>> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on
>> RFC4364.
>>
>> It has already been implemented as a Neutron plugin via OpenContrail
>> (http://juniper.github.io/contrail-vnc/README.html); With this
>> implementation each OpenStack cluster can be configured as its own
>> Autonomous System.
>>
>> There is a blueprint
>> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
>> that is discussing adding the provisioning of the autonomous system and
>> peering to Neutron.
>>
>> Please note that the work above does interoperate with 4364 using option B.
>> Option C is possible but not that practical (as an operator you probably
>> don't want to expose your internal topology between clusters).
>>
>> If you want to give it a try you can use this devstack fork:
>> https://github.com/dsetia/devstack.
>> You can use it to interoperate with a standard router that implements 4364
>> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.
>>
>> I believe that the work i'm referencing implements interoperability while
>> having very minimal changes to Neutron. It is based on the same concept of
>> neutron virtual network and it hides the BGP/MPLS functionality from the
>> user by translating policies that establish connectivity between virtual
>> networks into RFC 4364 concepts.
>> Please refer to:
>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>>
>> Would it make sense to have an IRC/Web meeting around interoperability with
>> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of
>> work that has already been done there by multiple vendors as well as some
>> carriers.
>>
>> +1  And it should be scheduled and announced a reasonable time in advance
>> developers can plan to participate.
>>
>> --Rocky
>>
>>   Pedro.
>>
>> On Nov 7, 2013, at 12:35 AM, Colin McNamara  wrote:
>>
>> I have a couple concerns that I don’t feel I clearly communicated during the
>> L3 advanced features session. I’d like to take this opportunity to both
>> clearly communicate my thoughts, as well as start a discussion around them.
>>
>>
>> Building to the edge of the "autonomous system"
>>
>> The current state of neutron implementation is functionally the l2 domain
>> and simple l3 services that are part of a larger autonomous system. The
>> routers and switches northbound of the OpenStack networking layer handled
>> the abstraction and integration of the components.
>>
>> Note, I use the term “Autonomous System” to describe more then the notion of
>> BGP AS, but more broadly in the term of a system that is controlled within a
>> common framework and methodology, and integrates with a peer system that
>> doesn’t not share that same scope or method of control
>>
>> These components that composed the autonomous system boundary implement
>> protocols and standards that map into IETF and IEEE standards. The reasoning
>> for this is interoperability. Before vendors utilize IETF for
>> interoperability at this layer, the provider experience was horrible (this
>> was my personal experience in the late 90’s).
>>
>>
>>
>> Wednesdays discussions in the Neutron Design Sessions
>>
>> A couple of the discussions, most notably the extension of l3 functionality
>> fell within the scope of starting the process of extending Neutron with
>> functionality that will result (eventually) in the ability for an OpenStack
>> installation to operate as it’s own Autonomous System.
>>
>> The discussions that occurred to support L3 advanced functi

Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

[Jarret Raim]

On 11/21/13, 7:51 PM, "Jamie Lennox"  wrote:


>So i've a feeling that this was proposed and dismissed once before. I
>don't remember why.
>
>So my concern with barbican is that i'm under the impression that
>barbican was going to be an 'overcloud' service. That's a really bad way
>of putting it, but it is service and user facing and discovered via the
>service catalog. 
>
>This feature will need to be configured at a lower level (runs in
>situations without a token) and so we will need to configure the
>services to point to an IP for the KDS service.

Why would there be a need for token less authentication? My understanding
of the feature is that each service account would have a KDS key
associated with it. This means that each account would need to
authenticate to Keystone before talking to Barbican. Are there service
accounts that don’t have a keystone account?

>
>Is this an expected deployment of barbican (i can't see why not)?

We certainly could enable this if needed. We already create separate uwsgi
processes for the main and admin apis. We could create another one for the
KDS. I’d rather not do that unless we have to though.


Jarret



>
>Jamie
>
>On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote:
>> The Barbican team has been taking a look at the KDS feature and the
>> proposed patch and I think this may be better placed in Barbican rather
>> than Keystone. The patch, from what I can tell, seems to require that a
>> service account create & use a key under its own tenant. In this use
>>case,
>> Barbican can handle the entire exchange and Keystone can just provide
>> auth/auth for the process. This would allow for some great additional
>> features including guaranteed entropy and additional security through
>>the
>> use of HSMs, auditing / logging, etc.
>> 
>> Barbican is pretty far along at this point and it doesn¹t appear to be a
>> huge amount of work to move the patch over as it doesn¹t seem to use any
>> Keystone internals.
>> 
>> What would people think about this approach? We¹re happy to help move
>>the
>> patch over and I¹m certainly happy to merge it as it feels like a good
>> feature for barbican.
>> 
>> 
>> 
>> 
>> Jarret
>> 
>> 
>> 
>> 
>> 
>> 
>> On 11/21/13, 12:55 AM, "Russell Bryant"  wrote:
>> 
>> >Greetings,
>> >
>> >I'd like to check in on the status of this API addition:
>> >
>> >https://review.openstack.org/#/c/40692/
>> >
>> >The last comment is:
>> >
>> >   "propose against stackforge as discussed at summit?"
>> >
>> >I don't see a session about this and from a quick look, don't see notes
>> >related to it in other session etherpads.
>> >
>> >When was this discussed?  Can you summarize it?
>> >
>> >Last I heard, this was just being deferred to be merged early in
>> >Icehouse [1].
>> >
>> >This is blocking one of the most important security features for
>> >OpenStack, IMO (trusted messaging) [2].  We've been talking about it
>>for
>> >years.  Someone has finally made some real progress on it and I feel
>> >like it has been given little to no attention.
>> >
>> >I'm not thrilled about the prospect of this going into a new project
>>for
>> >multiple reasons.
>> >
>> > - Given the priority and how long this has been dragging out, having
>>to
>> >wait for a new project to make its way into OpenStack is not very
>> >appealing.
>> >
>> > - A new project needs to be able to stand on its own legs.  It needs
>>to
>> >have a reasonably sized development team to make it sustainable.  Is
>> >this big enough for that?
>> >
>> >What's the thinking on this?
>> >
>> >[1]
>> 
>>>http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht
>>>ml
>> >[2] https://review.openstack.org/#/c/37913/
>> >
>> >-- 
>> >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

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Julie Pichon]

"Imre Farkas"  wrote:
> On 11/22/2013 02:49 PM, Maxime Vidori wrote:
> >> It seems a bit crazy to me to introduce NodeJS as a dependency just for
> >> the sake of an easy way to run jslint. There are other options
> >> available that run without NodeJS as a dependency.
> >
> > Sadly, the only solutions which try to implement jslint in pure python are
> > in alpha or abandoned. If you have a python library which has the same
> > quality as jslint (which is written by Douglas Crockford himself), I will
> > be glad to take a look at it.
> 
> There's a jslint fork called jshint which is able to run in the browser
> without any node.js dependency.
> 
> I created a POC patch [1] long time ago to demonstrate its capabilities.
> It's integrated with qunit and runs automatically with the horizon test
> suite.

Thanks Imre, this is interesting. Would you mind restoring the patch? If
you don't have time to work on it please indicate so (I don't think it's
possible to pick up a patch if the status is 'Abandoned') and someone else
can look into the test failures.

> The patch also contains a .jshintrc file for the node.js package but you
> can remove it since it's not used by the qunit+jshint test at all.

Sounds good.

Julie

> Imre
> 
> [1] https://review.openstack.org/#/c/41087/

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Julie Pichon]

"Maxime Vidori"  wrote:
> >There is at least one bug open against Ubuntu[1], asking to install
> >python-lesscpy as well, as customers "often" need to re-create or change
> >stylesheets.
> >
> >This would imply nodejs in a production environment, when going back to
> >less.
> 
> As long as the css will be the only one included into the package, we cannot
> run into this issue. If someone wants to modify the less file he could
> compile it and just copy paste the result into the proper directory.

This doesn't sound particularly friendly, I think what Matthias was
getting at is that there are requests from users who want to be able to
modify the CSS directly.

> >It seems a bit crazy to me to introduce NodeJS as a dependency just for
> >the sake of an easy way to run jslint. There are other options
> >available that run without NodeJS as a dependency.
> 
> Sadly, the only solutions which try to implement jslint in pure python are in
> alpha or abandoned. If you have a python library which has the same quality
> as jslint (which is written by Douglas Crockford himself), I will be glad to
> take a look at it.

Sure, I'll look into it. There seems to be also Javascript-based
solutions that could be viable. If anyone has recommendations based on
past experience, please let me know. The patch Imre linked to looks
like a good start!

> >There are more implications to running NodeJS even only for
> >development. It will likely have an impact on our infrastructure as
> >well, since we'll want these checks running on patches up for
> >review. Then if it's there for development it increases the risk it
> >will creep in as a dependency for our runtime.
> 
> That is a good point, but Selenium also provides external dependencies, like
> a browser to run into. I do not really know the infrastructure used by
> jenkins and how we can integrate our solution into, but I do not think it is
> impossible (I have never got any trouble with the installation of node with
> the sources in any distro).

Selenium is already integrated with our Jenkins gate. I don't think it
hurts either to run the tests in an environment similar to what they
need to work in in the end.

> >As for Selenium, are you talking about rewriting our existing Selenium
> >tests in Javascript? If so I am opposed to this. The strength of our
> >community is in Python, if we want to encourage people to write more
> >tests we should make it easy for them to do so.
> 
> Currently we have two Selenium tests in pure python, and all the others are
> running in a page with qUnit, which is a javascript unit testing framework.
> 
> Lastly, we will start using angularjs as a front-end framework, it provides
> an advanced testing framework which allows us to get rid of selenium.

I don't think Selenium is going away, and efforts have started around
using it as well for our integration tests [0]. Looking at the current
AngularJS patch up for review, it is testable without requiring
NodeJS. From the initial mailing list discussion [1], my understanding
is that we're planning on using a specific AngularJS feature, not
rewriting everything with it. Changing our build system to accommodate
this seems like getting a bit ahead of ourselves.

Julie

[0] https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing
[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html

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

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Khanh-Toan Tran]

Dear all,

I'm very interested in this subject as well. Actually there is also a 
discussion of the possibility of an independent scheduler in the mailisg list:
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019518.html

Would it be possible to discuss about this subject in the next Scheduler 
meeting Nov 26th?

Best regards,

Toan

- Original Message - 
From: "Mike Spreitzer"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Friday, November 22, 2013 4:58:46 PM 
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest 
proposal for an external scheduler in our lifetime 

I'm still a newbie here, so can not claim my Nova skills are even "modest". But 
I'd like to track this, if nothing more. 

Thanks, 
Mike 
___ 
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] future fate of nova-network?

[Mike Spreitzer]

"Daniel P. Berrange"  wrote on 11/22/2013 11:32:59 
AM:

> > A good example is the current discussion around a new scheduling
> > service.  There have been lots of big ideas around this.  Robert 
Collins
> > just started a thread about a proposal to start this project but with 
a
> > very strict scope of being able to replace nova-scheduler, and 
*nothing*
> > more until that's completely done.  I like that approach quite a bit.
> 
> I'd suggest something even stronger. If we want to split out code into
> a new project, we should always follow the approach used for cinder.
> ie the existing fully functional code should be pulled out as is, and
> work then progress from there. That ensures we'd always have feature
> parity from the very start. Yes, you might have to then do a large
> amount of refactoring to get to where you want to be, but IMHO that's
> preferrable to starting something from scratch and forgetting to cover
> existing use cases.

I think that is what Robert is saying.

Regards,
Mike___
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

[Krishna Raman]

Reminder: We are meting in about 15 minutes on #openstack-meeting channel.

--Krishna


On Fri, Nov 22, 2013 at 7:53 AM, Krishna Raman  wrote:

>
>
>
> On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell  wrote:
>
>>
>>
>> Can we make sure that the costs for the end users are also considered as
>> part of this ?
>>
>>
>>
>> -  Configuration management will need further modules
>>
>> -  Dashboard confusion as we get multiple tabs
>>
>> -  Accounting, Block Storage, Networking, Orchestration
>> confusion as the concepts diverge
>>
>>
>>
>> Is this really a good idea to create another project considering the
>> needs of the whole openstack community ?
>>
>
> Hi Tim,
>
> We have not made the determination that a new service is necessary yet.
> All the discussion today will be about is to see what the differences are.
> After we have that, we will go back to discuss with Nova team and see if
> the split is even necessary.
>
> --kr
>
>
>>
>>
>> Tim
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2013-11-22 01:50:39 -0800:
> Tim Bell wrote:
> > Can we make sure that the costs for the end users are also considered as
> > part of this ?
> > 
> > -  Configuration management will need further modules
> > -  Dashboard confusion as we get multiple tabs
> > -  Accounting, Block Storage, Networking, Orchestration
> > confusion as the concepts diverge
> > 
> > Is this really a good idea to create another project considering the
> > needs of the whole openstack community ?
> 
> Personally, it will have to prove a really different API and set of use
> cases to justify the cost of a separate project. I'm waiting to see what
> they come up with, but IMHO it's "compute" in both cases. We've seen
> with the libvirt-sandbox discussion that using technology (hypervisor
> vs. container) to draw the line between the use cases is a bit
> over-simplifying the problem.
> 

Agreed, I think it has been over simplified, but that is what you do
when you're not driven by a well understood real use-case, something I
have yet to see from this discussion.

> I don't really want us to create a container service and end up
> implementing the same hypervisor backends than in Nova, just because
> hypervisors can perfectly also be used to serve lightweight
> application-centric workloads. Or the other way around (keep Docker
> support in Nova since you can perfectly run an OS in a container). At
> first glance, extending the Nova API to also cover lightweight
> app-centric use cases would avoid a ton of duplication...
> 

Agreed. There are a few weird things that come to mind though. One of
those is that I imagine users would like to do something like this:

host_id=$(container-thing allocate-host --flavor small  appserver)
db_id=$(container-thing allocate-host --flavor huge dbserver)
app_id=$(container-thing run --host $host_id --image app-image)
proxy_id=$(container-thing run --host $host_id --image proxy-image)
cache_id=$(container-thing run --host $host_id --image cache-image)
db_id=$(container-thing run --host $db_id)

As in, they'd probably like to have VMs spun up and then chopped up
into containers. If this is implemented first inside nova, that may end
up being a rats nest and hard to separate later.  The temptation to use
private API's is really strong. But if it is outside nova, the separation
stays clear and the two can be used without one-another very easily.

> If the main concern is to keep Nova small and manageable, I'd rather rip
> out pieces like nova-network or the scheduler, which are clearly not
> "compute".
> 

Indeed, and those things are under way. :)

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

[openstack-dev] [Solum] Working group on language packs

[Clayton Coleman]

I have updated the language pack (name subject to change) blueprint with the 
outcomes from the face2face meetings, and drafted a specification that captures 
the discussion so far.  The spec is centered around the core idea of 
transitioning base images into deployable images (that can be stored in Nova 
and sent to Glance).  These are *DRAFT* and are intended for public debate.  

https://blueprints.launchpad.net/solum/+spec/lang-pack
https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts

Please take this opportunity to review these documents and offer criticism and 
critique via the ML - I will schedule a follow up deep dive for those who 
expressed interest in participation [1] after US Thanksgiving.

[1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes






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

Re: [openstack-dev] [nova] future fate of nova-network?

[Daniel P. Berrange]

On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote:
> On 11/22/2013 11:17 AM, Jonathan Proulx wrote:
> > To add to the screams of others removing features from nova-network to
> > achieve parity with neutron is a non starter, and it rather scares me
> > to hear it suggested.
> 
> -1 from me too, so everyone can take a deep breath on this.  :-)
> 
> > Providing feature parity and easy cut over *should have been* priority
> > 1 when quantum split out of nova as it was for cinder (which was a
> > delightful and completely unnoticable transition)
> 
> +1
> 
> I think the experience with Neutron provides us some very good insight
> for future project splits/replacements.  We're working on establishing
> more clear requirements for project incubation and graduation in the TC.
>  One note I put down was that we should require that projects stay
> completely focused on being able to deprecate their replacement before
> adding *anything* else whenever possible.
> 
> A good example is the current discussion around a new scheduling
> service.  There have been lots of big ideas around this.  Robert Collins
> just started a thread about a proposal to start this project but with a
> very strict scope of being able to replace nova-scheduler, and *nothing*
> more until that's completely done.  I like that approach quite a bit.

I'd suggest something even stronger. If we want to split out code into
a new project, we should always follow the approach used for cinder.
ie the existing fully functional code should be pulled out as is, and
work then progress from there. That ensures we'd always have feature
parity from the very start. Yes, you might have to then do a large
amount of refactoring to get to where you want to be, but IMHO that's
preferrable to starting something from scratch and forgetting to cover
existing use cases.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Duncan Thomas]

On 22 November 2013 14:59, Ben Nemec  wrote:

> One other thought I had was to add the ability to split one Oslo sync up
> into multiple commits, either one per module, or even one per Oslo commit
> for some really large module changes (I'm thinking of the 1000 line db sync
> someone mentioned recently).  It would be more review churn, but at least it
> would keep the changes per review down to a more reasonable level.   I'm not
> positive it would be beneficial, but I thought I'd mention it.

Cinder (often but not always me) tends to reject merges that do more
that one module at a time, because it makes it far harder to review
and spot problems, so some from of automation of this would be great.

-- 
Duncan Thomas

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Russell Bryant]

On 11/22/2013 11:17 AM, Jonathan Proulx wrote:
> To add to the screams of others removing features from nova-network to
> achieve parity with neutron is a non starter, and it rather scares me
> to hear it suggested.

-1 from me too, so everyone can take a deep breath on this.  :-)

> Providing feature parity and easy cut over *should have been* priority
> 1 when quantum split out of nova as it was for cinder (which was a
> delightful and completely unnoticable transition)

+1

I think the experience with Neutron provides us some very good insight
for future project splits/replacements.  We're working on establishing
more clear requirements for project incubation and graduation in the TC.
 One note I put down was that we should require that projects stay
completely focused on being able to deprecate their replacement before
adding *anything* else whenever possible.

A good example is the current discussion around a new scheduling
service.  There have been lots of big ideas around this.  Robert Collins
just started a thread about a proposal to start this project but with a
very strict scope of being able to replace nova-scheduler, and *nothing*
more until that's completely done.  I like that approach quite a bit.

-- 
Russell Bryant

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

Re: [openstack-dev] [Cinder][Glance] OSLO update

[Duncan Thomas]

On 22 November 2013 12:27, Elena Ezhova  wrote:
> But what if I want to update some module that consists of ten or even more
> files (like rpc or db) and each of these files has quite a long change log?
> In that case the commit message may turn out to be really long even if only
> commit ids and names are included.


A message that is too long is definitely a better problem to have than
a message that is missing important details.

To turn the question round, how can a reviewer review a change that
includes ten or even more files without any information on what
changed and why? rpc and db are extremely difficult imports to review,
and I've found problems in the last two I looked at.

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Jonathan Proulx]

To add to the screams of others removing features from nova-network to
achieve parity with neutron is a non starter, and it rather scares me
to hear it suggested.

I do try not to rant in public, especially about things I'm not
competent to really help fix, but I can't really contain this one any
longer:


As an operator I've moved my cloud neutron already, but while it
provides many advanced features it still really falls down on
providing simple solutions for simple use cases.  Most operators I've
talked to informally hate it for that and don't want to go near it and
for new users, even those with advanced skill sets, neutron causes by
far the most cursing and rage quits I've seen (again just my
subjective observation) on IRC, Twitter, and the mailing lists.

Providing feature parity and easy cut over *should have been* priority
1 when quantum split out of nova as it was for cinder (which was a
delightful and completely unnoticable transition)

We need feature parity and complexity parity with nova-network for the
use cases it covers.  The failure to do so or even have a reasonable
plan to do so is currently the worst thing about openstack.


I do appreciate the work being done on advanced networking features in
neutron, I'm even using some of them, just someone please bring focus
back on the basics.

-Jon

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

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Mike Spreitzer]

I'm still a newbie here, so can not claim my Nova skills are even 
"modest".  But I'd like to track this, if nothing more.

Thanks,
Mike___
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

[Krishna Raman]

On Thu, Nov 21, 2013 at 9:58 AM, 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?
>
>
Will go over the options on the table briefly today. As we discussed during
the design session, it will be important to figure out the delta between
Nova VM API and what is required for containers. After we have the delta,
we can decide on which of those 3 options makes sense.

--kr


>
> >> 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 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 poss

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

[Krishna Raman]

On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell  wrote:

>
>
> Can we make sure that the costs for the end users are also considered as
> part of this ?
>
>
>
> -  Configuration management will need further modules
>
> -  Dashboard confusion as we get multiple tabs
>
> -  Accounting, Block Storage, Networking, Orchestration confusion
> as the concepts diverge
>
>
>
> Is this really a good idea to create another project considering the needs
> of the whole openstack community ?
>

Hi Tim,

We have not made the determination that a new service is necessary yet. All
the discussion today will be about is to see what the differences are.
After we have that, we will go back to discuss with Nova team and see if
the split is even necessary.

--kr


>
>
> Tim
>
>
>
>
>
>
>
> ___
> 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] FreeBSD hypervisor (bhyve) driver

[Russell Bryant]

On 11/22/2013 10:43 AM, Rafał Jaworowski wrote:
> Russell,
> First, thank you for the whiteboard input regarding the blueprint for
> FreeBSD hypervisor nova driver:
> https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node
> 
> We were considering libvirt support for bhyve hypervisor as well, only
> wouldn't want to do this as the first approach for FreeBSD+OpenStack
> integration. We'd rather bring bhyve bindings for libvirt later as
> another integration option.
> 
> For FreeBSD host support a native hypervisor driver is important and
> desired long-term and we would like to have it anyways. Among things
> to consider are the following:
> - libvirt package is additional (non-OpenStack), external dependency
> (maintained in the 'ports' collection, not included in base system),
> while native API (via libvmmapi.so library) is integral part of the
> base system.
> - libvirt license is LGPL, which might be an important aspect for some users.

That's perfectly fine if you want to go that route as a first step.
However, that doesn't mean it's appropriate for merging into Nova.
Unless there are strong technical justifications for why this approach
should be taken, I would probably turn down this driver until you were
able to go the libvirt route.

-- 
Russell Bryant

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

[openstack-dev] FreeBSD hypervisor (bhyve) driver

[Rafał Jaworowski]

Russell,
First, thank you for the whiteboard input regarding the blueprint for
FreeBSD hypervisor nova driver:
https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node

We were considering libvirt support for bhyve hypervisor as well, only
wouldn't want to do this as the first approach for FreeBSD+OpenStack
integration. We'd rather bring bhyve bindings for libvirt later as
another integration option.

For FreeBSD host support a native hypervisor driver is important and
desired long-term and we would like to have it anyways. Among things
to consider are the following:
- libvirt package is additional (non-OpenStack), external dependency
(maintained in the 'ports' collection, not included in base system),
while native API (via libvmmapi.so library) is integral part of the
base system.
- libvirt license is LGPL, which might be an important aspect for some users.

Rafal

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

[openstack-dev] [Neutron][LBaaS] L7 rules design

[Eugene Nikanorov]

Hi Avishay, lbaas folks,

I've reviewed the wiki and have some questions/suggestions:

1) Looks like L7Policy is lacking 'name' attribute in it's description.
However i see little benefit of having a name for this object
2) lbaas-related neutron client commands start with lb-, please fix this.
3) How does L7Policy specifies relation of vip and pool?
4) How default pool will be associated with the vip? Will it be a l7 rule
of special kind?
It is not quite clear what does mean associating vip with pool with policy
if each rule in the policy contains 'SelectedPool' attribute.
5) what is 'action'? What other actions except SELECT_POOL can be?

In fact my suggestion will be slightly different:
- Instead of having L7Policy which i believe serves only to rules grouping,
we introduce VipPoolAssociation as follows:

VipPoolAssociation
 id,
 vip_id,
 pool_id,
 default - boolean flag for default pool for the vip

L7Rule then will have vippoolassociation_id (it's better to shorten the
attr name) just like it has policy_id in your proposal. L7Rule doesn't need
SelectedPool attribute since once it attached to VipPoolAssociation, the
rule then points to the pool with pool_id of that association.
In other words, VipPoolAssociation is almost the same as L7Policy but named
closer to it's primary goal of associating vips and pools.

I would also suggest to add add/delete-rule operation for the association.

What do you think?

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Imre Farkas]

On 11/22/2013 02:49 PM, Maxime Vidori wrote:

It seems a bit crazy to me to introduce NodeJS as a dependency just for
the sake of an easy way to run jslint. There are other options
available that run without NodeJS as a dependency.


Sadly, the only solutions which try to implement jslint in pure python are in 
alpha or abandoned. If you have a python library which has the same quality as 
jslint (which is written by Douglas Crockford himself), I will be glad to take 
a look at it.


There's a jslint fork called jshint which is able to run in the browser 
without any node.js dependency.


I created a POC patch [1] long time ago to demonstrate its capabilities. 
It's integrated with qunit and runs automatically with the horizon test 
suite.


The patch also contains a .jshintrc file for the node.js package but you 
can remove it since it's not used by the qunit+jshint test at all.


Imre

[1] https://review.openstack.org/#/c/41087/


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

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Ben Nemec]

On 2013-11-22 03:11, Flavio Percoco wrote:

Greetings,

Based on the recent discussion that came out about not having enough
information in the commit message when syncing oslo-incubator modules,
I was thinking that besides encouraging people to write better commit
messages, we could also improve the script we use to sync those
modules.

Some of the changes that I've been thinking of:

   1) Store the commit sha from which the module was copied from.
   Every project using oslo, currently keeps the list of modules it
   is using in `openstack-modules.conf` in a `module` parameter. We
   could store, along with the module name, the sha of the commit it
   was last synced from:

   module=log,commit

   or

   module=log
   log=commit

   2) Add an 'auto-commit' parameter to the update script that will
   generate a commit message with the short log of the commits where
   the modules being updated were modified. Soemthing like:

   Syncing oslo-incubator modules

   log.py:
   commit1: short-message
   commit2: short-message
   commit3: short-message

   lockutils:
   commit4: short-message
   commit5: short-message

#1 will help with figuring out when was the last time a module was
updated and what changes have been introduced since then.

#2 won't be the recommended way for writing commit messages. Oslo
incubator syncs can have different side-effects in every project.
However, it could be useful for trivial syncs.

Thoughts?


+1.  I've been thinking along the same lines.  I always try to include 
the git oneline output in my Oslo syncs anyway, but it's not trivial to 
figure out the appropriate ones to include so doing it automatically 
would be fantastic.


One other thought I had was to add the ability to split one Oslo sync up 
into multiple commits, either one per module, or even one per Oslo 
commit for some really large module changes (I'm thinking of the 1000 
line db sync someone mentioned recently).  It would be more review 
churn, but at least it would keep the changes per review down to a more 
reasonable level.   I'm not positive it would be beneficial, but I 
thought I'd mention it.


-Ben

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

Re: [openstack-dev] How to stage client major releases in Gerrit?

[Dolph Mathews]

On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez wrote:

> Robert Collins wrote:
> > I don't understand why branches would be needed here *if* the breaking
> > changes don't impact any supported release of OpenStack.
>
> Right -- the trick is what does "supported" mean in that case.
>
> When the client libraries were first established as separate
> deliverables, they came up with a blanket statement that the latest
> version could always be used with *any* version of openstack you may
> have. The idea being, if some public cloud was still stuck in pre-diablo
> times, you could still use the same library to address both this public
> cloud and the one which was 2 weeks behind Havana HEAD.
>

I'm curious about the historical circumstance of this requirement -- were
the services supported "master, minus two releases" at the time?

We're not testing more than two stable releases against the latest clients
in CI today, so I find it odd that we still bother with this claim, without
demonstrating that it's true.


>
> --
> Thierry Carrez (ttx)
>
> ___
> 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

Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting on Thursday, 21

[Eugene Nikanorov]

Meeting logs from the latest meeting:


Minutes:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.txt
Log:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.log.html

Thanks,
Eugene.



On Thu, Nov 21, 2013 at 3:04 PM, Eugene Nikanorov
wrote:

> Meeting reminder!
> Today, 14-00 UTC, #openstack-meeting
>
> Agenda for the meeting:
> 1) Announcements
> 2) Progress with qa and third-party testing
> 3) Feature design discussions
>
> Thanks,
> Eugene.
>
>
> On Tue, Nov 19, 2013 at 12:30 PM, Eugene Nikanorov <
> enikano...@mirantis.com> wrote:
>
>> Hi folks,
>>
>> Let's meet on #openstack-meeting on Thrsday, 21, at 14-00 UTC
>> We'll discuss current progress and design of some of proposed features.
>>
>> Thanks,
>> Eugene.
>>
>>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Javascript development improvement

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/22/2013 02:19 PM, Sascha Peilicke wrote:
> On Friday 22 November 2013 13:13:29 Matthias Runge wrote:
>> On 11/21/2013 01:55 PM, Jiri Tomasek wrote:
>>> Hi,
>>> 
>>> 
>>> Regarding less, I don't really care what compiler we use as
>>> long as it works. And if we need to provide uncompiled less for
>>> production, then let's use Lesscpy.
>> 
>> There is at least one bug open against Ubuntu[1], asking to
>> install python-lesscpy as well, as customers "often" need to
>> re-create or change stylesheets.
> 
> I asked chuck months ago to package it :-)
> 
AFAIK it is packaged already.

I was not speaking about lesscpy (which might raised your attention
here), but about less compiler in general (or other tools, probably
useful for maintainers/customizers tasks).

Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSj2qnAAoJEOnz8qQwcaIWeZcH/jC7RUTUPD+fa9lG92YmYuoU
XiG9xivEVtOrhHlqigb43A6rGVkq7IPEVCnf3nMCwxtVHcoLdy3Pq8QPqFEI9LNv
GrjfoKoFy8R71AuAWVblTWgMxJ/4ffHDny4na4FDiqn02vMCucYvsPAKsNU6m3fU
SaFC1pH0f7/LeVpa13IJuM7XlEKpbPNwKObFfxalIen9ISP+9iQeWlczAr96Z198
tjdPg+2CeXM4Dh+jklYjOQHB5ITxFI3U4ehXCDB+aJS5HnGulL4gF1120zsBScG7
fsTI67n+r0mhMo9rIQdVVJFmK/wpHXzKQi8bsBJctk+hJ1UG9sHNjRJVmmq9SWY=
=7B9B
-END PGP SIGNATURE-

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Sean Dague]

On 11/22/2013 04:47 AM, Daniel P. Berrange wrote:
> On Fri, Nov 22, 2013 at 11:25:51AM +, John Garbutt wrote:
 On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant  wrote:
>> In particular, has there been a decision made about whether it will
>> definitely be deprecated in some (as yet unspecified) future release, or
>> whether it will continue to be supported for the foreseeable future?
>
> We want to deprecate it.  There are some things blocking moving forward
> with this.  In short:
>
> 1) Feature parity (primarily something that satisfies performance and HA
> requirements addressed by nova-network in multi-host mode)
>
> 2) Testing and quality parity.  The status of Neutron testing in the
> gate is far inferior to the testing done against nova-network.
>
> I'm personally more worried about #2 than #1 at this point.
>
> A major issue is that very few people actually stepped up and agreed to
> help with #2 at the summit [2].  Only one person signed up to work on
> tempest issues.  Nobody signed up to help with grenade.  If this doesn't
> happen, nova-network can't be deprecated, IMO.
>
> If significant progress isn't made ASAP this cycle, and ideally by
> mid-cycle so we can change directions if necessary, then we'll have to
> discuss what next step to take.  That may include un-freezing
> nova-network so that various people holding on to enhancements to
> nova-network can start submitting them back.  It's a last resort, but I
> consider it on the table.
>>
>> Another approach to help with (1) is in Icehouse we remove the
>> features from nova-network that neutron does not implement. We have
>> warned about deprecation for a good few releases, so its almost OK.
> 
> We deprecated it on the basis that users would be able to do a upgrade
> to new release providing something that was feature equivalent.
> 
> We didn't deprecate it on the basis that we were going to remove the
> feature and provide no upgrade path, leaving users screwed.
> 
> So I don't consider removing features from nova-network to be an
> acceptable approach, until they exist in Neutron or something else
> that users can upgrade their existing deployments to.

100% agree. -1 on removing nova-network features that people may very
well be using in production, successfully.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Javascript development improvement

[Maxime Vidori]

>There is at least one bug open against Ubuntu[1], asking to install
>python-lesscpy as well, as customers "often" need to re-create or change
>stylesheets.
>
>This would imply nodejs in a production environment, when going back to
>less.

As long as the css will be the only one included into the package, we cannot 
run into this issue. If someone wants to modify the less file he could compile 
it and just copy paste the result into the proper directory.

>It seems a bit crazy to me to introduce NodeJS as a dependency just for
>the sake of an easy way to run jslint. There are other options
>available that run without NodeJS as a dependency.

Sadly, the only solutions which try to implement jslint in pure python are in 
alpha or abandoned. If you have a python library which has the same quality as 
jslint (which is written by Douglas Crockford himself), I will be glad to take 
a look at it.

>There are more implications to running NodeJS even only for
>development. It will likely have an impact on our infrastructure as
>well, since we'll want these checks running on patches up for
>review. Then if it's there for development it increases the risk it
>will creep in as a dependency for our runtime.

That is a good point, but Selenium also provides external dependencies, like a 
browser to run into. I do not really know the infrastructure used by jenkins 
and how we can integrate our solution into, but I do not think it is impossible 
(I have never got any trouble with the installation of node with the sources in 
any distro). 

>As for Selenium, are you talking about rewriting our existing Selenium
>tests in Javascript? If so I am opposed to this. The strength of our
>community is in Python, if we want to encourage people to write more
>tests we should make it easy for them to do so.

Currently we have two Selenium tests in pure python, and all the others are 
running in a page with qUnit, which is a javascript unit testing framework.

Lastly, we will start using angularjs as a front-end framework, it provides an 
advanced testing framework which allows us to get rid of selenium.

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Sascha Peilicke]

On Friday 22 November 2013 13:13:29 Matthias Runge wrote:
> On 11/21/2013 01:55 PM, Jiri Tomasek wrote:
> > Hi,
> > 
> > 
> > Regarding less, I don't really care what compiler we use as long as it
> > works. And if we need to provide uncompiled less for production, then
> > let's use Lesscpy.
> 
> There is at least one bug open against Ubuntu[1], asking to install
> python-lesscpy as well, as customers "often" need to re-create or change
> stylesheets.

I asked chuck months ago to package it :-) 

> This would imply nodejs in a production environment, when going back to
> less.
> 
> Just naming the n word here, makes people bite, for whatever reason ;-)
> 
> Matthias
> 
> [1]
> https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

signature.asc
Description: This is a digitally signed message part.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] future fate of nova-network?

[Daniel P. Berrange]

On Fri, Nov 22, 2013 at 11:25:51AM +, John Garbutt wrote:
> >> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant  wrote:
>  In particular, has there been a decision made about whether it will
>  definitely be deprecated in some (as yet unspecified) future release, or
>  whether it will continue to be supported for the foreseeable future?
> >>>
> >>> We want to deprecate it.  There are some things blocking moving forward
> >>> with this.  In short:
> >>>
> >>> 1) Feature parity (primarily something that satisfies performance and HA
> >>> requirements addressed by nova-network in multi-host mode)
> >>>
> >>> 2) Testing and quality parity.  The status of Neutron testing in the
> >>> gate is far inferior to the testing done against nova-network.
> >>>
> >>> I'm personally more worried about #2 than #1 at this point.
> >>>
> >>> A major issue is that very few people actually stepped up and agreed to
> >>> help with #2 at the summit [2].  Only one person signed up to work on
> >>> tempest issues.  Nobody signed up to help with grenade.  If this doesn't
> >>> happen, nova-network can't be deprecated, IMO.
> >>>
> >>> If significant progress isn't made ASAP this cycle, and ideally by
> >>> mid-cycle so we can change directions if necessary, then we'll have to
> >>> discuss what next step to take.  That may include un-freezing
> >>> nova-network so that various people holding on to enhancements to
> >>> nova-network can start submitting them back.  It's a last resort, but I
> >>> consider it on the table.
> 
> Another approach to help with (1) is in Icehouse we remove the
> features from nova-network that neutron does not implement. We have
> warned about deprecation for a good few releases, so its almost OK.

We deprecated it on the basis that users would be able to do a upgrade
to new release providing something that was feature equivalent.

We didn't deprecate it on the basis that we were going to remove the
feature and provide no upgrade path, leaving users screwed.

So I don't consider removing features from nova-network to be an
acceptable approach, until they exist in Neutron or something else
that users can upgrade their existing deployments to.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [nova] future fate of nova-network?

[Soren Hansen]

2013/11/22 John Garbutt :
> Another approach to help with (1) is in Icehouse we remove the
> features from nova-network that neutron does not implement. We have
> warned about deprecation for a good few releases, so its almost OK.

You want to motivate Neutron developers by punishing users of
nova-network who are probably already nervous that the rug will be
pulled out from under them? I'm about a -1,000,000 on that one.

-- 
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer  | http://www.openstack.org/

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

Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing "request identification"

[Mitsuru Kanabuchi]

On Tue, 19 Nov 2013 12:03:57 -0500
Adam Young  wrote:

> On 11/19/2013 08:21 AM, Dolph Mathews wrote:
> > Related BP:
> >
> >   Create a unified request identifier
> > https://blueprints.launchpad.net/nova/+spec/cross-service-request-id

I interested in cross-service-request-id because it has potential to
solve several problem.

I believe that API-retry would improve reliability of processing
especially in HA environment.
But it has fundamental problem what POST methods isn't idempotent.
In my understand, currently, a lot of OpenStack API caller doesn't
API-retry to avoid problem when do POST and response was lost.

For reference:
  https://wiki.openstack.org/wiki/Support-retry-with-idempotency

I think id has to be something passed in by the client is essential
part of to solve that problem.
And I recently found that cross-service-request-id could realize
that objective. It is really nice idea.

I understand, currently cross-service-request-id's objective is for
debugging. It is very useful.
In addition, I think that cross-service-request-id can use for
ensuring POST idempotent.
If the service received known cross-service-request-id, the service
just return existence resource-id to clients.
And the service don't create new resource.

I understand it's need several considerations.
(Please refer the thread of
 [Heat]Updated summit etherpad: API-retry-with-idempotency)

However, basically it's good function for reliability.
What do you think about it?


> And we have discussed  workplans as well, which would be data to be 
> carried along with the request id
> 
> https://blueprints.launchpad.net/keystone/+spec/delegation-workplans
> https://etherpad.openstack.org/keystone_workplans
> 
> >
> > On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa  > > wrote:
> >
> > Hi stackers!!
> >
> > I'd like to ask for your opinions about my idea of identifying
> > request.
> >
> > Challenges
> > ==
> >
> > We have no way to know the final result of an API request.
> > Indeed we can continuously get the status of allocated resources,
> > but this is just resource status, not request status.
> >
> > It doesn't matter so much for manual operations.
> > But it does for automated clients like heat.
> > We need request-oriented-status and it should be disclosed to clients.
> >
> > Literally, we need to address two items for it.
> >  1. how to identify request from clients
> >  2. how to disclose status of request to clients
> >
> > Note that this email includes only 1 for initiating the discussion.
> > Also, bp:instance-tasks-api[0] should include both two items above.
> >
> > Proposal: introducing "request identification"
> > =
> >
> > I'd like to introduce "request identification", which is disclosed
> > to clients.
> > There are two characteristics:
> >
> >  - "request identification" is unique ID for each request
> >so that we can identify tell a specific request from others.
> >  - "request identification" is available for clients
> >so that we can enable any after-request-operations like check,
> > retry[1] or cancel[2].
> >(of course we need to add more logic for check/retry/cancel,
> > but I'm pretty sure that indentifying request is the starting
> > point for these features)
> >
> > In my understandings, main objections should be 'who should
> > generate and maintain such IDs?'.
> >
> > How to implement "request identification"
> > =
> >
> > There are several options at least. (See also recent discussion at
> > openstack-dev[3])
> >
> > 1. Enable user to provide his/her own "request identification"
> > within API request.
> >This should be the simplest way. But providing id from outside
> > looks hard to be accepted.
> >For example, Idempotency for OpenStack API[4].
> >Or instance-tasks-api enable to user to put his/her own
> > "request identification".
> >
> > 2. Use correlation_id in oslo as "request identification".
> >correlation_id looks similar concept of "request indentification",
> >but correlation_id in nova was already rejected[5].
> >
> > 3. Enable keystone to generate "request identification" (we can
> > call it 'request-token', for example).
> >Before sending actual API request to nova-api, client sends a
> > request to keystone to get 'request-token'.
> >
> >
> > -2
> >
> >Then client sends an actual API request with 'request-token'.
> >Nova-api will consult it to keystone whether it was really
> > generated.
> >Sounds like a auth-token generated by keystone, differences are:
> >  [lifecycle] auth-token is used for multiple API requests
> > before it expires,
> > 'request-token' is used for only single API 

Re: [openstack-dev] [Cinder][Glance] OSLO update

[Elena Ezhova]

But what if I want to update some module that consists of ten or even more
files (like rpc or db) and each of these files has quite a long change log?
In that case the commit message may turn out to be really long even if only
commit ids and names are included.


On Wed, Nov 20, 2013 at 12:37 PM, Elena Ezhova  wrote:

>
> 20.11.2013, 06:18, "John Griffith" :
>
> On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin 
> wrote:
>
> >  On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote:
> >>  Random OSLO updates with no list of what changed, what got fixed etc
> >>  are unlikely to get review attention - doing such a review is
> >>  extremely difficult. I was -2ing them and asking for more info, but
> >>  they keep popping up. I'm really not sure what the best way of
> >>  updating from OSLO is, but this isn't it.
> >  Best practice is to include a list of changes being synced, for example:
> >
> >https://review.openstack.org/54660
> >
> >  Every so often, we throw around ideas for automating the generation of
> >  this changes list - e.g. cinder would have the oslo-incubator commit ID
> >  for each module stored in a file in git to tell us when it was last
> >  synced.
> >
> >  Mark.
> >
> >  _
>>
>> __
>> >  OpenStack-dev mailing list
>> >  OpenStack-dev@lists.openstack.org
>> >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> Been away on vacation so I'm afraid I'm a bit late on this... but;
>>
>> I think the point Duncan is bringing up here is that there are some
>> VERY large and significant patches coming from OSLO pulls.  The DB
>> patch in particular being over 1K lines of code to a critical portion
>> of the code is a bit unnerving to try and do a review on.  I realize
>> that there's a level of trust that goes with the work that's done in
>> OSLO and synchronizing those changes across the projects, but I think
>> a few key concerns here are:
>>
>> 1. Doing huge pulls from OSLO like the DB patch here are nearly
>> impossible to thoroughly review and test.  Over time we learn a lot
>> about real usage scenarios and the database and tweak things as we go,
>> so seeing a patch set like this show up is always a bit unnerving and
>> frankly nobody is overly excited to review it.
>>
>> 2. Given a certain level of *trust* for the work that folks do on the
>> OSLO side in submitting these patches and new additions, I think some
>> of the responsibility on the review of the code falls on the OSLO
>> team.  That being said there is still the issue of how these changes
>> will impact projects *other* than Nova which I think is sometimes
>> neglected.  There have been a number of OSLO synchs pushed to Cinder
>> that fail gating jobs, some get fixed, some get abandoned, but in
>> either case it shows that there wasn't any testing done with projects
>> other than Nova (PLEASE note, I'm not referring to this particular
>> round of patches or calling any patch set out, just stating a
>> historical fact).
>>
>> 3. We need better documentation in commit messages explaining why the
>> changes are necessary and what they do for us.  I'm sorry but in my
>> opinion the answer "it's the latest in OSLO and Nova already has it"
>> is not enough of an answer in my opinion.  The patches mentioned in
>> this thread in my opinion met the minimum requirements because they at
>> least reference the OSLO commit which is great.  In addition I'd like
>> to see something to address any discovered issues or testing done with
>> the specific projects these changes are being synced to.
>>
>> I'm in no way saying I don't want Cinder to play nice with the common
>> code or to get in line with the way other projects do things but I am
>> saying that I think we have a ways to go in terms of better
>> communication here and in terms of OSLO code actually keeping in mind
>> the entire OpenStack eco-system as opposed to just changes that were
>> needed/updated in Nova.  Cinder in particular went through some pretty
>> massive DB re-factoring and changes during Havana and there was a lot
>> of really good work there but it didn't come without a cost and the
>> benefits were examined and weighed pretty heavily.  I also think that
>> some times the indirection introduced by adding some of the
>> openstack.common code is unnecessary and in some cases makes things
>> more difficult than they should be.
>>
>> I'm just not sure that we always do a very good ROI investigation or
>> risk assessment on changes, and that opinion applies to ALL changes in
>> OpenStack projects, not OSLO specific or anything else.
>>
>> All of that being said, a couple of those syncs on the list are
>> outdated.  We should start by doing a fresh pull for these and if
>> possible add some better documentation in the commit messages as to
>> the justification for the patches that would be great.  We can take a
>> closer look at the changes and the history behind them and try to get
>> some review progress m

Re: [openstack-dev] [horizon] Javascript development improvement

[Matthias Runge]

On 11/22/2013 11:10 AM, Maxime Vidori wrote:
> I will start reading documentation in order to integrate node in development, 
> we also want to integrate its testing into the existing ones. I think a 
> blueprint will be necessary.
> 
Since it was such a pain to get rid of nodejs, I'd love to see other
options here.

Matthias

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Matthias Runge]

On 11/21/2013 01:55 PM, Jiri Tomasek wrote:
> Hi,

> 
> Regarding less, I don't really care what compiler we use as long as it
> works. And if we need to provide uncompiled less for production, then
> let's use Lesscpy.
> 

There is at least one bug open against Ubuntu[1], asking to install
python-lesscpy as well, as customers "often" need to re-create or change
stylesheets.

This would imply nodejs in a production environment, when going back to
less.

Just naming the n word here, makes people bite, for whatever reason ;-)

Matthias

[1]
https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276

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

Re: [openstack-dev] [Swift] Server Side Encryption

[Michael Factor]

Gregory Holt  wrote on 20/11/2013 05:46:41 PM:

> From: Gregory Holt 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , 
> Date: 20/11/2013 05:49 PM
> Subject: Re: [openstack-dev] [Swift]  Server Side Encryption
> 
> On Nov 20, 2013, at 5:26 AM, David Hadas  wrote:
> 
> > 
> > Hi all,
> > 
> > We created a wiki page discussing the addition of software side 
encryption
> > to Swift:
> > "The general scheme is to create a swift proxy middleware that will 
encrypt
> > and sign the object data during PUT and check the signature + decrypt 
it
> > during GET. The target is to create two domains - the user domain 
between
> > the client and the middleware where the data is decrypted and the 
system
> > domain between the middleware and the data at rest (on the device) 
where
> > the data is encrypted.
> > Design goals include: (1) Extend swift as necessary but without 
changing
> > existing swift behaviors and APIs; (2) Support encrypting data 
incoming
> > from unchanged clients"
> > 
> > See:  https://wiki.openstack.org/wiki/Swift/server-side-enc
> > We would like to invite feedback.
> 
> I'll bite, though I'm fairly sure I already know the response. Why 
> all this complexity for what amounts to just encrypting data on disk
> in case the disk is stolen, lost, or reused? That's the only 
> protection I see this providing and it would seem it could be 
> achieved with a single cluster key stored only on the Swift proxy 
> servers. All the rest seems like gyrations that provide no true 
> additional benefit. If a client actually cares about having their 
> data encrypted, they should encrypt it themselves and only they 
> would keep the key.
> 

A couple of reasons: 
-- improve re-keying by having a hierarchy 
-- finer grain control on encryption, e.g., per account (the objective is 
not just to protect against disks walking away). 
No argument, best security is client side encryption.  This said, there 
seems to be a need for tenant-controlled, server side encryption, based 
both upon what is offered by other services and discussions I have had 
with users.

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

Re: [openstack-dev] [horizon] Javascript development improvement

[Julie Pichon]

"Maxime Vidori"  wrote:
> Hi all, I know it is pretty annoying but I have to resurrect this subject.
> 
> With the integration of Angularjs into Horizon we will encounter a lot of
> issues with javascript. I ask you to reconsider to bring back Nodejs as a
> development platform. I am not talking about production, we are all agree
> that Node is not ready for production, and we do not want it as a backend.
> But the facts are that we need a lot of its features, which will increase
> the tests and the development. Currently, we do not have any javascript code
> quality: jslint is a great tool and can be used easily into node. Angularjs
> also provides end-to-end testing based on nodejs again, testing is important
> especially if we start to put more logic into JS. Selenium is used just to
> run qUnit tests, we can bring back these tests into node and have a clean
> unified testing platform. Tests will be easier to perform.

It seems a bit crazy to me to introduce NodeJS as a dependency just for
the sake of an easy way to run jslint. There are other options
available that run without NodeJS as a dependency.

There are more implications to running NodeJS even only for
development. It will likely have an impact on our infrastructure as
well, since we'll want these checks running on patches up for
review. Then if it's there for development it increases the risk it
will creep in as a dependency for our runtime.

As for Selenium, are you talking about rewriting our existing Selenium
tests in Javascript? If so I am opposed to this. The strength of our
community is in Python, if we want to encourage people to write more
tests we should make it easy for them to do so.

I think you bring up great points, we do need to control our Javascript
quality better especially as we bring in more of it into our
codebase. But, style checks, CSS, and unit testing, shouldn't require
NodeJS.

Julie
 
> Finally, (do not punch me in the face) lessc which is used for bootstrap is
> completely integrated into it. I am afraid that modern javascript
> development can not be perform without this tool.
> 
> Regards
> 
> Maxime Vidori
> 

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

Re: [openstack-dev] [Nova] V3 API Review Checklist and style guide

[John Garbutt]

On 19 November 2013 11:40, Christopher Yeoh  wrote:
> I've updated the Nova review check list with some details for reviewing V3
> API changesets and started a bit of a style guide for the API.
>
> Checklist:
> https://wiki.openstack.org/w/index.php?title=ReviewChecklist#Nova_Review_Checklist

Looks good, but should we mention what we can change after Icehouse,
when we bump the extension version.
Obviously, that detail should also go in the docs.

I wonder if we should rename all the core extensions to start with
"os-" for consistency?
Makes it easier to expand/contact what is in "core" at a later date
without changing the API format.

> Style Guide: https://wiki.openstack.org/wiki/Nova/APIStyleGuide

Awesome. Only thing I see missing is a list of the error codes we use,
and how we use them.

John

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

Re: [openstack-dev] [nova] future fate of nova-network?

[John Garbutt]

>> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant  wrote:
 In particular, has there been a decision made about whether it will
 definitely be deprecated in some (as yet unspecified) future release, or
 whether it will continue to be supported for the foreseeable future?
>>>
>>> We want to deprecate it.  There are some things blocking moving forward
>>> with this.  In short:
>>>
>>> 1) Feature parity (primarily something that satisfies performance and HA
>>> requirements addressed by nova-network in multi-host mode)
>>>
>>> 2) Testing and quality parity.  The status of Neutron testing in the
>>> gate is far inferior to the testing done against nova-network.
>>>
>>> I'm personally more worried about #2 than #1 at this point.
>>>
>>> A major issue is that very few people actually stepped up and agreed to
>>> help with #2 at the summit [2].  Only one person signed up to work on
>>> tempest issues.  Nobody signed up to help with grenade.  If this doesn't
>>> happen, nova-network can't be deprecated, IMO.
>>>
>>> If significant progress isn't made ASAP this cycle, and ideally by
>>> mid-cycle so we can change directions if necessary, then we'll have to
>>> discuss what next step to take.  That may include un-freezing
>>> nova-network so that various people holding on to enhancements to
>>> nova-network can start submitting them back.  It's a last resort, but I
>>> consider it on the table.

Another approach to help with (1) is in Icehouse we remove the
features from nova-network that neutron does not implement. We have
warned about deprecation for a good few releases, so its almost OK.

But that somewhat assumes (2) is still going well.

John

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

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Gary Kotton]

On 11/22/13 12:16 PM, "Soren Hansen"  wrote:

>I'd very much like to take part in the discussions. Depending on the
>outcome of said discussion, I may or may not want to participate in
>the implementation :)
>
>Soren Hansen |
>https://urldefense.proofpoint.com/v1/url?u=http://linux2go.dk/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=pr4FBldPmZvECJD7jpPfjv0XLo1P3PPXDRd3dhn56k0%3D%0A&s=2dba15816537ae5
>61ef54f0548fd0da0c5ce37fce819acc4c056134590c40cef
>Ubuntu Developer |
>https://urldefense.proofpoint.com/v1/url?u=http://www.ubuntu.com/&k=oIvRg1
>%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq
>8%3D%0A&m=pr4FBldPmZvECJD7jpPfjv0XLo1P3PPXDRd3dhn56k0%3D%0A&s=462ef9df3aed
>afde406b7d73ed571630344691b79c9809f86084557f7ce303c3
>OpenStack Developer  |
>https://urldefense.proofpoint.com/v1/url?u=http://www.openstack.org/&k=oIv
>Rg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFx
>PEq8%3D%0A&m=pr4FBldPmZvECJD7jpPfjv0XLo1P3PPXDRd3dhn56k0%3D%0A&s=1c8236fed
>c4e15ca9c3d4ff1b970f41648ce6c639dc3d99becabcc6a7158a138
>
>
>2013/11/21 Robert Collins :
>> 
>>https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org
>>/p/icehouse-external-scheduler&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0p
>>xTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=pr4FBldPmZvECJD7jpPfjv0
>>XLo1P3PPXDRd3dhn56k0%3D%0A&s=c0f64e4db8aa810d1a8412fc40fafa260d8ad43d8428
>>b2aaa254e98ed6273947
>>
>> I'm looking for 4-5 folk who have:
>>  - modest Nova skills
>>  - time to follow a fairly mechanical (but careful and detailed work
>> needed) plan to break the status quo around scheduler extraction

I would be happy to take part. But prior I think that we need to iron out
a number of issues:
1. Will this be a new service that has an API, for example will Nova be
able to register a host and provide the host statisticsŠ.
2. How will the various components interact with the scheduler - same as
today - that is RPC? Or a REST API? The latter is a real concern due to
problems we have seen with the interactions of nova and other services
3. How will current developments fit into this model?

All in all I think that it is a very good and healthy idea. I have a
number of reservations - these are mainly regarding the implementation and
the service definition.

Basically I like the approach of just getting heads down and doing it, but
prior to that I think that we just need to understand the scope and mainly
define the interfaces and how they can used/abused and consumed. It may be
a very good topic to discuss at the up and coming scheduler meeting - this
may be in the middle of the night for Robert. If so then maybe we can
schedule another time.

Please note that this is scheduling and not orchestration. That is also
something that we need to resolve.

Thanks
Gary

>>
>> And of course, discussion galore about the idea :)
>>
>> Cheers,
>> Rob
>>
>> --
>> Robert Collins 
>> Distinguished Technologist
>> HP Converged Cloud
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
>>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
>>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=pr4FBldPmZvECJD7jp
>>Pfjv0XLo1P3PPXDRd3dhn56k0%3D%0A&s=8bfc07a9380a0bcae8430b746a543267b2823b1
>>205ebb0f8000341b0ea5b80f6
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=pr4FBldPmZvECJD7jpPfj
>v0XLo1P3PPXDRd3dhn56k0%3D%0A&s=8bfc07a9380a0bcae8430b746a543267b2823b1205e
>bb0f8000341b0ea5b80f6


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

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Soren Hansen]

I'd very much like to take part in the discussions. Depending on the
outcome of said discussion, I may or may not want to participate in
the implementation :)

Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer  | http://www.openstack.org/


2013/11/21 Robert Collins :
> https://etherpad.openstack.org/p/icehouse-external-scheduler
>
> I'm looking for 4-5 folk who have:
>  - modest Nova skills
>  - time to follow a fairly mechanical (but careful and detailed work
> needed) plan to break the status quo around scheduler extraction
>
> And of course, discussion galore about the idea :)
>
> Cheers,
> Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> 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] [horizon] Javascript development improvement

[Maxime Vidori]

I will start reading documentation in order to integrate node in development, 
we also want to integrate its testing into the existing ones. I think a 
blueprint will be necessary.

- Original Message -
From: "Jiri Tomasek" 
To: openstack-dev@lists.openstack.org
Sent: Thursday, November 21, 2013 1:55:48 PM
Subject: Re: [openstack-dev] [horizon] Javascript development improvement

Hi,

I also don't see an issue with using nodejs in Horizon development 
environment. Is the problem in Django not differentiating the 
development and production environments by default?
Could the problem be resolved by having two different environments with 
the two requirements files etc. similar as Rails does?

Regarding less, I don't really care what compiler we use as long as it 
works. And if we need to provide uncompiled less for production, then 
let's use Lesscpy.

Jirka

On 11/21/2013 09:21 AM, Ladislav Smola wrote:
> Hello,
>
> as long as node won't be Production dependency, it shouldn't be a 
> problem, right? I give +1 to that
>
> Regards
> Ladislav
>
> On 11/20/2013 05:01 PM, Maxime Vidori wrote:
>> Hi all, I know it is pretty annoying but I have to resurrect this 
>> subject.
>>
>> With the integration of Angularjs into Horizon we will encounter a 
>> lot of issues with javascript. I ask you to reconsider to bring back 
>> Nodejs as a development platform. I am not talking about production, 
>> we are all agree that Node is not ready for production, and we do not 
>> want it as a backend. But the facts are that we need a lot of its 
>> features, which will increase the tests and the development. 
>> Currently, we do not have any javascript code quality: jslint is a 
>> great tool and can be used easily into node. Angularjs also provides 
>> end-to-end testing based on nodejs again, testing is important 
>> especially if we start to put more logic into JS. Selenium is used 
>> just to run qUnit tests, we can bring back these tests into node and 
>> have a clean unified testing platform. Tests will be easier to perform.
>>
>> Finally, (do not punch me in the face) lessc which is used for 
>> bootstrap is completely integrated into it. I am afraid that modern 
>> javascript development can not be perform without this tool.
>>
>> Regards
>>
>> Maxime Vidori
>>
>>
>> ___
>> 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] Search Project - summit follow up

[Oleg Gelbukh]

Dmitri,

If you intend to make this middleware generic and reusable between
different OpenStack services, your best shot, to my understanding, will be
to propose a new library in oslo-incubator.

--
Best regards,
Oleg Gelbukh


On Fri, Nov 22, 2013 at 4:05 AM, Dmitri Zimin(e) | StackStorm <
d...@stackstorm.com> wrote:

>
> On Wed, Nov 20, 2013 at 2:11 PM, Dolph Mathews wrote:
>
>>
>> On Wed, Nov 20, 2013 at 1:06 PM, Dmitri Zimin(e) | StackStorm <
>> d...@stackstorm.com> wrote:
>>
>>> Thanks Terry for highlighting this:
>>>
>>> Yes, tenant isolation is the must. It's not reflected in the prototype -
>>> it queries Solr directly; but the proper implementation will go through the
>>> query API service, where ACL will be applied.
>>>
>>> UX folks are welcome to comment on expected queries.
>>>
>>> I think the key benefit of cross-resource index over querying DBs is
>>> that it saves the clients from implementing complex queries case by case,
>>> leaving flexibility to the user.
>>>
>>
>> I question the need for this service, as this service **should** very
>> much be dependent on the clients for this functionality. Expecting to query
>> backends directly must be a misunderstanding somewhere... Start with a
>> specification for filtering across all services and advocate for it on both
>> existing and new APIs.
>>
>
>
> Dolph, thanks for the suggestion: we will begin drafting the API on the
> wiki.
>
> Just to be clear: this is not filtering. Existing filtering APIs are
> [getting] sufficient. This is a full text search, which doesn't exist yet.
>
> SWIFT is now considering Search API, ideologically similar, but limited to
> Object Storage metadata [1]. Search middleware can make it generic and
> extensible. And yes, middleware may be a better term, as this is not a
> "service" like nova or cinder, but a layer on top.
>
> Do we need to clarify where search middleware shall live?
> Or do we question wether there is the need for search functionality?
>
> What else shall we do to make the discussion forward?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/019014.html
>
>
>
>>> -- Dmitri.
>>>
>>>
>>>
>>>
>>> On Wed, Nov 20, 2013 at 2:27 AM, Thierry Carrez 
>>> wrote:
>>>
 Dmitri Zimin(e) | StackStorm wrote:
 > Hi Stackers,
 >
 > The project Search is a service providing fast full-text search for
 > resources across OpenStack services.
 > [...]

 At first glance this looks slightly scary from a security / tenant
 isolation perspective. Most search results would be extremely
 user-specific (and leaking data from one user to another would be
 catastrophic), so the benefits of indexing (vs. querying DB) would be
 very limited ?

 --
 Thierry Carrez (ttx)

 ___
 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
>>>
>>>
>>
>>
>> --
>>
>> -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

Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

[Alex Glikson]

Great initiative!
I would certainly be interested taking part in this -- although I wouldn't 
necessary claim to be among "people with the know-how to design and 
implement it well". For sure this is going to be a painful but exciting 
process.


Regards,
Alex




From:   Robert Collins 
To: OpenStack Development Mailing List 
, 
Date:   21/11/2013 11:00 PM
Subject:[openstack-dev] [Nova][Schduler] Volunteers wanted for a 
modest proposal for an external scheduler in our lifetime



https://etherpad.openstack.org/p/icehouse-external-scheduler

I'm looking for 4-5 folk who have:
 - modest Nova skills
 - time to follow a fairly mechanical (but careful and detailed work
needed) plan to break the status quo around scheduler extraction

And of course, discussion galore about the idea :)

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
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][Oslo] Future of Key Distribution Server, Trusted Messaging

[Thierry Carrez]

Russell Bryant wrote:
> [...]
> I'm not thrilled about the prospect of this going into a new project for
> multiple reasons.
> 
>  - Given the priority and how long this has been dragging out, having to
> wait for a new project to make its way into OpenStack is not very appealing.
> 
>  - A new project needs to be able to stand on its own legs.  It needs to
> have a reasonably sized development team to make it sustainable.  Is
> this big enough for that?

Having it in Barbican (and maybe have Barbican join under the identity
program) would mitigate the second issue. But the first issue stands,
and I share your concerns.

-- 
Thierry Carrez (ttx)

___
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

[Thierry Carrez]

Tim Bell wrote:
> Can we make sure that the costs for the end users are also considered as
> part of this ?
> 
> -  Configuration management will need further modules
> -  Dashboard confusion as we get multiple tabs
> -  Accounting, Block Storage, Networking, Orchestration
> confusion as the concepts diverge
> 
> Is this really a good idea to create another project considering the
> needs of the whole openstack community ?

Personally, it will have to prove a really different API and set of use
cases to justify the cost of a separate project. I'm waiting to see what
they come up with, but IMHO it's "compute" in both cases. We've seen
with the libvirt-sandbox discussion that using technology (hypervisor
vs. container) to draw the line between the use cases is a bit
over-simplifying the problem.

I don't really want us to create a container service and end up
implementing the same hypervisor backends than in Nova, just because
hypervisors can perfectly also be used to serve lightweight
application-centric workloads. Or the other way around (keep Docker
support in Nova since you can perfectly run an OS in a container). At
first glance, extending the Nova API to also cover lightweight
app-centric use cases would avoid a ton of duplication...

If the main concern is to keep Nova small and manageable, I'd rather rip
out pieces like nova-network or the scheduler, which are clearly not
"compute".

-- 
Thierry Carrez (ttx)

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