[openstack-dev] OpenStack-dev Digest, Vol 19, Issue 66
Alok Mohindra
alok.mohindra at gmail.com
Mon Nov 25 19:06:08 UTC 2013
unsubscribe
--Alok
On Fri, Nov 22, 2013 at 12:03 PM, <openstack-dev-request at lists.openstack.org
> wrote:
> Send OpenStack-dev mailing list submissions to
> openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
> openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [horizon] Javascript development improvement (Matthias Runge)
> 2. Re: [horizon] Javascript development improvement (Matthias Runge)
> 3. Re: [Cinder][Glance] OSLO update (Elena Ezhova)
> 4. Re: [nova][heat][[keystone] RFC: introducing "request
> identification" (Mitsuru Kanabuchi)
> 5. Re: [nova] future fate of nova-network? (Soren Hansen)
> 6. Re: [nova] future fate of nova-network? (Daniel P. Berrange)
> 7. Re: [horizon] Javascript development improvement (Sascha Peilicke)
> 8. Re: [horizon] Javascript development improvement (Maxime Vidori)
> 9. Re: [nova] future fate of nova-network? (Sean Dague)
> 10. Re: [horizon] Javascript development improvement (Matthias Runge)
> 11. Re: [Neutron][LBaaS] Subteam meeting on Thursday, 21
> (Eugene Nikanorov)
> 12. Re: How to stage client major releases in Gerrit? (Dolph Mathews)
> 13. Re: [Oslo] Improving oslo-incubator update.py (Ben Nemec)
> 14. Re: [horizon] Javascript development improvement (Imre Farkas)
> 15. [Neutron][LBaaS] L7 rules design (Eugene Nikanorov)
> 16. FreeBSD hypervisor (bhyve) driver (Rafa? Jaworowski)
> 17. Re: FreeBSD hypervisor (bhyve) driver (Russell Bryant)
> 18. Re: Introducing the new OpenStack service for Containers
> (Krishna Raman)
> 19. Re: Introducing the new OpenStack service for Containers
> (Krishna Raman)
> 20. Re: [Nova][Schduler] Volunteers wanted for a modest proposal
> for an external scheduler in our lifetime (Mike Spreitzer)
> 21. Re: [nova] future fate of nova-network? (Jonathan Proulx)
> 22. Re: [Cinder][Glance] OSLO update (Duncan Thomas)
> 23. Re: [nova] future fate of nova-network? (Russell Bryant)
> 24. Re: [Oslo] Improving oslo-incubator update.py (Duncan Thomas)
> 25. Re: [nova] future fate of nova-network? (Daniel P. Berrange)
> 26. [Solum] Working group on language packs (Clayton Coleman)
> 27. Re: Introducing the new OpenStack service for Containers
> (Clint Byrum)
> 28. Re: Introducing the new OpenStack service for Containers
> (Krishna Raman)
> 29. Re: [nova] future fate of nova-network? (Mike Spreitzer)
> 30. Re: [Nova][Schduler] Volunteers wanted for a modest proposal
> for an external scheduler in our lifetime (Khanh-Toan Tran)
> 31. Re: [horizon] Javascript development improvement (Julie Pichon)
> 32. Re: [Keystone][Oslo] Future of Key Distribution Server,
> Trusted Messaging (Jarret Raim)
> 33. Re: [horizon] Javascript development improvement (Julie Pichon)
> 34. Re: L3 advanced features blueprint mapping to IETF and IEEE
> standards (Carl Baldwin)
> 35. Re: [Cinder][Glance] OSLO update (Doug Hellmann)
> 36. Re: [nova] future fate of nova-network? (Tim Bell)
> 37. Re: [Oslo] Improving oslo-incubator update.py (Doug Hellmann)
> 38. Re: [Oslo] Improving oslo-incubator update.py (Doug Hellmann)
> 39. Re: [Ceilometer] meaning of resource_id in a meter (Doug Hellmann)
> 40. Re: [nova] future fate of nova-network? (Lorin Hochstein)
> 41. Re: RFC: Potential to increase min required libvirt version
> to 0.9.11 ? (Daniel P. Berrange)
> 42. Re: [nova] future fate of nova-network? (Daniel P. Berrange)
> 43. Re: [horizon] Javascript development improvement (Jordan OMara)
> 44. Re: Introducing the new OpenStack service for Containers
> (Eric Windisch)
> 45. Re: [Keystone][Oslo] Future of Key Distribution Server,
> Trusted Messaging (Mark McLoughlin)
> 46. Re: [Nova][Schduler] Volunteers wanted for a modest proposal
> for an external scheduler in our lifetime (Yathiraj Udupi (yudupi))
> 47. [Ironic][Cinder] Attaching Cinder volumes to baremetal
> instance (Rohan Kanade)
> 48. Re: Introducing the new OpenStack service for Containers
> (Krishna Raman)
> 49. Re: [Nova] [Infra] Support for PCI Passthrough (Jeremy Stanley)
> 50. Re: [horizon] Javascript development improvement (Maxime Vidori)
> 51. Re: How to stage client major releases in Gerrit? (Jeremy Stanley)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Nov 2013 13:13:29 +0100
> From: Matthias Runge <mrunge at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID: <528F4A69.40302 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 22 Nov 2013 13:14:50 +0100
> From: Matthias Runge <mrunge at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID: <528F4ABA.1080109 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 22 Nov 2013 16:27:17 +0400
> From: Elena Ezhova <eezhova at mirantis.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Cinder][Glance] OSLO update
> Message-ID:
> <
> CAFZxAhgXrF1iEf_3wAOrQB2WX3aK5PcA0jCyD0MhVPSHOr2M5g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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 <eezhova at mirantis.com>
> wrote:
>
> >
> > 20.11.2013, 06:18, "John Griffith" <john.griffith at solidfire.com>:
> >
> > On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin <markmc at redhat.com>
> > wrote:
> >
> > > On Mon, 2013-11-18 at 17:24 +0000, 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 at 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 made here. Mark mentioned some good ideas
> >> regarding capturing commit ID's from synchronization pulls and I'd
> >> like to look into that a bit as well.
> >>
> >> Thanks,
> >> John
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > I see now that updating OSLO is a far more complex issue than it may seem
> > from the first sight.
> > But I would really like to do my best to make it look acceptable and
> > possible to review.
> >
> > It seems everybody agrees that commit messages should have change logs of
> > the updated files.
> > It can be done by writing a shell script that will generate this logs by
> > simply executing a git log command.
> > But the problem is how to get the initial version of the file that is
> > being updated.
> >
> > As Mark McLoughlin said, it may be a good idea to store OSLO commit-ids
> > for each module in some file.
> > This file will have to be changed every time an update is performed which
> > implies changing update.py
> > in oslo-incubator. The the shell script will just have to fetch a
> > change-id from this file.
> >
> > I will try to write the script and generate logs, but I'm not sure about
> > how can I put all these logs in
> > a commit message because one patch usually changes more than one file and
> > each file may have
> > quite a long log.
> >
> > So I would really appreciate any comments or pieces of advice.
> >
> > Thanks,
> > Elena
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/9c60c258/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 22 Nov 2013 21:30:20 +0900
> From: Mitsuru Kanabuchi <kanabuchi.mitsuru at po.ntts.co.jp>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing
> "request identification"
> Message-ID: <20131122213020.8b80d3a0acf30ad7f452916f at po.ntts.co.jp>
> Content-Type: text/plain; charset=US-ASCII
>
>
> On Tue, 19 Nov 2013 12:03:57 -0500
> Adam Young <ayoung at redhat.com> 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 <harubelle at gmail.com
> > > <mailto:harubelle at gmail.com>> 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 request.
> > > [reusing] if the same 'request-token' was specified twice or
> > > more times,
> > > nova-api simply returns 20x (works like client token in
> > > AWS[6]).
> > > Keystone needs to maintain 'request-tokens' until they
> expire.
> > > For backward compatibility, actual API request without
> > > 'request-token' should work as before.
> > > We can consider several options for uniqueness of
> 'request-token':
> > > uuid, any string with uniqueness per tennant, etc.
> > >
> > > IMO, since adding new implementation to Keystone is a little bit
> > > hard work,
> > > so implement of 1 is reasonable for me, just idea.
> > >
> > > Any comments will be appreciated.
> > >
> > > Sincerely, Haruka Tanizawa
> > >
> > > [0] https://blueprints.launchpad.net/nova/+spec/instance-tasks-api
> > > [1] https://wiki.openstack.org/wiki/Support-retry-with-idempotency
> > > [2] https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume
> > > [3]
> > >
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09023.html
> > > [4]
> > >
> https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token
> > > [5] https://review.openstack.org/#/c/29480/
> > > [6]
> > >
> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Run_Instance_Idempotency.html
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > <mailto:OpenStack-dev at lists.openstack.org>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > >
> > > --
> > >
> > > -Dolph
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --------------------
> Mitsuru Kanabuchi
> NTT Software Corporation
> E-Mail : kanabuchi.mitsuru at po.ntts.co.jp
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 22 Nov 2013 13:36:12 +0100
> From: Soren Hansen <soren at linux2go.dk>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID:
> <
> CAPFUtkbro-o-xdB7u2dgctM4trvQE6uXAmQyN9AyACidYhywZQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2013/11/22 John Garbutt <john at johngarbutt.com>:
> > 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/
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 22 Nov 2013 12:47:19 +0000
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID: <20131122124719.GD16339 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Nov 22, 2013 at 11:25:51AM +0000, John Garbutt wrote:
> > >> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant <rbryant at redhat.com>
> 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:|
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 22 Nov 2013 14:19:35 +0100
> From: Sascha Peilicke <speilicke at suse.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID: <11379465.E1ltjE6RFd at bort.suse.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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 at 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)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 198 bytes
> Desc: This is a digitally signed message part.
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/1012f23e/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 8
> Date: Fri, 22 Nov 2013 14:49:47 +0100 (CET)
> From: Maxime Vidori <maxime.vidori at enovance.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID:
> <1003254746.1659898.1385128187231.JavaMail.root at enovance.com>
> Content-Type: text/plain; charset=utf-8
>
> >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.
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 22 Nov 2013 05:58:11 -0800
> From: Sean Dague <sean at dague.net>
> To: "Daniel P. Berrange" <berrange at redhat.com>, "OpenStack
> Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID: <528F62F3.2090903 at dague.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 11/22/2013 04:47 AM, Daniel P. Berrange wrote:
> > On Fri, Nov 22, 2013 at 11:25:51AM +0000, John Garbutt wrote:
> >>>> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant <rbryant at redhat.com>
> 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
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 482 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/6644230e/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 10
> Date: Fri, 22 Nov 2013 15:31:03 +0100
> From: Matthias Runge <mrunge at redhat.com>
> To: Sascha Peilicke <speilicke at suse.com>,
> openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID: <528F6AA7.2000704 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----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-----
>
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 22 Nov 2013 18:41:44 +0400
> From: Eugene Nikanorov <enikanorov at mirantis.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting on
> Thursday, 21
> Message-ID:
> <
> CAJfiwORT9eLVy7c++Uv5CTWi3vn3ZnVYiu6OxOAWZR-b3W45xg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> <enikanorov at mirantis.com>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 <
> > enikanorov at 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.
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/45ff3779/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Fri, 22 Nov 2013 08:57:53 -0600
> From: Dolph Mathews <dolph.mathews at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] How to stage client major releases in
> Gerrit?
> Message-ID:
> <CAC=h7gU-rLwT6iYb=8iUYPJZdDu+uROoqYsQCoRxh0=
> HtUyiyQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez <thierry at openstack.org
> >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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
>
> -Dolph
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/e497e0d3/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Fri, 22 Nov 2013 08:59:31 -0600
> From: Ben Nemec <openstack at nemebean.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
> Message-ID: <7c5c8991205d2233cdcbe85a7f15b72b at localhost>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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
>
>
>
> ------------------------------
>
> Message: 14
> Date: Fri, 22 Nov 2013 16:08:53 +0100
> From: Imre Farkas <ifarkas at redhat.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID: <528F7385.5020208 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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/
>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Fri, 22 Nov 2013 19:23:43 +0400
> From: Eugene Nikanorov <enikanorov at mirantis.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Neutron][LBaaS] L7 rules design
> Message-ID:
> <CAJfiwOQ_=
> i6myrDPCAsN-Xha1toUvRZR7YGFby3HYsj75jaKAw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/4fc1ad2c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 16
> Date: Fri, 22 Nov 2013 16:43:40 +0100
> From: Rafa? Jaworowski <raj at semihalf.com>
> To: rbryant <rbryant at redhat.com>, openstack-dev at lists.openstack.org
> Cc: Micha? Dubiel <md at semihalf.com>
> Subject: [openstack-dev] FreeBSD hypervisor (bhyve) driver
> Message-ID:
> <CA+gdeqdNzqsn_8yfRV_=
> iYUXB_TP-HVHuizWFaQkMaUve3PZKA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
>
> ------------------------------
>
> Message: 17
> Date: Fri, 22 Nov 2013 10:46:19 -0500
> From: Russell Bryant <rbryant at redhat.com>
> To: Rafa? Jaworowski <raj at semihalf.com>,
> openstack-dev at lists.openstack.org
> Cc: Micha? Dubiel <md at semihalf.com>
> Subject: Re: [openstack-dev] FreeBSD hypervisor (bhyve) driver
> Message-ID: <528F7C4B.7040904 at redhat.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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
>
>
>
> ------------------------------
>
> Message: 18
> Date: Fri, 22 Nov 2013 07:52:00 -0800
> From: Krishna Raman <kraman at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Introducing the new OpenStack service for
> Containers
> Message-ID:
> <
> CAG+5PoV4XAMoJY4URQHKCmKQ8fjkbpWehCXUyvarHgj48B1TuQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Nov 21, 2013 at 9:58 AM, Sam Alba <sam.alba at gmail.com> wrote:
>
> > On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman <kraman at gmail.com> wrote:
> > >
> > > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba <sam.alba at gmail.com> 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 <
> chuck.short at canonical.com
> > >
> > >> 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 <kraman at gmail.com>
> > wrote:
> > >> >>
> > >> >>
> > >> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant <rbryant at redhat.com>
> > wrote:
> > >> >>
> > >> >> On 11/18/2013 06:30 PM, Dan Smith wrote:
> > >> >>
> > >> >> Not having been at the summit (maybe the next one), could somebody
> > >> >> give a really short explanation as to why it needs to be a separate
> > >> >> service? It sounds like it should fit within the Nova area. It is,
> > >> >> after all, just another hypervisor type, or so it seems.
> > >> >>
> > >> >>
> > >> >> But it's not just another hypervisor. If all you want from your
> > >> >> containers is lightweight VMs, then nova is a reasonable place to
> put
> > >> >> that (and it's there right now). If, however, you want to expose
> the
> > >> >> complex and flexible attributes of a container, such as being able
> to
> > >> >> overlap filesystems, have fine-grained control over what is shared
> > with
> > >> >> the host OS, look at the processes within a container, etc, then
> nova
> > >> >> ends up needing quite a bit of change to support that.
> > >> >>
> > >> >> I think the overwhelming majority of folks in the room, after
> > >> >> discussing
> > >> >> it, agreed that Nova is infrastructure and containers is more of a
> > >> >> platform thing. Making it a separate service lets us define a
> > mechanism
> > >> >> to manage these that makes much more sense than treating them like
> > VMs.
> > >> >> Using Nova to deploy VMs that run this service is the right
> approach,
> > >> >> IMHO. Clayton put it very well, I think:
> > >> >>
> > >> >> If the thing you want to deploy has a kernel, then you need Nova.
> If
> > >> >> your thing runs on a kernel, you want $new_service_name.
> > >> >>
> > >> >> I agree.
> > >> >>
> > >> >> Note that this is just another service under the compute project
> (or
> > >> >> program, or whatever the correct terminology is this week).
> > >> >>
> > >> >>
> > >> >> The Compute program is correct. That is established terminology as
> > >> >> defined by the TC in the last cycle.
> > >> >>
> > >> >> So while
> > >> >> distinct from Nova in terms of code, development should be tightly
> > >> >> integrated until (and if at some point) it doesn't make sense.
> > >> >>
> > >> >>
> > >> >> And it may share a whole bunch of the code.
> > >> >>
> > >> >> Another way to put this: The API requirements people have for
> > >> >> containers include a number of features considered outside of the
> > >> >> current scope of Nova (short version: Nova's scope stops before
> going
> > >> >> *inside* the servers it creates, except file injection, which we
> plan
> > >> >> to
> > >> >> remove anyway). That presents a problem. A new service is one
> > >> >> possible
> > >> >> solution.
> > >> >>
> > >> >> My view of the outcome of the session was not "it *will* be a new
> > >> >> service". Instead, it was, "we *think* it should be a new service,
> > but
> > >> >> let's do some more investigation to decide for sure".
> > >> >>
> > >> >> The action item from the session was to go off and come up with a
> > >> >> proposal for what a new service would look like. In particular, we
> > >> >> needed a proposal for what the API would look like. With that in
> > hand,
> > >> >> we need to come back and ask the question again of whether a new
> > >> >> service
> > >> >> is the right answer.
> > >> >>
> > >> >> I see 3 possible solutions here:
> > >> >>
> > >> >> 1) Expand the scope of Nova to include all of the things people
> want
> > to
> > >> >> be able to do with containers.
> > >> >>
> > >> >> This is my least favorite option. Nova is already really big.
> We've
> > >> >> worked to split things out (Networking, Block Storage, Images) to
> > keep
> > >> >> it under control. I don't think a significant increase in scope
> is a
> > >> >> smart move for Nova's future.
> > >> >>
> > >> >> 2) Declare containers as explicitly out of scope and start a new
> > >> >> project
> > >> >> with its own API.
> > >> >>
> > >> >> That is what is being proposed here.
> > >> >>
> > >> >> 3) Some middle ground that is a variation of #2. Consider Ironic.
> > The
> > >> >> idea is that Nova's API will still be used for basic provisioning,
> > >> >> which
> > >> >> Nova will implement by talking to Ironic. However, there are a lot
> > of
> > >> >> baremetal management things that don't fit in Nova at all, and
> those
> > >> >> only exist in Ironic's API.
> > >> >>
> > >> >> I wanted to mention this option for completeness, but I don't
> > actually
> > >> >> think it's the right choice here. With Ironic you have a physical
> > >> >> resource (managed by Ironic), and then instances of an image
> running
> > on
> > >> >> these physical resources (managed by Nova).
> > >> >>
> > >> >> With containers, there's a similar line. You have instances of
> > >> >> containers (managed either by Nova or the new service) running on
> > >> >> servers (managed by Nova). I think there is a good line for
> > separating
> > >> >> concerns, with a container service on top of Nova.
> > >> >>
> > >> >>
> > >> >> Let's ask ourselves: How much overlap is there between the current
> > >> >> compute API and a proposed containers API? Effectively, what's the
> > >> >> diff? How much do we expect this diff to change in the coming
> years?
> > >> >>
> > >> >> The current diff demonstrates a significant clash with the current
> > >> >> scope
> > >> >> of Nova. I also expect a lot of innovation around containers in
> the
> > >> >> next few years, which will result in wanting to do new cool things
> in
> > >> >> the API. I feel that all of this justifies a new API service to
> best
> > >> >> position ourselves for the long term.
> > >> >>
> > >> >>
> > >> >> +1
> > >> >>
> > >> >> We need to come up with the API first before we decide if this is a
> > new
> > >> >> service or just something that
> > >> >> needs to be added to Nova,
> > >> >>
> > >> >> How about we have all interested parties meet on IRC or conf. call
> > and
> > >> >> discuss the suggested REST API,
> > >> >> open questions and architecture.
> > >> >>
> > >> >> If you are interested please add your name to the participant list
> on
> > >> >> https://etherpad.openstack.org/p/containers-service.
> > >> >>
> > >> >> I have also set up a doodle poll at
> > http://doodle.com/w7y5qcdvq9i36757
> > >> >> to
> > >> >> gather a times when a majority
> > >> >> of us are available to discuss on IRC.
> > >> >>
> > >> >> --
> > >> >> Krishna Raman
> > >> >>
> > >> >> PS: Sorry if you see this email twice. I am having some issues with
> > >> >> list
> > >> >> subscription.
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Russell Bryant
> > >> >>
> > >> >> _______________________________________________
> > >> >> OpenStack-dev mailing list
> > >> >> OpenStack-dev at lists.openstack.org
> > >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> >>
> > >> >>
> > >> >>
> > >> >> _______________________________________________
> > >> >> OpenStack-dev mailing list
> > >> >> OpenStack-dev at lists.openstack.org
> > >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> >>
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > OpenStack-dev mailing list
> > >> > OpenStack-dev at lists.openstack.org
> > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> @sam_alba
> > >>
> > >> _______________________________________________
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> >
> > --
> > @sam_alba
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/cf266bfb/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 19
> Date: Fri, 22 Nov 2013 07:53:31 -0800
> From: Krishna Raman <kraman at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Introducing the new OpenStack service for
> Containers
> Message-ID:
> <
> CAG+5PoV28ZM_t790mK8yja3VqK8+qmyLNqnYkY02NNiMOq2y7w at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell <Tim.Bell at cern.ch> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/4bc1b438/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 20
> Date: Fri, 22 Nov 2013 10:58:46 -0500
> From: Mike Spreitzer <mspreitz at us.ibm.com>
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a
> modest proposal for an external scheduler in our lifetime
> Message-ID:
> <
> OF2D54E8FB.F2526DFE-ON85257C2B.00578C0A-85257C2B.0057C750 at us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/188326aa/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 21
> Date: Fri, 22 Nov 2013 11:17:13 -0500
> From: Jonathan Proulx <jon at jonproulx.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID:
> <CABZB-sj6K15Ei0xBZnHxim=
> AeG_Cx0kaTsuADaBxCykH3Nyz0Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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:
>
> <rant>
> 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.
> </rant>
>
> 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
>
>
>
> ------------------------------
>
> Message: 22
> Date: Fri, 22 Nov 2013 16:21:50 +0000
> From: Duncan Thomas <duncan.thomas at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Cinder][Glance] OSLO update
> Message-ID:
> <CAOyZ2aHXe2S6F1s5HApWJA40jeV+cnUvphEA1KA2FEBfAy=_
> ZQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 22 November 2013 12:27, Elena Ezhova <eezhova at mirantis.com> 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.
>
>
>
> ------------------------------
>
> Message: 23
> Date: Fri, 22 Nov 2013 11:24:18 -0500
> From: Russell Bryant <rbryant at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID: <528F8532.3000400 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
>
> ------------------------------
>
> Message: 24
> Date: Fri, 22 Nov 2013 16:24:23 +0000
> From: Duncan Thomas <duncan.thomas at gmail.com>
> To: openstack at nemebean.com, "OpenStack Development Mailing List (not
> for usage questions)" <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
> Message-ID:
> <
> CAOyZ2aEaUrzTNGeoxT9yejbxqKfvxaDmsfRuf+1HBSKN7fcNGQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 22 November 2013 14:59, Ben Nemec <openstack at nemebean.com> 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
>
>
>
> ------------------------------
>
> Message: 25
> Date: Fri, 22 Nov 2013 16:32:59 +0000
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID: <20131122163259.GH16339 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> 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:|
>
>
>
> ------------------------------
>
> Message: 26
> Date: Fri, 22 Nov 2013 11:34:37 -0500 (EST)
> From: Clayton Coleman <ccoleman at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Solum] Working group on language packs
> Message-ID:
> <1788852399.27667197.1385138077079.JavaMail.root at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 27
> Date: Fri, 22 Nov 2013 08:47:13 -0800
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Introducing the new OpenStack service for
> Containers
> Message-ID: <1385137957-sup-2694 at clint-HP>
> Content-Type: text/plain; charset=UTF-8
>
> 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. :)
>
>
>
> ------------------------------
>
> Message: 28
> Date: Fri, 22 Nov 2013 08:49:09 -0800
> From: Krishna Raman <kraman at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Introducing the new OpenStack service for
> Containers
> Message-ID:
> <
> CAG+5PoXFzadya2xk8_1PX8sXOWuSQzfGWCLyp8JP0BWJ-_+7xw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Reminder: We are meting in about 15 minutes on #openstack-meeting channel.
>
> --Krishna
>
>
> On Fri, Nov 22, 2013 at 7:53 AM, Krishna Raman <kraman at gmail.com> wrote:
>
> >
> >
> >
> > On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell <Tim.Bell at cern.ch> 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 at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/3ad1b0ee/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 29
> Date: Fri, 22 Nov 2013 11:53:39 -0500
> From: Mike Spreitzer <mspreitz at us.ibm.com>
> To: "Daniel P. Berrange" <berrange at redhat.com>, "OpenStack Development
> Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID:
> <
> OF2A8C740E.C19403E9-ON85257C2B.005CBA5D-85257C2B.005CCD94 at us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> "Daniel P. Berrange" <berrange at redhat.com> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/01659b6a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 30
> Date: Fri, 22 Nov 2013 17:01:40 +0000 (UTC)
> From: Khanh-Toan Tran <khanh-toan.tran at cloudwatt.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a
> modest proposal for an external scheduler in our lifetime
> Message-ID:
> <969288672.14943277.1385139700462.JavaMail.root at cloudwatt.com>
> Content-Type: text/plain; charset=utf-8
>
> 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" <mspreitz at us.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 31
> Date: Fri, 22 Nov 2013 12:06:30 -0500 (EST)
> From: Julie Pichon <jpichon at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID:
> <532370933.39209272.1385139990948.JavaMail.root at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> "Maxime Vidori" <maxime.vidori at enovance.com> 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
>
>
>
> ------------------------------
>
> Message: 32
> Date: Fri, 22 Nov 2013 17:12:41 +0000
> From: Jarret Raim <jarret.raim at RACKSPACE.COM>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key
> Distribution Server, Trusted Messaging
> Message-ID: <CEB4EB99.82E5D%jarret.raim at rackspace.com>
> Content-Type: text/plain; charset="euc-kr"
>
> On 11/21/13, 7:51 PM, "Jamie Lennox" <jamielennox at redhat.com> 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 +0000, 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" <rbryant at redhat.com> 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 at lists.openstack.org
> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ------------------------------
>
> Message: 33
> Date: Fri, 22 Nov 2013 12:13:17 -0500 (EST)
> From: Julie Pichon <jpichon at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID:
> <639410224.39211670.1385140397543.JavaMail.root at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> "Imre Farkas" <ifarkas at redhat.com> 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/
>
>
>
> ------------------------------
>
> Message: 34
> Date: Fri, 22 Nov 2013 10:26:36 -0700
> From: Carl Baldwin <carl at ecbaldwin.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] L3 advanced features blueprint mapping to
> IETF and IEEE standards
> Message-ID:
> <CALiLy7qL9x7SBjkuazkHUJUg=muf2m1tLbomOP2NXw1eh20u=
> g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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 <nachi at ntti3.com> 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 <pedro.r.marques at gmail.com>:
> >> 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 nachi at 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 <
> Rochelle.Grober at huawei.com>
> >> wrote:
> >>
> >>
> >>
> >> From: Pedro Roque Marques [mailto:pedro.r.marques at 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 <colin at 2cups.com> 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 functionality
> >> (northbound boundary), and the QOS extension functionality both fell
> into
> >> the scope of Northbound and Southbound boundaries of this system.
> >>
> >> My comments in the session
> >>
> >> My comments in the session, while clouded with jet-lag were specifically
> >> around two concepts that are used when integrating other types of
> systems
> >>
> >> 1. In a simple (1-8) tenant environment integration with a northbound
> AS is
> >> normally done in a PE-CE model that generally centers around mapping
> dot1q
> >> tags into the appropriate northbound l3 segments and then handling the
> >> availability of the L2 path that traverses with port channeling, MLAG,
> STP,
> >> Etc.
> >>
> >> 2. In a complex environment (8+ for discussion) different Carrier
> Supporting
> >> Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or
> C are
> >> used. These allow the mapping of segregated tenant networks together and
> >> synchronizing between distributed systems. This normally extends the
> tagging
> >> or tunneling mechanism and then allows for BGP to synchronize NLRI
> >> information between AS?s.
> >>
> >> These are the standard ways of integrating between carriers, but also
> >> components of these implementations are used to integrate and scale
> inside
> >> of a single web scale data center. Commonly when you scale beyond a
> certain
> >> physical port boundary (1000is edge ports in many implementations, much
> >> larger in current implementations) the same designs for C2C
> integrations are
> >> used to create network availability zones inside a web scale data
> center.
> >>
> >> Support of these IETF and IEEE standard integrations are necessary for
> brown
> >> field installations
> >>
> >> In a green field installation, diverging from IETF and IEEE standards
> on the
> >> north bound edge while not a great idea, can result in a functional
> >> implementation. In a brown field implementation where OpenStack Neutron
> will
> >> be integrated into an existing network core. This boundary layer is
> where we
> >> move from a controlled system into a distributed system. The cleanly
> >> integrate into this system, IETF and IEEE protocols and standards have
> to be
> >> followed.
> >>
> >>
> >>
> >> <8DB71B56-CDE5-42D5-870E-CF94157510F8.png>When we diverge from this
> >> standards based integration at the north edge of our autonomous system
> we
> >> lose the ability to integrate without introducing major changes (and
> risk),
> >> into our core. In my experience this is sufficient to either slow or
> stall
> >> adoption. This is a major risk, that I believe can be mitigated.
> >>
> >> My thoughts on mitigating this risk
> >>
> >> We need to at least map and track the relevant IETF RFC?s that define
> the
> >> internet standards for integration at the AS boundary. I know that many
> of
> >> the network vendor developers that contribute to Neutron have access to
> >> people who both have deep knowledge of these standards, and also
> participate
> >> in the IETF working groups. I would hope that these resources could be
> >> leveraged to at least give a sanity check, at best ensure a compliant
> >> northbound interface to other systems.
> >>
> >> Side benefit of engaging IETF members in this discussion
> >>
> >> The other side benefit of this is that inventions inside of Neutron can
> also
> >> be communicated as standards to the rest of the world in the form of
> net new
> >> RFC?s. In OVS this has already happened, as OVS has emerged to be a
> common
> >> component in many network devices, and the need to establish and
> reference a
> >> common standard has risen it?s head. I would think that inventions
> within
> >> Neutron would follow this same path.
> >>
> >>
> >> Regards,
> >> Colin
> >> Colin McNamara
> >> People | Process | Technology
> >> --------------------------------------------
> >> Mobile: 858-208-8105
> >> Twitter: @colinmcnamara
> >> Linkedin: www.linkedin.com/colinmcnamara
> >> Blog: www.colinmcnamara.com
> >> Email: colin at 2cups.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 35
> Date: Fri, 22 Nov 2013 12:36:12 -0500
> From: Doug Hellmann <doug.hellmann at dreamhost.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Cinder][Glance] OSLO update
> Message-ID:
> <
> CADb+p3T0UuifbpywF22x-WTgjm8AzDJ58MG6VDQO8T2VzAWTvg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Nov 22, 2013 at 11:21 AM, Duncan Thomas <duncan.thomas at gmail.com
> >wrote:
>
> > On 22 November 2013 12:27, Elena Ezhova <eezhova at mirantis.com> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/ba060052/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 36
> Date: Fri, 22 Nov 2013 17:39:00 +0000
> From: Tim Bell <Tim.Bell at cern.ch>
> To: "Daniel P. Berrange" <berrange at redhat.com>, "OpenStack Development
> Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID:
> <5D7F9996EA547448BC6C54C8C5AAF4E5D985259B at CERNXCHG02.cern.ch>
> Content-Type: text/plain; charset="us-ascii"
>
> 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:berrange at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 37
> Date: Fri, 22 Nov 2013 12:39:59 -0500
> From: Doug Hellmann <doug.hellmann at dreamhost.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
> Message-ID:
> <
> CADb+p3Qy6qY++iwdp5u9cVz06xOa-sQqegpRkui5fVPD8id3tQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco <flavio at redhat.com> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/8c6e03c7/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 38
> Date: Fri, 22 Nov 2013 12:40:28 -0500
> From: Doug Hellmann <doug.hellmann at dreamhost.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
> Message-ID:
> <CADb+p3Q6-nywytb7VsaFNKZmGA=
> xYkiCaMEb4tM8OWCWoh726g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Nov 22, 2013 at 11:24 AM, Duncan Thomas <duncan.thomas at gmail.com
> >wrote:
>
> > On 22 November 2013 14:59, Ben Nemec <openstack at nemebean.com> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/6f52850e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 39
> Date: Fri, 22 Nov 2013 12:46:17 -0500
> From: Doug Hellmann <doug.hellmann at dreamhost.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Ceilometer] meaning of resource_id in a
> meter
> Message-ID:
> <CADb+p3Qjdkz62aJ9rvh=GnahW=
> 71cfa4maP-jDgh3tT6_GHEww at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Nov 21, 2013 at 2:37 PM, Gordon Chung <chungg at ca.ibm.com> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/eefe680d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 40
> Date: Fri, 22 Nov 2013 12:55:48 -0500
> From: Lorin Hochstein <lorin at nimbisservices.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID:
> <CADzpNMXD6Oc8C7d1zQXNS+_D8Of9QrEoe66_fCMffBgYrLE=
> 2Q at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell <Tim.Bell at cern.ch> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/8d15a232/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 41
> Date: Fri, 22 Nov 2013 18:02:04 +0000
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] RFC: Potential to increase min required
> libvirt version to 0.9.11 ?
> Message-ID: <20131122180203.GL16339 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> 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 <berrange at redhat.com>
> 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:|
>
>
>
> ------------------------------
>
> Message: 42
> Date: Fri, 22 Nov 2013 18:15:40 +0000
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: Lorin Hochstein <lorin at nimbisservices.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?
> Message-ID: <20131122181540.GN16339 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, Nov 22, 2013 at 12:55:48PM -0500, Lorin Hochstein wrote:
> > On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell <Tim.Bell at cern.ch> 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:|
>
>
>
> ------------------------------
>
> Message: 43
> Date: Fri, 22 Nov 2013 13:22:12 -0500
> From: Jordan OMara <jomara at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID: <20131122182212.GC1565 at redhat.com>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
>
> 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 <jomara at redhat.com>
> Red Hat Engineering, Raleigh
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 490 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/ff4e2553/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 44
> Date: Fri, 22 Nov 2013 13:26:13 -0500
> From: Eric Windisch <eric at cloudscaling.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Introducing the new OpenStack service for
> Containers
> Message-ID:
> <
> CALnZm-am+J_ospzKCw8VZcTsMSm3ASP7HH4hxtJvPCHfiCfSbw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman <kraman at gmail.com> 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
>
>
>
> ------------------------------
>
> Message: 45
> Date: Fri, 22 Nov 2013 18:49:09 +0000
> From: Mark McLoughlin <markmc at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key
> Distribution Server, Trusted Messaging
> Message-ID: <1385146149.4314.14.camel at sorcha>
> Content-Type: text/plain; charset="UTF-8"
>
> 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.
>
>
>
>
> ------------------------------
>
> Message: 46
> Date: Fri, 22 Nov 2013 19:07:39 +0000
> From: "Yathiraj Udupi (yudupi)" <yudupi at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a
> modest proposal for an external scheduler in our lifetime
> Message-ID: <CEB4E9FC.22073%yudupi at cisco.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> 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" <robertc at robertcollins.net> 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 <rbtcollins at hp.com>
> >Distinguished Technologist
> >HP Converged Cloud
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 47
> Date: Sat, 23 Nov 2013 00:44:16 +0530
> From: Rohan Kanade <openstack at rohankanade.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [Ironic][Cinder] Attaching Cinder volumes to
> baremetal instance
> Message-ID:
> <
> CAH3Sreo1C4-a72Kb+haUrzkZ7Zr2UY+MCmppJfaEDgQR4UG7wQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131123/5565ea0b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 48
> Date: Fri, 22 Nov 2013 11:29:24 -0800
> From: Krishna Raman <kraman at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Introducing the new OpenStack service for
> Containers
> Message-ID: <81B1D424-5508-4A18-8F09-0DCED1A4CE3A at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Nov 22, 2013, at 10:26 AM, Eric Windisch <eric at cloudscaling.com> wrote:
>
> > On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman <kraman at gmail.com>
> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/a7281201/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 49
> Date: Fri, 22 Nov 2013 19:43:05 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] [Infra] Support for PCI
> Passthrough
> Message-ID: <20131122194303.GP2304 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2013-11-22 08:59:16 +0000 (+0000), 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
>
>
>
> ------------------------------
>
> Message: 50
> Date: Fri, 22 Nov 2013 20:50:44 +0100 (CET)
> From: Maxime Vidori <maxime.vidori at enovance.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Javascript development
> improvement
> Message-ID:
> <1734467249.1771409.1385149844843.JavaMail.root at enovance.com>
> Content-Type: text/plain; charset=utf-8
>
> 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" <jomara at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> 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 <jomara at redhat.com>
> Red Hat Engineering, Raleigh
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 51
> Date: Fri, 22 Nov 2013 20:03:20 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] How to stage client major releases in
> Gerrit?
> Message-ID: <20131122200320.GQ2304 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> 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...
>
> <URL: https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits >
>
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 19, Issue 66
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/a2c7a46e/attachment-0001.html>
More information about the OpenStack-dev
mailing list