Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
Hi, thanks for your reply irena and salvatore. Currently, we're targeting 4 backends : bagpipe (the ref impelmentations compatible with other ref implementations of neutron), ODL, contrail and nuage. Contrail and bagpipe work with networks attachments to a bgpvpn connection, while ODL and Nuage work with routers attachments. We even start thinking about port attachments [1] Moreover, ODL needs a RD attribute that won't be supported by other backends. I think that each backend should be able to manage each kind of attachment in the future, depending on the will of the backend dev team. But in a firts step, we have to manage the capacity of each backend. So, indeed, the managment of attachments to a bgpvpn connection through the use of extensions will expose backend capacity. And I agree that it's not the good way, since when moving from one cloud to another, the API will change depending on the backend. So I see two ways to solve this issue : 1-In first releases, backends that don't support a feature will through a 'NotImplemented exception when the feature will be called through the API; We still have an inconsistent API, but hopefully, this gone be temporary. 2-reducing the scope of the spec [2] and having less compatible backends, and a smaller community for the bgpvpn project. [1]https://blueprints.launchpad.net/bgpvpn/+spec/port-association [2]https://review.openstack.org/#/c/177740/ regards, Mathieu On Wed, Aug 19, 2015 at 1:55 PM, Irena Berezovsky irenab@gmail.com wrote: Current VPNaaS Service Plugin inherits from VpnPluginRpcDbMixin, which is not required for some vendor solutions, since L3 is implemented without leveraging L3 Agents to manage router namespaces (ODL, MidoNet, etc). I guess if Mixin usage will be changed to conditional RPC support based on drivers requirements, follow what Salvatore suggested makes perfect sense. On Wed, Aug 19, 2015 at 11:06 AM, Salvatore Orlando salv.orla...@gmail.com wrote: my 0.02€ on the matter inline. Regards, Salvatore On 18 August 2015 at 23:45, Mathieu Rohon mathieu.ro...@gmail.com wrote: hi brandon, thanks for your answer. my answers inline, On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan brandon.lo...@rackspace.com wrote: So let me make sure I understand this. You want to do a separate service plugin for what would normally be separate drivers under one service plugin. The reasons for this are: 1. You dont want users the ability to choose the type, you want it always to be the same one While in theory it is be possible to have multiple BGPVPN providers in the same deployment, there are control and data plane aspects that the service type framework at the moment cannot deal with it. Mathieu brought some examples in the bug report. The bottom line appears to be that the choice of the l3 service plugin (or whatever serves l3 in your deployment) also dictates the choiche of the BGPVPN service provider to employ. 2. Some types do want to be the source of truth of the data stored, instead of it being the service plugin database. This point has little to do with service types. It's about the fact that plugins are not required to implemented the various db mixins in neutron.db and therefore not required to use the neutron DB. First, let me address the possibility of a solution using one service plugin and multiple drivers per type: I think that you can overcome #1 in the instantiation of the service plugin to check if there are more than 1 provider active, if so you can just throw an exception saying you can only have 1. I'd have to look at it more to see if there are any caveats to this, but I think that would work. For #2, assuming #1 works, then the drivers that are defined can have some boolean that they set that will tell the plugin whether they are the source of truth or not, and depending on that you can store the data in the service plugin's db or just pass the data along, also pass GET requests to the drivers as well. I agree that those workarounds will surely works but I wonder what is the meaning of a service plugin/type that can only support one service provider? can't the service plugin be the service provider directly? I believe there is some value, but I am not able to quantify it at the moment. - A single service plugin also implies (more or less) a common user-facing APIs. I really don't want to end up in a conditons where the user API looks different (or the workflow is different) according to what's backing the neutron BGPVPN implementation - A single service plugin provides a commonplace for all the boilerplate management logic. This works for most drivers, but not for those who don't rely on neutron DB as a data source (unless you manage to build a sqlalchemy dialect for things such as opencontrail APIs, but I seriously doubt that it would be feasible) - Distinct service plugins might lead to different workflows. This is not necessarily a
Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes
-Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: Wednesday, August 19, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes On 19 August 2015 at 21:19, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: [...] Proposed data structure: - create a top level directory in each repo called release-notes - within that create a subdirectory called changes. - within the release-notes dir we place yaml files containing the release note inputs. - within the 'changes' subdirectory, the name of the yaml file will be the gerrit change id in a canonical form. E.g. I1234abcd.yaml This serves two purposes: it guarantees file name uniqueness (no merge conflicts) and lets us determine which release to group it in (the most recent one, in case of merge+revert+merge patterns). We try to have python-glanceclient and glance_store including release notes upon the release time. We use in tree doc/source/index.rst for ease of access. This provides our release notes through: docs.openstack.org/developer/python-glanceclient/ and you can easily follow up stable branches via git: https://github.com/openstack/python-glanceclient/blob/stable/kilo/doc/source/index.rst I've been trying to push mentality in to our community that last thing before release, we merge release notes update and tag that. What comes to stable, I think it's worth of adding release notes in the backport workflow. One small issue I see with using changeid in the filename is that it prevents people from easily proposing a backport with a release note snippet in them (since they can't predict the changeID). They will have to get it generated and then amend their commit. Backports typically use the original changeID - they will if they use git cherry- pick. I think we need to enforce some more structure. Release notes are easier to read if you group them by category. For stable branches you should put critical upgrade notes first, then security updates, then random release notes. For master branch notes we usually have critical upgrade notes, then major features, then known issues, then random release notes. So I would encourage a slightly more detailed schema with categories to keep consistency and readability. Strong maybe, pointless in stable if our aim is to have each commit being release or if we anyways have one or two changes per topic. This would make sense on initial release from master excluding libs and clients which tends to have less changes per release anyways. Sure - please fill it in :). I was winging it, since I don't do release notes, I had no idea of your needs. Processing: 1) determine the revisions we need to generate release notes for. By default generate notes for the current minor release. (E.g. if the tree version is 1.2.3.dev4 we would generate release notes for 1.2.0, 1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]). How would that work in a post-versioned world ? What would you generate if the tree version is 1.2.3.post12 ? 1.2.3 is still the version, not that we can use post versions at all with pbr. (Short story - we can't because we used them wrongly and we haven't had nearly enough time to flush out remaining instances in the wild). 2) For each version: scan all the commits to determine gerrit change-id's. i) read in all those change ids .yaml files and pull out any notes within them. ii) read in any full version yaml file (and merge in its contained notes) iii) Construct a markdown document as follows: a) Sort any preludes (there should be only one at most, but lets not error if there are multiple) b) sort any notes We would sort them by category. The requirement for deterministic results means we'd just sort them. If they are divided into categories, we'd sort the list of categories (perhaps according to some schema) and then within each category sort the notes. c) for each note transform it into a bullet point by prepending its first line with '- ' and every subsequent line with ' ' (two spaces to form a hanging indent). d) strip any trailing \n's from everything. e) join the result - '\n'.join(chain(preludes, notes)) iv) we output the resulting file to release-notes/$version.md where $version is the pbr reported version for the tree (e.g. in the example above it would be 1.2.3.dev4, *not* 1.2.3). So you would have release-notes/1.2.2.yaml and release-notes/1.2.2.md in the same directory, with one being a subset of the data present in the other ? That feels a bit confusing. I would rather use two separate directories (source and output) for that. If you like, sure. Though the thing I was thinking was that for very old things we might generate the md file, delete the yaml,
[openstack-dev] [requirements] [global-requirements] [mistral] Using pika library
Hi, folks! Recently we've had the discussion with oslo.messaging team about acknowledge feature in RabbitMQ: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html After that Mistral team did the research about using *kombu *or *pika* library for implementation of remote procedure call server. Both kombu and pika was met our requirements. But we would prefer to use *pika* by next reasons: 1. It is less complex than *kombu*; 2. *kombu* itself is abstraction of messaging (but we don't need that); 3. We had the discussion with one of RabbitMQ developer which advised us to use *pika* (comparing to *kombu*) Is it possible to add *pika *to the global-requirements for our needs? Thanks. -- Best Regards, Nikolay @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tricircle] Cancellation of Weekly Team Meeting 2015.08.19
Hi Team, Due to inability of several team members to attend today's meeting, the meeting would be canceled and discussion are welcomed on the mailing list :) -- Zhipeng (Howard) Huang Standard Engineer IT Standard Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.
Hi Xies, Abhi, It works a bit differently. Nodepool is responsible to launch VMs which it then registers as Jenkins Slaves. These Jenkins slaves have “labels” which identify certain user-properties such as Operating System, image contents, etc. When CI wants to run a test case it submits the job to Jenkins master to be run on any Jenkins slave that matches the desired “label”. Jenkins will wait until a slave of that ‘label’ is available and assign the job once available. Ramy From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com] Sent: Tuesday, August 18, 2015 10:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves. Hi Abhi, IIUC, you should create and configure slaves(these slaves can be VMs or real physical machine) in Jenkins. And the nodepool is used to create and pool VMs automatically, and these VMs should be run on the slaves. Then, while CI wants to build and execute a testcase, especially which attempts to be run on an isolated host, the nodepool will match a proper VM for this testcase. Hope this might help you. Xiexs From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] Sent: Tuesday, August 18, 2015 1:46 PM To: openstack-in...@lists.openstack.org; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves. Also adding the following: * https://github.com/openstack-infra/project-config/tree/master/nodepool/elements Does this means that we don't have to take care of creating slaves(i.e; installing slave using scripts as we have done in master) and it will be done automatically, and also we don't have to configure slaves in Jenkins. A bit confusing for me so if anyone can explain it to me then it will be very helpful. On Tue, Aug 18, 2015 at 11:11 AM, Abhishek Shrivastava abhis...@cloudbyte.commailto:abhis...@cloudbyte.com wrote: Hi Folks, I was going through Ramy's guide for setting up CI, there I found out the following: * https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves But I don't get the fact on how to create the image, also what major settings need to be done to make the config perfect for use. Can anyone help me with that? -- [Image removed by sender.] Thanks Regards, Abhishek Cloudbyte Inc.http://www.cloudbyte.com -- [Image removed by sender.] Thanks Regards, Abhishek Cloudbyte Inc.http://www.cloudbyte.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] [global-requirements] [mistral] Using pika library
Nikolay, Do you mean that you will *NOT* use oslo.messaging and use pika directly. I'd strongly discourage that possibility. Few members on the oslo.messaging team are looking at pika library already and are doing a prototype: https://github.com/dukhlov/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_pika.py If you are interested in that effort, please let us know. Thanks, Dims On Wed, Aug 19, 2015 at 7:21 AM, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Hi, folks! Recently we've had the discussion with oslo.messaging team about acknowledge feature in RabbitMQ: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html After that Mistral team did the research about using *kombu *or *pika* library for implementation of remote procedure call server. Both kombu and pika was met our requirements. But we would prefer to use *pika* by next reasons: 1. It is less complex than *kombu*; 2. *kombu* itself is abstraction of messaging (but we don't need that); 3. We had the discussion with one of RabbitMQ developer which advised us to use *pika* (comparing to *kombu*) Is it possible to add *pika *to the global-requirements for our needs? Thanks. -- Best Regards, Nikolay @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] [global-requirements] [mistral] Using pika library
Hi, Davanum! Have you already read the thread [1]? It is about acknowledge feature in oslo.messaging. Particularly, about the absent of this feature in oslo.messaging. The guys from messaging said that it is very problematically to add that kind of feature to oslo.messaging because it does not fit to oslo.messaging's approach. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html On Wed, Aug 19, 2015 at 2:35 PM, Davanum Srinivas dava...@gmail.com wrote: Nikolay, Do you mean that you will *NOT* use oslo.messaging and use pika directly. I'd strongly discourage that possibility. Few members on the oslo.messaging team are looking at pika library already and are doing a prototype: https://github.com/dukhlov/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_pika.py If you are interested in that effort, please let us know. Thanks, Dims On Wed, Aug 19, 2015 at 7:21 AM, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Hi, folks! Recently we've had the discussion with oslo.messaging team about acknowledge feature in RabbitMQ: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html After that Mistral team did the research about using *kombu *or *pika* library for implementation of remote procedure call server. Both kombu and pika was met our requirements. But we would prefer to use *pika* by next reasons: 1. It is less complex than *kombu*; 2. *kombu* itself is abstraction of messaging (but we don't need that); 3. We had the discussion with one of RabbitMQ developer which advised us to use *pika* (comparing to *kombu*) Is it possible to add *pika *to the global-requirements for our needs? Thanks. -- Best Regards, Nikolay @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova
Markus Zoeller/Germany/IBM@IBMDE wrote on 08/17/2015 09:37:09 AM: From: Markus Zoeller/Germany/IBM@IBMDE To: OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org Date: 08/17/2015 09:48 AM Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova Michael Still mi...@stillhq.com wrote on 08/12/2015 10:08:26 PM: From: Michael Still mi...@stillhq.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/12/2015 10:14 PM Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova [...] Do we see https://review.openstack.org/#/c/205154/ as a reasonable example of such centralization? If not, what needs to change there to make it an example of that centralization? I see value in having a worked example people can follow before we attempt a large number of these moves. [...] Michael IIUC, this change doesn't yet meet the idea and needs to change by: * creating a module nova/conf/default.py and * move the imagecache config options to that module After this change, it wouldn't address the need to lookup which services use a specific config option. What about enhancing this to something like this: [...] Based on Michael's proposal I did another one which shows what I tried to describe in the previous mail. The example: https://review.openstack.org/#/c/214581/ Regards, Markus Zoeller (markus_z) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2
On 08/18/2015 09:34 PM, John Griffith wrote: On Tue, Aug 18, 2015 at 7:42 PM, John Griffith john.griffi...@gmail.com mailto:john.griffi...@gmail.com wrote: On Tue, Aug 18, 2015 at 2:14 PM, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net wrote: On 19 August 2015 at 03:51, Sean Dague s...@dague.net mailto:s...@dague.net wrote: So... I'm at Linux Con this week, meaning that things will be slow. I think - https://review.openstack.org/#/c/208582/ (slightly updated this morning) will get devstack users working again. And I agree, we really need devstack and the gate to be convergent on their solution here, not divergent. So unless something has changed, devstack users are broken only on Fedora - and the constraints thing won't protect them at this stage because of two things. Firstly, the bug isn't a cryptography bug - its a setuptools / pip thing resulting in the .so pip installs being in the arch neutral path rather than lib64, and this would work except that devstack also installs python-cffi, which then masks the pip updated one. I don't know why devstack is installing the binary package :/. This is a Fedora platform specific bug - it doesn't show up on Ubuntu - either because devstack doesn't install the ubuntu python-cffi package, or because pip/setuptools on ubuntu don't have the same disconnect with system packages in the same way. I'm not sure which. Secondly, until we have a gate on openstack/requirements that checks devstack-on-fedora, fedora developers will be exposed to this sort of thing from time to time :/. -Rob -- Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Catching up on this thread, looks like the referenced devstk change above (987dc6453e8e3a8a46d748059378564c42bafc5c) merged and broke things. Seems we don't install opt/stack/requirements so stack.sh is failing for third party CI's that don't use node-pool (suspect they'll fail when they're nodes are rebuilt similar to last weeks issue with keystone). Went ahead and confirmed that a fresh download and stack.sh locally fails, going to have a look after dinner but thought maybe somebody already knows what's up with this. Thanks, John For those that are interested, Clark pointed me to this patch [1] which in fact the addresses the issue I was running in to. [1]: https://review.openstack.org/#/c/214409/ Sorry about jumping the gun there. We thought, incorrectly, we had the right fix. And it's a conference week so access to my local test env wasn't easy. I've got a few ideas on how to robustify this whole path to make issues like this less likely to happen in the future. My bad. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install
On 8/18/2015 5:49 PM, Tony Breeds wrote:
On Tue, Aug 18, 2015 at 10:04:56PM +, Jeremy Stanley wrote:
On 2015-08-18 15:48:08 -0500 (-0500), Matt Riedemann wrote:
[...]
You'd also have to raise the cap on swiftclient in g-r stable/juno
to python-swiftclient=2.2.0,2.4.0.
[...]
Followed by stable point releases of everything with a stable/juno
branch and a {test-,}requirements.txt entry for python-swiftclient.
Oh, and some of those things might _also_ have overly-strict caps in
global-requirements.txt, so iterate until clean.
Oh boy ;P
Yours Tony.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yeah, it sucks.
--
Thanks,
Matt Riedemann
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] API: Question on 'Retry-After': 0 in HTTPForbidden
ok thanks for confirm, I will file a bug and fix it~, Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From: Alex Xu hejie...@intel.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/19/2015 08:14 AM Subject:Re: [openstack-dev] [nova] API: Question on 'Retry-After': 0 in HTTPForbidden +1 for Retry-After is wrong for quota case 在 2015年8月19日，下午1:32，GHANSHYAM MANN ghanshyamm...@gmail.com 写道： Retry-After __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
Current VPNaaS Service Plugin inherits from VpnPluginRpcDbMixin, which is not required for some vendor solutions, since L3 is implemented without leveraging L3 Agents to manage router namespaces (ODL, MidoNet, etc). I guess if Mixin usage will be changed to conditional RPC support based on drivers requirements, follow what Salvatore suggested makes perfect sense. On Wed, Aug 19, 2015 at 11:06 AM, Salvatore Orlando salv.orla...@gmail.com wrote: my 0.02€ on the matter inline. Regards, Salvatore On 18 August 2015 at 23:45, Mathieu Rohon mathieu.ro...@gmail.com wrote: hi brandon, thanks for your answer. my answers inline, On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan brandon.lo...@rackspace.com wrote: So let me make sure I understand this. You want to do a separate service plugin for what would normally be separate drivers under one service plugin. The reasons for this are: 1. You dont want users the ability to choose the type, you want it always to be the same one While in theory it is be possible to have multiple BGPVPN providers in the same deployment, there are control and data plane aspects that the service type framework at the moment cannot deal with it. Mathieu brought some examples in the bug report. The bottom line appears to be that the choice of the l3 service plugin (or whatever serves l3 in your deployment) also dictates the choiche of the BGPVPN service provider to employ. 2. Some types do want to be the source of truth of the data stored, instead of it being the service plugin database. This point has little to do with service types. It's about the fact that plugins are not required to implemented the various db mixins in neutron.db and therefore not required to use the neutron DB. First, let me address the possibility of a solution using one service plugin and multiple drivers per type: I think that you can overcome #1 in the instantiation of the service plugin to check if there are more than 1 provider active, if so you can just throw an exception saying you can only have 1. I'd have to look at it more to see if there are any caveats to this, but I think that would work. For #2, assuming #1 works, then the drivers that are defined can have some boolean that they set that will tell the plugin whether they are the source of truth or not, and depending on that you can store the data in the service plugin's db or just pass the data along, also pass GET requests to the drivers as well. I agree that those workarounds will surely works but I wonder what is the meaning of a service plugin/type that can only support one service provider? can't the service plugin be the service provider directly? I believe there is some value, but I am not able to quantify it at the moment. - A single service plugin also implies (more or less) a common user-facing APIs. I really don't want to end up in a conditons where the user API looks different (or the workflow is different) according to what's backing the neutron BGPVPN implementation - A single service plugin provides a commonplace for all the boilerplate management logic. This works for most drivers, but not for those who don't rely on neutron DB as a data source (unless you manage to build a sqlalchemy dialect for things such as opencontrail APIs, but I seriously doubt that it would be feasible) - Distinct service plugins might lead to different workflows. This is not necessarily a bad thing, because integration for some backends might need it. However this means that during review phase particular attention should be paid to ensure the behaviour of each service plugin respects the API specification. The reasons why I'm considering this change are : 1. I'm not sure we would have some use cases where we would be able to choose one bgpvpn backend independently from the provider of the core plugin (or a mech driver in the ML2 case) and/or the router plugin. If one use ODL to manage its core resources, he won't be able to use nuage or contrail to manage its bgpvpn connection. The bgpvpn project is more about having a common API than having the capacity to mix backends. At least for the moment. I agree with this; but this problem exists regardless of whether you have a single service plugin with drivers or multiple service plugins. You are unlikely to be able to use the contrail BGPVPN service plugin is core and l3 are managed by ODL, I think. 2. I'm also considering that each plugin, which would be backend dependent, could declare what features it supports through the use of extensions. Unfortunately extensions are the only way to declare supported capabilities at the moment. But please - don't end up allowing each service plugin exposing a different API. Each plugin would be a bgpvpn service type, and would implement the bgpvpn extension, but some of them could extend the bgpvpn_connection resource with other extensions also hosted in the bgpvpn
Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account
HI Ramy: Many thanks, I completed to install log-server. http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5111/logs/ So, can you help me to re-enable my gerrit account? -Original Message- From: Asselin, Ramy [mailto:ramy.asse...@hp.com] Sent: Tuesday, August 18, 2015 11:28 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org; 'Mike Perez' thin...@gmail.com Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account Rick, These files are missing newlines i.e. unreadable for me: [1] [2] [3] Out of curiosity, any particular reason you don't set up a log server like OpenStack Infra? I have a script to do that [4], which uses the upstream common solution [5] Ramy [1] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/devstacklog.txt.gz [2] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/etc/cinder/cinder.conf.txt.gz [3] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/screen-c-vol.txt.gz [4] https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_log_se rver.sh ]5] http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/manife sts/logserver.pp -Original Message- From: Rick Chen [mailto:rick.c...@prophetstor.com] Sent: Monday, August 17, 2015 8:22 AM To: 'Mike Perez' Cc: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account HI Mike: I completed to refine our CI configuration to follow Ramy's comments. Does any missed or other attention I need respect? [1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all cinder volume testing. [2] Add each service configuration in the log. http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/etc/ [3] Add email alert when the devstack build failed to instead of you notify to me. [4] Integrate VMware snapshot revert feature in the Jenkins master to clean CI slave machine OS environment that avoid the devstack building failed due to previous devstack garbage configuration. [5] Latest CI result for you reference. http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/ http://download.prophetstor.com/prophetstor_ci/ [6] Logs need to be browsable online. Add Rewrite module and rule in the apache configuration. my gerrit account: prophetstor-ci gerrit account email:prophetstor...@prophetstor.com Many thanks. -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: Friday, August 14, 2015 11:41 PM To: Rick Chen rick.c...@prophetstor.com Cc: openstack-dev@lists.openstack.org Subject: Re: [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI account On 09:44 Aug 14, Rick Chen wrote: HI Mike: Sorry again, I already add email alert agent in our CI Jenkins server to capture each failed build result. [1] - http://lists.openstack.org/pipermail/third-party-announce/2015-June/00 0192.h tml [2] - http://lists.openstack.org/pipermail/third-party-announce/2015-June/00 0193.h tml Solution 1: Our Jenkins client machine is vmware machine, I already add snapshot revert script in the Jenkins Job script. Each git review job trigger the client will revert to clean environment to solve this problem. Solution 2: I don't know whiched changed to make keystone unable to import pastedeploy. So I try to uninstall python-pastedeploy package in the local to solve some issue about unable to build devstack issue. Sorry again to disturb you. Rick, I looked at your CI results directory [1], but it looks like the last time this ran was on July 28th according to the last modified dates. This should be actively running even if you account is disabled from leaving comments, so I can verify from the logs things are running fine again. In addition, see Ramy's comments with issues with the CI [2]. [1] - http://download.prophetstor.com/prophetstor_ci/?C=M;O=A [2] - http://lists.openstack.org/pipermail/openstack-infra/2015-August/003057.html -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account
Hi Rick, Huge improvement. Log server is looking great! Thanks! Next question is what (cinder) patch set is that job running? It seems to be cinder master [1]. Is that intended? That's fine to validate general functionality, but eventually it needs to run the actual cinder patch set under test. It's helpful to include a link to the patch that invoked the job at the top of the console.log file, e.g. [2]. Ramy [1] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5111/logs/devstack-gate-setup-workspace-new.txt.gz#_2015-08-19_18_27_38_953 [2] https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L93 -Original Message- From: Rick Chen [mailto:rick.c...@prophetstor.com] Sent: Wednesday, August 19, 2015 5:23 AM To: 'OpenStack Development Mailing List (not for usage questions)'; 'Mike Perez' Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account HI Ramy: Many thanks, I completed to install log-server. http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5111/logs/ So, can you help me to re-enable my gerrit account? -Original Message- From: Asselin, Ramy [mailto:ramy.asse...@hp.com] Sent: Tuesday, August 18, 2015 11:28 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org; 'Mike Perez' thin...@gmail.com Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account Rick, These files are missing newlines i.e. unreadable for me: [1] [2] [3] Out of curiosity, any particular reason you don't set up a log server like OpenStack Infra? I have a script to do that [4], which uses the upstream common solution [5] Ramy [1] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/devstacklog.txt.gz [2] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/etc/cinder/cinder.conf.txt.gz [3] http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/screen-c-vol.txt.gz [4] https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_log_se rver.sh ]5] http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/manife sts/logserver.pp -Original Message- From: Rick Chen [mailto:rick.c...@prophetstor.com] Sent: Monday, August 17, 2015 8:22 AM To: 'Mike Perez' Cc: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account HI Mike: I completed to refine our CI configuration to follow Ramy's comments. Does any missed or other attention I need respect? [1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all cinder volume testing. [2] Add each service configuration in the log. http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/etc/ [3] Add email alert when the devstack build failed to instead of you notify to me. [4] Integrate VMware snapshot revert feature in the Jenkins master to clean CI slave machine OS environment that avoid the devstack building failed due to previous devstack garbage configuration. [5] Latest CI result for you reference. http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds vm-tempest-cinder-ci/5100/logs/ http://download.prophetstor.com/prophetstor_ci/ [6] Logs need to be browsable online. Add Rewrite module and rule in the apache configuration. my gerrit account: prophetstor-ci gerrit account email:prophetstor...@prophetstor.com Many thanks. -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: Friday, August 14, 2015 11:41 PM To: Rick Chen rick.c...@prophetstor.com Cc: openstack-dev@lists.openstack.org Subject: Re: [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI account On 09:44 Aug 14, Rick Chen wrote: HI Mike: Sorry again, I already add email alert agent in our CI Jenkins server to capture each failed build result. [1] - http://lists.openstack.org/pipermail/third-party-announce/2015-June/00 0192.h tml [2] - http://lists.openstack.org/pipermail/third-party-announce/2015-June/00 0193.h tml Solution 1: Our Jenkins client machine is vmware machine, I already add snapshot revert script in the Jenkins Job script. Each git review job trigger the client will revert to clean environment to solve this problem. Solution 2: I don't know whiched changed to make keystone unable to import pastedeploy. So I try to uninstall python-pastedeploy package in the local to solve some issue about unable to
[openstack-dev] Cross-project meeting times
Hi all, In last week's TC Highlights blog post [1] I asked if there is interest in moving the cross-project meeting. Historically it is held after the TC meeting, but there isn't a requirement for those timings to line up. I've heard from European and Eastern Standard Time contributors that it's a tough time to meet half the year. It's also a bit early for APAC, my apologies for noting this but still proposing to meet earlier. I'd like to propose a new cross-project meeting time, 1800 Tuesdays. To that end I've created a review with the proposed time: https://review.openstack.org/214605 Please take a look, see if you think it could work, and let us know either on this list or the review itself. Thanks, Anne 1. http://www.openstack.org/blog/2015/08/technical-committee-highlights-august-11-2015/ -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-project meeting times
On Wed, Aug 19, 2015 at 9:33 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-08-19 08:17:06 -0500 (-0500), Anne Gentle wrote: In last week's TC Highlights blog post [1] I asked if there is interest in moving the cross-project meeting. Historically it is held after the TC meeting, but there isn't a requirement for those timings to line up. I've heard from European and Eastern Standard Time contributors that it's a tough time to meet half the year. I'm in USA EST/EDT and it's not been particularly inconvenient for me, though I don't have children or keep a strict business hours schedule so perhaps that's why. It's also a bit early for APAC, my apologies for noting this but still proposing to meet earlier. Yeah, I'm not especially keen on ostracizing APAC for the sake of EMEA or the Americas, but I get that there's never a perfect time for everyone on the planet. I'd like to propose a new cross-project meeting time, 1800 Tuesdays. To that end I've created a review with the proposed time: https://review.openstack.org/214605 Please take a look, see if you think it could work, and let us know either on this list or the review itself. It's worth acknowledging that this conflicts with the Keystone meeting, and we do normally have decent Keystone representation in the current time slot. Oh, I love that the gate test would have told me that. I intended to be side-by-side with Murano, so I have revised the proposal accordingly. Thanks for pointing it out and for the input! Anne -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-project meeting times
+1 for moving it earlier. On August 19, 2015 6:17:06 AM PDT, Anne Gentle annegen...@justwriteclick.com wrote: Hi all, In last week's TC Highlights blog post [1] I asked if there is interest in moving the cross-project meeting. Historically it is held after the TC meeting, but there isn't a requirement for those timings to line up. I've heard from European and Eastern Standard Time contributors that it's a tough time to meet half the year. It's also a bit early for APAC, my apologies for noting this but still proposing to meet earlier. I'd like to propose a new cross-project meeting time, 1800 Tuesdays. To that end I've created a review with the proposed time: https://review.openstack.org/214605 Please take a look, see if you think it could work, and let us know either on this list or the review itself. Thanks, Anne 1. http://www.openstack.org/blog/2015/08/technical-committee-highlights-august-11-2015/ -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-project meeting times
I am ok with this moving as long as it doesn't camp on the Keystone meeting time ;). In all seriousness I'm not opposed to moving the meeting if it will include more people / make lives better for those who are there. Sent via mobile On Aug 19, 2015, at 08:20, Sean Dague s...@dague.net wrote: +1 for moving it earlier. On August 19, 2015 6:17:06 AM PDT, Anne Gentle annegen...@justwriteclick.com wrote: Hi all, In last week's TC Highlights blog post [1] I asked if there is interest in moving the cross-project meeting. Historically it is held after the TC meeting, but there isn't a requirement for those timings to line up. I've heard from European and Eastern Standard Time contributors that it's a tough time to meet half the year. It's also a bit early for APAC, my apologies for noting this but still proposing to meet earlier. I'd like to propose a new cross-project meeting time, 1800 Tuesdays. To that end I've created a review with the proposed time: https://review.openstack.org/214605 Please take a look, see if you think it could work, and let us know either on this list or the review itself. Thanks, Anne 1. http://www.openstack.org/blog/2015/08/technical-committee-highlights-august-11-2015/ -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] [global-requirements] [mistral] Using pika library
Excerpts from Nikolay Makhotkin's message of 2015-08-19 17:16:14 +0300: Hi, Davanum! Have you already read the thread [1]? It is about acknowledge feature in oslo.messaging. Particularly, about the absent of this feature in oslo.messaging. The guys from messaging said that it is very problematically to add that kind of feature to oslo.messaging because it does not fit to oslo.messaging's approach. The Oslo libraries are meant to evolve as the needs to the applications evolve. That process works best when it comes about through collaboration between all of us, and the Oslo team has taken on the mission of enabling that collaboration. What I'm hearing in this request is the library our community has written doesn't do something we want, so rather than work on it with other members of our community we want to adopt a different library that is missing different features [2]. As far as I can tell from reading the thread you linked to, you weren't told no just that it might be harder than just moving the place we send acknowledgments inside the current driver, and we're likely to need your help with the implementation. The thread sort of died off, so perhaps that wasn't clear. You have what seems to be a new case -- perhaps its an old case that was never being handled properly and everyone actually always wanted this, I don't know. Either way, handling that case will require a change to the semantics of the library, which means we need to be careful about how we do it, but it's not impossible or unwanted. However we implement it, we need to ensure backwards compatibility for applications relying on the current behavior. For example, perhaps the application would pass a flag to the messaging library to control whether ACKs are sent before or after processing (we don't want that as a configuration option, because it's the application developer who needs to handle any differences in behavior, rather than the deployer). We should start out with the default behavior set to what we have now, and then we can experiment with changing it in each application before changing the default in the library. So, if you're interested in working with us on that, let us know. Doug [2] pika does not yet support Python 3, and would require work within the application to set up configuration options that would then be different from the options used in other OpenStack applications. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html On Wed, Aug 19, 2015 at 2:35 PM, Davanum Srinivas dava...@gmail.com wrote: Nikolay, Do you mean that you will *NOT* use oslo.messaging and use pika directly. I'd strongly discourage that possibility. Few members on the oslo.messaging team are looking at pika library already and are doing a prototype: https://github.com/dukhlov/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_pika.py If you are interested in that effort, please let us know. Thanks, Dims On Wed, Aug 19, 2015 at 7:21 AM, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Hi, folks! Recently we've had the discussion with oslo.messaging team about acknowledge feature in RabbitMQ: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html After that Mistral team did the research about using *kombu *or *pika* library for implementation of remote procedure call server. Both kombu and pika was met our requirements. But we would prefer to use *pika* by next reasons: 1. It is less complex than *kombu*; 2. *kombu* itself is abstraction of messaging (but we don't need that); 3. We had the discussion with one of RabbitMQ developer which advised us to use *pika* (comparing to *kombu*) Is it possible to add *pika *to the global-requirements for our needs? Thanks. -- Best Regards, Nikolay @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Great updates to tests and CI jobs
Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.
Hi Ramy, I got the following you mentioned, so as per my understanding here are the points: - We need to install CI master on a VM (*Using Ubuntu 14.04 in my case*). - The Master VM should have properties like 8 GB RAM, 100 GB HD. - Nodepool, Jenkins and Zull will be installed in the master VM. - We had to create slaves images and configure it to nodepool (*Creating Ubuntu 14.04 images*). - Nodepool will create it automatically later. Please guide me if I am wrong at any point. Also, your valuable suggestions are also welcome. On Wed, Aug 19, 2015 at 7:24 PM, Asselin, Ramy ramy.asse...@hp.com wrote: Hi Xies, Abhi, It works a bit differently. Nodepool is responsible to launch VMs which it then registers as Jenkins Slaves. These Jenkins slaves have “labels” which identify certain user-properties such as Operating System, image contents, etc. When CI wants to run a test case it submits the job to Jenkins master to be run on any Jenkins slave that matches the desired “label”. Jenkins will wait until a slave of that ‘label’ is available and assign the job once available. Ramy *From:* Xie, Xianshan [mailto:xi...@cn.fujitsu.com] *Sent:* Tuesday, August 18, 2015 10:59 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves. Hi Abhi, IIUC, you should create and configure slaves(these slaves can be VMs or real physical machine) in Jenkins. And the nodepool is used to create and pool VMs automatically, and these VMs should be run on the slaves. Then, while CI wants to build and execute a testcase, especially which attempts to be run on an isolated host, the nodepool will match a proper VM for this testcase. Hope this might help you. Xiexs *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] *Sent:* Tuesday, August 18, 2015 1:46 PM *To:* openstack-in...@lists.openstack.org; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves. Also adding the following: - https://github.com/openstack-infra/project-config/tree/master/nodepool/elements Does this means that we don't have to take care of creating slaves(i.e; installing slave using scripts as we have done in master) and it will be done automatically, and also we don't have to configure slaves in Jenkins. A bit confusing for me so if anyone can explain it to me then it will be very helpful. On Tue, Aug 18, 2015 at 11:11 AM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: Hi Folks, I was going through Ramy's guide for setting up CI, there I found out the following: - https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves But I don't get the fact on how to create the image, also what major settings need to be done to make the config perfect for use. Can anyone help me with that? -- *[image: Image removed by sender.]* *Thanks Regards,* *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* -- *[image: Image removed by sender.]* *Thanks Regards,* *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Thanks Regards,* *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-project meeting times
On 2015-08-19 08:17:06 -0500 (-0500), Anne Gentle wrote: In last week's TC Highlights blog post [1] I asked if there is interest in moving the cross-project meeting. Historically it is held after the TC meeting, but there isn't a requirement for those timings to line up. I've heard from European and Eastern Standard Time contributors that it's a tough time to meet half the year. I'm in USA EST/EDT and it's not been particularly inconvenient for me, though I don't have children or keep a strict business hours schedule so perhaps that's why. It's also a bit early for APAC, my apologies for noting this but still proposing to meet earlier. Yeah, I'm not especially keen on ostracizing APAC for the sake of EMEA or the Americas, but I get that there's never a perfect time for everyone on the planet. I'd like to propose a new cross-project meeting time, 1800 Tuesdays. To that end I've created a review with the proposed time: https://review.openstack.org/214605 Please take a look, see if you think it could work, and let us know either on this list or the review itself. It's worth acknowledging that this conflicts with the Keystone meeting, and we do normally have decent Keystone representation in the current time slot. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core
Congratulations! Welcome Gorka! Jay On 08/19/2015 12:01 PM, Mike Perez wrote: On 12:13 Aug 13, Mike Perez wrote: It gives me great pleasure to nominate Gorka Eguileor for Cinder core. Gorka's contributions to Cinder core have been much apprecated: https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11 60/90 day review stats: http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt Cinder core, please reply with a +1 for approval. This will be left open until August 19th. Assuming there are no objections, this will go forward after voting is closed. Gorka has been added to Cinder core. Welcome! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel][puppet] The state of collaboration: 9 weeks
On 08/18/2015 03:33 AM, Dmitry Borodaenko wrote: Two weeks ago, I flagged the patch sets to commits ratio as the biggest problem that Fuel contributors to Puppet OpenStack should address, and over the past two weeks the situation has improved dramatically. In first and second week of August, 19 of our commits were merged in upstream, bringing our patch sets per commit ratio from 19 down to 5.6 (while average for Puppet OpenStack during that period was 6.5). With the share of patch sets pushed by Fuel developers remaining at roughly the same level (15.9% vs 17.4%), I think it's safe to call this problem solved. Simply awesome! Comparing last 30 days contribution stats vs same numbers two weeks ago: Bogdan Dobrelia (#3 reviewer!): 67.2% - 66.3% (disagreements 4.9% - 3.6%) Denis Egorenko: 97% - 87.5% (disagreements 12.1% - 13.9%) Vasyl Saienko: 100% - 96.4% (disagreements 16.7% - 10.7%) Ivan Berezovskiy: 100% - 92.3% (disagreements 0% - 3.8%) Sergey Kolekonov: 91.7% - 95.7% (disagreements 8.3% - 13%) Max Yatsenko: n/a - 100% (disagreements n/a - 17.4%) Alex Schultz: 80% - 80% (disagreements 20% - 26.7%) Bartlomiej Piotrowski: n/a - 100% (disagreements n/a - 12.5%) Sergii Golovatiuk: 100% - 100% (disagreements 33.3% - 0%) Bogdan continues to set the example and improve his numbers, which is not surprising considering that he's also the top reviewer in fuel-library. I think puppet-nova and puppet-neutron teams should seriously consider nominating him for core, he already tops reviewers lists for these modules. http://stackalytics.com/?user_id=bogdandometric=marks 2 commits and 16 LOC in our Puppet modules is in my opinion not enough to promote him core reviewer today. Though he's making good progress on reviews, we also need to read how he write code in our am upstremodules, and not in Fuel Library. Denis, Vasyl, and Ivan are not there yet, but they all have noticeably increased both number and quality of their reviews, keep it up guys! Numbers for other top reviewers are uneven and small enough for noise to overtake meaningful data, all I can recommend here is to watch your disagreements and learn from them. A ratio above 10% can mean one of three things: 1) you're not doing enough reviews so even a handful of disagreements sticks out -- do more reviews and this will improve on its own; 2) you're missing problems with the code that other reviewers find unacceptable -- try to be more attentive and watch for the things that you've been missing; 3) you disagree with majority on how some things should be done -- discuss your differences on IRC or ML and figure out a consensus. Moving on to other numbers, weekly IRC meetings participation remains good: Aug-4: 4 of 15 participants, 22 of 162 lines Aug-11: 6 of 16 participants, 62 of 192 lines Unfortunately it's not all roses and unicorns, last week I flagged a stuck review that I think has been mishandled by Puppet OpenStack team [0][1], and it still remains in the same state. [0] https://review.openstack.org/198695 [1] http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-11-15.00.log.html#l-140 On July 8, patch set 2 has passed CI. It received 2 +1 votes from other Fuel developers on July 10 and 29, but remained ignored by upstream reviewers until August 10, more than a month after the current patch set was posted. Then, a Swift core reviewer left a -1 disagreeing with the intent of the patch, and even though patch author posted a rebuttal a day later, the patch remains stuck and untouched for yet another week. It's a one-off case that does not outweigh the positive trends I've outlined above, but even one stuck patch that fixes a critical bug is enough to justify a fork. Speaking of forks, we managed to un-fork 9 upstream modules [2] with puppet-librarian-simple before Fuel 7.0 soft code freeze has kicked in. [2] https://github.com/stackforge/fuel-library/blob/master/deployment/Puppetfile That's 9 times more than my conservative estimate of converting at least 1 module to librarian in 7.0, but these were the easiest and least deviated from upstream. We've still got 50 more modules to convert in Fuel 8.0, many will require commits to be merged in upstream before they can be completely un-forked. Having such commits wait for a month at a time only to be summarily rejected puts this effort at risk, lets figure out what went wrong this time and come up with a way to prevent this from happening again. Thanks, From a general perspective, it's clear Fuel people is making good progress to be involved in Puppet OpenStack group, and we can be proud of our recent discussions that lead us to this state now. Promoting people to the core team is another story and it will come naturally like it has been done for other people, I think you need to continue to show that efforts are consistent and good stuffs will probably happen.
Re: [openstack-dev] [neutron][fwaas][dvr] FWaaS with DVR
Great writeup, I think this is an excellent starting place for our efforts moving forward. There is also some information on an accepted spec about firewall insertion[1], search for the phrase Phase 2 where firewalls can be associated with ports - and also some of my thinking about having FwaaS consume the networking-sfc project's proposed API, since that could help describe firewall insertion - although I don't know if we'd expose it to the user and have them use the SFC API to insert their firewalls, or if maybe in the FwaaS API we can take a list of ports like described in [1], and then consume the SFC API in the backend. At the very least, we're going to have lots to talk about in Tokyo :) [1]: http://specs.openstack.org/openstack/neutron-specs/specs/kilo/fwaas-router-insertion.html -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [fwaas][dvr] FWaaS with DVR
Currently, FWaaS behaves differently with DVR, applying to only north/south traffic, whereas FWaaS on routers in network nodes applies to both north/south and east/west traffic. There is a compatibility issue due to the asymmetric design of L3 forwarding in DVR, which breaks the connection tracking that FWaaS currently relies on.I started an etherpad where I hope the community can discuss the problem, collect multiple possible solutions, and eventually try to reach consensus about how to move forward:https://etherpad.openstack.org/p/FWaaS_with_DVRI listed every possible solution that I can think of as a starting point. I am somewhat new to OpenStack and FWaaS, so please correct anything that I might have misrepresented.Please add more possible solutions and comment on the possible solutions already listed.Mickey __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Kuryr - virtual sprint
Hello everyone, During our last meeting an idea was brought up that we try to do a virtual sprint for Kuryr somewhere in September. Basically the plan is very similar to the mid cycle sprints or feature sprints where we iterate on couple of tasks online and finish gaps we might have in Kuryr. (I think we are talking about 2-3 days) The agenda for the sprint is dependent on the amount of work we finish by then, but it will probably consist of containerising some of the common plugins and connecting things end to end. (for host networking) I started this email in order to find the best dates for it, so if you plan on participating please share your preferred dates (anyone that has a Neutron plugin might want to offer a containerised version of it with Kuryr to integrate with Docker and lib network and the sprint is probably a good place to start doing it) Thanks Gal. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] RFE for DHCP agent changes for networking-calico
FYI, I've raised the new RFE bug that I suggested below: https://bugs.launchpad.net/neutron/+bug/1486649 Neil On 18/08/15 23:22, Neil Jerram wrote: Although the DHCP-related patches below are I think very close to mergeable, Brian Haley on IRC queried what, process-wise, motivates merging them now (for Liberty). I think he's right that something is missing, so I'd like to discuss filling that hole here. What has happened so far is this: - https://review.openstack.org/#/c/198439/ described 'routed networking', which is the ultimate motivation for these patches. - I realised/was told that there should be an RFE bug, per current process, so raised https://bugs.launchpad.net/neutron/+bug/1472704 - Those contributed to the beginning of discussions about supporting 'routed' or 'L3' networks in Neutron - which are ongoing and will take Mitaka at least to refine. - Nevertheless, the DHCP-related patches are still valuable now (as explained below) and feasible within the Liberty timescale, so I've continued refining those. - Discussions, which I believe supported this in principle, took place in neutron-drivers [1][2] and main Neutron [3] IRC meetings. [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-14-15.04.log.html [2] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-21-15.00.log.html [3] discussion between 14:49:44 and 14:56:49 at http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-28-14.01.log.html The specific process issue now is that the patches that (IMO) make sense for Liberty reference a bug (1472704) that has a much wider scope and so is quite correctly not approved for Liberty. So, what to do? My guess is to raise a new RFE bug that just motivates the DHCP agent support that I'd like to achieve - by way of the existing patches - in the Liberty timescale, ask neutron-drivers to approve that, and update the patches to reference that bug instead. Does that sound right? Regards, Neil Original Message From: Neil Jerram Sent: Monday, 17 August 2015 18:47 To: OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] New networking-calico project I'd like to announce networking-calico, a new project within the Neutron stadium to provide OpenStack integration pieces for Project Calico [1][2]. In a sentence, Calico is a backend that uses routing and iptables to provide IP-level connectivity between VMs, instead of - as most Neutron backends do - using bridging to provide an effective L2 broadcast domain. You can read about why that might be interesting at [1][2], or in more OpenStack-centric terms at [3]. Calico's semantics are not fully describable by the current Neutron API, and I plan to contribute to API and data model work to address this. Discussion about that has already begun at [3] and in the email thread about 'routed, segmented networks' [4], and I hope it will continue through the end of this cycle, in Tokyo, and during Mitaka. For a practical deployment, though, and with some semantic caveats [5], Calico-style connectivity can be used already in an OpenStack cluster - and we have several operator partners interested in and trialling that. My team has been developing and refining this since Icehouse, using Calico-specific patches to Nova and Neutron, but we are now within touching distance, we think, of working with vanilla OpenStack when Liberty is released. We released our v1.0 milestone of the core Calico code last week [14], our Nova patches were merged in July, and we have the following core Neutron patches currently in review. [6] https://review.openstack.org/#/c/205181/ [7] https://review.openstack.org/#/c/206078/ [8] https://review.openstack.org/#/c/206077/ [9] https://review.openstack.org/#/c/206079/ These patches have been through many cycles of review - thanks in particular to Cedric and Oleg - and are now, I believe, fully tested and polished. They make small generalizations to the DHCP agent code so that a networking-calico-provided interface driver will be able to use it, instead of having to provide a parallel DHCP agent implementation. I would particularly appreciate if Neutron core reviewers would consider reviewing and approving [6] and [7] now, as they are the changes that would be messiest if I had to reimplement them out-of-tree using some kind of subclassing approach. Then the plan for networking-calico is that it will contain docs, an ML2 mechanism driver, a DHCP interface driver, and a Devstack plugin for Calico. These aren't yet at [10], but I will be getting on with that shortly, and you can already see those pieces in other forms (which will be retired) at [11], [12] and [13]. Hence, within the next few weeks, I hope that
Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs
Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Moving instack upstream
- Original Message - From: Dmitry Tantsur dtant...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, 19 August, 2015 5:57:36 PM Subject: Re: [openstack-dev] [TripleO] Moving instack upstream On 08/19/2015 06:42 PM, Derek Higgins wrote: On 06/08/15 15:01, Dougal Matthews wrote: - Original Message - From: Dan Prince dpri...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, 6 August, 2015 1:12:42 PM Subject: Re: [openstack-dev] [TripleO] Moving instack upstream snip I would really like to see us rename python-rdomanager-oscplugin. I think any project having the name RDO in it probably doesn't belong under TripleO proper. Looking at the project there are some distro specific things... but those are fairly encapsulated (or could be made so fairly easily). I agree, it made sense as it was the entrypoint to RDO-Manager. However, it could easily be called the python-tripleo-oscplugin or similar. The changes would be really trivial, I can only think of one area that may be distro specific. I'm putting the commit together now to pull these repositories into upstream tripleo are we happy with the name python-tripleo-oscplugin ? Do we really need this oscplugin postfix? It may be clear for some of us, but I don't that our users know that OSC means OpenStackClient, and that oscplugin designates something that adds features to openstack command. Can't we just call it python-tripleo? or maybe even just tripleo? +1 to either. Having oscplugin in the name just revealed an implementation detail, there may be a point where for some reason everyone moves away from OSC. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
As we considered today, Ubuntu bootstrap will not be shipped in MOS 7.0. It was a hard decision based on the issue with NICs naming [1]. This bug can be fixed only by changing the naming of network interfaces( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) and it's too late to do it in MOS 7.0 scope. So, this feature is moved to MOS 8.0. [1] https://bugs.launchpad.net/mos/+bug/1482049 -- Thanks, Michael On Thu, Aug 13, 2015 at 6:30 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here https://review.openstack.org/#/c/194154/. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu ( http://archive.ubuntu.com/ubuntu) and MOS ( http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: *fuel-bootstrap-image-set ubuntu* 3. Just in a case restart dnsmasq: *dockerctl shell cobbler service dnsmasq restart* 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for *partners* *and* *plugin developers*. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael -- Thanks, Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2015 05:25 PM, Russell Bryant wrote: While this includes me, I'm really not taking this personally. I'm thinking about it in the general sense. Thanks, and sorry for the thread, but I felt that we should clarify the matter asap if the new world does not completely stick to some minds in the team, like mine. On 08/14/2015 11:03 AM, Kyle Mestery wrote: I'd argue the system is built on a web of trust. If you trust me, and I trust Russell and Brandon, then you should likely trust Russell and Brandon as well. This is EXACTLY what the Lieutenant system was meant to convey, though I now feel like perhaps people missed this key ingredient of the new world we find ourselves in. This is a huge and important point. The N to N trust model we've been operating under doesn't scale. Neutron is trying to move to a different trust model that has proven to scale much further than we've been able to do within a single OpenStack project so far. Indeed that's the case, and I believe Kyle's efforts are the main reason we have a team that is so open to newcomers and different perspectives. That's why I feel that even if I am not completely bought in the new world doctrine, I should expect that if Kyle does something, he makes it for good. That's indeed trust, but based on past experience, not the potential future. If Kyle and others leading a section of Neutron trust me, I'm happy to jump in and do more reviews. If they trust me, I'd hope others not as familiar with me or my work can trust by proxy. The same applies to Brandon. I honestly don't know Brandon very well, but I have a high level of trust for Kyle. Kyle trusts him, so +1 from me. I tried to digest it these days, and I still have problems with it. In my world, trust indeed can be based on proxy referrals, but not solely. Usually whenever there are nominations sent, I already have a clue of how candidates contribute to the repo, their goods and bads. If not, I always have a source of truth to fix the lack of knowledge (stackalytics, git log, ...) If I have no ways to know, I don't feel like I'm in the position to +1 a nomination. If the vote is to be based solely on my trust in Kyle, then I'm better not to vote at all (that's what I did) and defer to Kyle alone to make a judgement. With this new world, do we even need to vote? Kyle has a tough role here. It means he gives up some control, but it's the way the project will scale. Kyle doesn't have to develop a close trust relationship with everyone merging code into the main neutron repo, much less all the other repos. He can delegate some of that. It only works if everyone buys into this way of thinking. Agreed, though there is still should be some kind of relationship between team members, if not with Kyle. I think the discussion is not about delegation though; but about criteria that we apply to core reviewers, both existing and new ones. Kyle removed several members from the core team before because of their low review stats (in the past, not in the future), and I believe it was the right thing to do. But then we should probably apply similar requirements to new candidates. Now, I see Kyle's point in trying to push for more proxy trust in neutron, and I also think that I may miss new developments in project governance, and indeed adding more cores in the team is a good thing, especially from those contributors that showed their effectiveness in other openstack projects (ovn, nova for Russell; lbaas for Brandon). I only want to make sure that by doing it we don't lower criteria to core reviewers in terms of number of reviews etc. I see we lag on it. And also I am concerned that we may suggest to others that non-core reviews are somehow insignificant and that collecting some review stats for several months or even weeks is considered a pointless effort unless it's done with a core hammer. I value reviews of multiple openstack folks who are not cores in neutron, f.e. @otherwiseguy and @gsagie for anything ovsdb related; or @zzzeek for all things sql-ish; or @salv-orlando for all things API/policy/how the world started to exist; or @jlibosva for anything python-esoteric; or @moshele for sr-iov... The list follows. I don't want them to feel their reviews are not that valuable if not +2. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV1L7sAAoJEC5aWaUY1u57rhYIAOCxX5K8HbHNcUYh33/rvTRc InqvoKKu5NWFU4s+iUZly1Fu5/3JXzLR5h8/+1b/gWR5EDYJ2Q6FRy5Bmn6Fduuw cHV6trqGfEmA+NJsvNSNeg1Ux8hQ0hjdcF0mcrMhM0li+DFDMwogHMxPUAzKF4Cm fcMDr+aZW3zkUDi0Y/iUjxqWwQFOBwPg0gWhKqhasVTqbOfd0W62z4gT9o6ZYkdn mJr6jU+qc1hV+St03qpgLN9h/S023Ha1PCnMBUfjldbthmVBtJEsgmyfHlqWpWmc UGSH7vTv6EmSSVcvZmAuCSZQKeG4UaodbApNusELFTA4zSK6GeKgJL9hr9MfkCs= =ZXGT -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [TripleO] Moving instack upstream
On 06/08/15 15:01, Dougal Matthews wrote: - Original Message - From: Dan Prince dpri...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, 6 August, 2015 1:12:42 PM Subject: Re: [openstack-dev] [TripleO] Moving instack upstream snip I would really like to see us rename python-rdomanager-oscplugin. I think any project having the name RDO in it probably doesn't belong under TripleO proper. Looking at the project there are some distro specific things... but those are fairly encapsulated (or could be made so fairly easily). I agree, it made sense as it was the entrypoint to RDO-Manager. However, it could easily be called the python-tripleo-oscplugin or similar. The changes would be really trivial, I can only think of one area that may be distro specific. I'm putting the commit together now to pull these repositories into upstream tripleo are we happy with the name python-tripleo-oscplugin ? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Moving instack upstream
On 08/19/2015 06:42 PM, Derek Higgins wrote: On 06/08/15 15:01, Dougal Matthews wrote: - Original Message - From: Dan Prince dpri...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, 6 August, 2015 1:12:42 PM Subject: Re: [openstack-dev] [TripleO] Moving instack upstream snip I would really like to see us rename python-rdomanager-oscplugin. I think any project having the name RDO in it probably doesn't belong under TripleO proper. Looking at the project there are some distro specific things... but those are fairly encapsulated (or could be made so fairly easily). I agree, it made sense as it was the entrypoint to RDO-Manager. However, it could easily be called the python-tripleo-oscplugin or similar. The changes would be really trivial, I can only think of one area that may be distro specific. I'm putting the commit together now to pull these repositories into upstream tripleo are we happy with the name python-tripleo-oscplugin ? Do we really need this oscplugin postfix? It may be clear for some of us, but I don't that our users know that OSC means OpenStackClient, and that oscplugin designates something that adds features to openstack command. Can't we just call it python-tripleo? or maybe even just tripleo? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs
Indeed, great news! I would only suggest to wait a little bit more that a few days with switching to the voting mode since it looks like there will be not so many patches proposed to python-fuelclient as we are heading towards Hard Code Freeze. I hope that the next step will be to enable Python 3 pipepline for our client so we could finally test all the code that uses six library for Python 2 3 compatibility. Best, Sebastian 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core
On 12:13 Aug 13, Mike Perez wrote: It gives me great pleasure to nominate Gorka Eguileor for Cinder core. Gorka's contributions to Cinder core have been much apprecated: https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11 60/90 day review stats: http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt Cinder core, please reply with a +1 for approval. This will be left open until August 19th. Assuming there are no objections, this will go forward after voting is closed. Gorka has been added to Cinder core. Welcome! -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][fwaas][dvr] FWaaS with DVR
Resending, forgot the [neutron] tag-Mickey Spiegel/San Jose/IBM wrote: -To: openstack-dev@lists.openstack.orgFrom: Mickey Spiegel/San Jose/IBMDate: 08/19/2015 09:45AMSubject: [fwaas][dvr] FWaaS with DVRCurrently, FWaaS behaves differently with DVR, applying to only north/south traffic, whereas FWaaS on routers in network nodes applies to both north/south and east/west traffic. There is a compatibility issue due to the asymmetric design of L3 forwarding in DVR, which breaks the connection tracking that FWaaS currently relies on.I started an etherpad where I hope the community can discuss the problem, collect multiple possible solutions, and eventually try to reach consensus about how to move forward:https://etherpad.openstack.org/p/FWaaS_with_DVRI listed every possible solution that I can think of as a starting point. I am somewhat new to OpenStack and FWaaS, so please correct anything that I might have misrepresented.Please add more possible solutions and comment on the possible solutions already listed.Mickey __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [glance] [nova] Image Prefetching – Precaching
Hi everyone, This is my first email to the OS developer forum, so forgive me if I misplaced the subject tags J. Straight to the point: for a project we’re involved in, we think that a pre-fetcher mechanism would be great for a variety of use cases. There was an attempt with this blueprint: https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2 and a more recent one: https://blueprints.launchpad.net/python-novaclient/+spec/prefetch-image although both seems to be dead now. So I really want to get a feedback from the developer’s community whether (1) such a feature makes sense in general, and (2) it may be worth the integration of such a component in the OpenStack code. In fact, although we can solve our problem by developing an in-house component, it would be better to have it integrated in OpenStack, including Nova and Horizon, so I need the feedback from the OS Guru guys J. What do you think? -- Dott. Alberto Geniola albertogeni...@gmail.com +39-346-6271105 https://www.linkedin.com/in/albertogeniola Web: http://www.hw4u.it __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 8/19/2015 2:16 PM, Matt Riedemann wrote: On 8/19/2015 1:33 PM, Matt Riedemann wrote: On 8/19/2015 12:18 PM, Chen CH Ji wrote: In doing [1] [2], some suggestions raised that those kind of change need microversion bump which is fine however, another concern raised on whether we need combine a set of those kind of changes (which may only change some error code) into one bump ? apparently there are pros and cons for doing so, combine makes API version bump not that frequent for minor changes but makes it hard to review and backport ... so any suggestions on how to handle ? Thanks [1]https://review.openstack.org/#/c/198753/ [2]https://review.openstack.org/#/c/173985/ Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I don't see why https://review.openstack.org/#/c/198753/ would require a microversion bump. We've always allowed handling 500s and turning them into more appropriate error codes, like a 400 in this case. As noted: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html Changing an error response code to be more accurate. is generally acceptable. https://review.openstack.org/#/c/173985/ doesn't require a version bump for the same reasons, IMO. If people are hung up on 400 vs 403 in that change, just make it a 400, we do it both ways in the compute API. I guess the problems are in the doc: http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63 - the list of status codes allowed for a particular request Example: an API previously could return 200, 400, 403, 404 and the change would make the API now also be allowed to return 409. - changing a status code on a particular response Example: changing the return code of an API from 501 to 400. So in the one change, just return 400. In the service_get change where you want to return a 400 but it's only returning a 404 today, then I guess according to the doc you'd need a microversion bump. But what do we do about fixing that bug in the v2 API? Do we not fix it? Do we return 404 but v2.1 would return 400 with a microversion bump? That's equally inconsistent and gross IMO. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 8/19/2015 12:18 PM, Chen CH Ji wrote: In doing [1] [2], some suggestions raised that those kind of change need microversion bump which is fine however, another concern raised on whether we need combine a set of those kind of changes (which may only change some error code) into one bump ? apparently there are pros and cons for doing so, combine makes API version bump not that frequent for minor changes but makes it hard to review and backport ... so any suggestions on how to handle ? Thanks [1]https://review.openstack.org/#/c/198753/ [2]https://review.openstack.org/#/c/173985/ Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I don't see why https://review.openstack.org/#/c/198753/ would require a microversion bump. We've always allowed handling 500s and turning them into more appropriate error codes, like a 400 in this case. As noted: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html Changing an error response code to be more accurate. is generally acceptable. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] binding information for networks
Hello all, Recently i have came across two use cases that having binding information, or metadata for networks can be useful. (similar to the port binding profile for that matter) For example: 1) In project Kuryr we want to have a binding information which maps the Neutron network to docker network (And we might want to do it prior to the docker network being created, that is assign a network that is ready to be attached) so this field also needs to be editable (just like the port binding profile) 2) For multi site OpenStack (multi cloud) use cases we might want to share information which binds logically same network that is created at each OpenStack cloud site (and hence the ID's are different). (Something like this could be useful for project Tricircle for example) 3) Use cases for multi controllers environments? (each controller manage different networks?) I believe adding such optional field to the network API is really low risk due to its being optional and i believe other use cases can be found to leverage it. Feel free to share ideas/comments. If there are no strong objections to it, i will add an RFE/Spec to add this ability. Thanks Gal. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] binding information for networks
On Wed, Aug 19, 2015 at 2:34 PM, Gal Sagie gal.sa...@gmail.com wrote: Hello all, Recently i have came across two use cases that having binding information, or metadata for networks can be useful. (similar to the port binding profile for that matter) For example: 1) In project Kuryr we want to have a binding information which maps the Neutron network to docker network (And we might want to do it prior to the docker network being created, that is assign a network that is ready to be attached) so this field also needs to be editable (just like the port binding profile) 2) For multi site OpenStack (multi cloud) use cases we might want to share information which binds logically same network that is created at each OpenStack cloud site (and hence the ID's are different). (Something like this could be useful for project Tricircle for example) 3) Use cases for multi controllers environments? (each controller manage different networks?) I believe adding such optional field to the network API is really low risk due to its being optional and i believe other use cases can be found to leverage it. I wonder if we should just add a key/pair tuples tags or metadata generic field instead. There's been similar requests floating about that could also use a place to dump their data in. Feel free to share ideas/comments. If there are no strong objections to it, i will add an RFE/Spec to add this ability. Thanks Gal. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.com wrote: Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. The only action items for Neutron developers that I can spot are: 1. Linux bridge + DVR / multi host 2. Prevent data loss when restarting the OVS agent (The patch [1] is very close to merge anyway, nothing more to do here) 3. Work as described by [2] (Big deployers team) The rest is either polling (Who uses what feature / plugin / etc) or generic comments with no actionable bugs or RFEs. Did I miss anything? [1] https://review.openstack.org/#/c/182920/ [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases Cheers, Edgar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
Actually, there were very few requirements collected. So, your summary is correct. I feel that this time we did not get a lot of input s we got during the Ops meet-up in Philadelphia. I also recommend to read the burning issues ether pads, there are few suggestions on the networking side. Actually, I believe Operators has expressed in this session some good feedback that they probaly did not want to repeat during the networking section. https://etherpad.openstack.org/p/PAO-ops-burning-issues Cheers, Edgar From: Assaf Muller Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Wednesday, August 19, 2015 at 1:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote: Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. The only action items for Neutron developers that I can spot are: 1. Linux bridge + DVR / multi host 2. Prevent data loss when restarting the OVS agent (The patch [1] is very close to merge anyway, nothing more to do here) 3. Work as described by [2] (Big deployers team) The rest is either polling (Who uses what feature / plugin / etc) or generic comments with no actionable bugs or RFEs. Did I miss anything? [1] https://review.openstack.org/#/c/182920/ [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases Cheers, Edgar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel][puppet] The state of collaboration: 9 weeks
Dmitry, I've appreciated the feedback on my patches from your team and the work they are doing, it's great that everyone is working together better now. I think getting more puppet core reviewers is certainly on the horizon and will happen with continued effort, it just takes time and trust. But its on the radar to use a analogy. As for your specific issue with the swift patch, I don't know enough about ring builder to decide whether the author or the swift reviewer is right so I was hoping he (the swift core) would follow-up to your comment. The puppet code itself is fine. I've also asked someone on my team who is a swift expert (but not a puppet core) to take a look and weigh-in. I don't know what our official policy is, but I would expect your author to reach out to the person who left the -1 and attempt to resolve it with them before one of us would essentially override the -1. On Tue, Aug 18, 2015 at 12:33 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Two weeks ago, I flagged the patch sets to commits ratio as the biggest problem that Fuel contributors to Puppet OpenStack should address, and over the past two weeks the situation has improved dramatically. In first and second week of August, 19 of our commits were merged in upstream, bringing our patch sets per commit ratio from 19 down to 5.6 (while average for Puppet OpenStack during that period was 6.5). With the share of patch sets pushed by Fuel developers remaining at roughly the same level (15.9% vs 17.4%), I think it's safe to call this problem solved. Simply awesome! Comparing last 30 days contribution stats vs same numbers two weeks ago: Bogdan Dobrelia (#3 reviewer!): 67.2% - 66.3% (disagreements 4.9% - 3.6%) Denis Egorenko: 97% - 87.5% (disagreements 12.1% - 13.9%) Vasyl Saienko: 100% - 96.4% (disagreements 16.7% - 10.7%) Ivan Berezovskiy: 100% - 92.3% (disagreements 0% - 3.8%) Sergey Kolekonov: 91.7% - 95.7% (disagreements 8.3% - 13%) Max Yatsenko: n/a - 100% (disagreements n/a - 17.4%) Alex Schultz: 80% - 80% (disagreements 20% - 26.7%) Bartlomiej Piotrowski: n/a - 100% (disagreements n/a - 12.5%) Sergii Golovatiuk: 100% - 100% (disagreements 33.3% - 0%) Bogdan continues to set the example and improve his numbers, which is not surprising considering that he's also the top reviewer in fuel-library. I think puppet-nova and puppet-neutron teams should seriously consider nominating him for core, he already tops reviewers lists for these modules. Denis, Vasyl, and Ivan are not there yet, but they all have noticeably increased both number and quality of their reviews, keep it up guys! Numbers for other top reviewers are uneven and small enough for noise to overtake meaningful data, all I can recommend here is to watch your disagreements and learn from them. A ratio above 10% can mean one of three things: 1) you're not doing enough reviews so even a handful of disagreements sticks out -- do more reviews and this will improve on its own; 2) you're missing problems with the code that other reviewers find unacceptable -- try to be more attentive and watch for the things that you've been missing; 3) you disagree with majority on how some things should be done -- discuss your differences on IRC or ML and figure out a consensus. Moving on to other numbers, weekly IRC meetings participation remains good: Aug-4: 4 of 15 participants, 22 of 162 lines Aug-11: 6 of 16 participants, 62 of 192 lines Unfortunately it's not all roses and unicorns, last week I flagged a stuck review that I think has been mishandled by Puppet OpenStack team [0][1], and it still remains in the same state. [0] https://review.openstack.org/198695 [1] http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-11-15.00.log.html#l-140 On July 8, patch set 2 has passed CI. It received 2 +1 votes from other Fuel developers on July 10 and 29, but remained ignored by upstream reviewers until August 10, more than a month after the current patch set was posted. Then, a Swift core reviewer left a -1 disagreeing with the intent of the patch, and even though patch author posted a rebuttal a day later, the patch remains stuck and untouched for yet another week. It's a one-off case that does not outweigh the positive trends I've outlined above, but even one stuck patch that fixes a critical bug is enough to justify a fork. Speaking of forks, we managed to un-fork 9 upstream modules [2] with puppet-librarian-simple before Fuel 7.0 soft code freeze has kicked in. [2] https://github.com/stackforge/fuel-library/blob/master/deployment/Puppetfile That's 9 times more than my conservative estimate of converting at least 1 module to librarian in 7.0, but these were the easiest and least deviated from upstream. We've still got 50 more modules to convert in Fuel 8.0, many will require commits to be merged in upstream before they can be completely un-forked. Having such commits wait for a
[openstack-dev] [Neutron] Etherpad from the Ops Meetup
Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. Cheers, Edgar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel][puppet] The state of collaboration: 9 weeks
Matt, I appreciate that it has barely been 2 months since we've started following the new model of collaboration (see thread subject :), so the intent of highlighting Bogdan's work was exactly what you said: put it on your radar. We have discussed the swift ring rebalance patch in the IRC meeting yesterday: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-18-15.00.log.html#l-108 You've now confirmed what Emilien said in the meeting: core reviewers in puppet-swift don't know enough about ring rebalance to judge this patch on their own, and need an expert opinion from Swift team. That's totally fine in my book and I don't have any issue with that. I also don't have an issue with the -1 that's still outstanding: it's a valid concern and it was good to raise it. I think Alex has addressed it in his rebuttal, and now it needs two more votes to move forward: a comment from a Puppet expert to confirm or disprove Alex's statement that his code is idemptotent and will not spuriously trigger rebalance when it's not needed, and one more from Christian to confirm that the idempotency assurance is sufficient to address his concern. My problem was that it took a month and two escalations on weekly IRC meeting and another one here before this situation was explained. A better way to handle this would have been to leave a +1 (or even 0) with a comment along the lines of Puppet code looks good, but we need a Swift expert to confirm this, Christian please have a look. In other words, it never hurts to over-communicate :) Thanks, -DmitryB On Wed, Aug 19, 2015 at 11:47 AM Matt Fischer m...@mattfischer.com wrote: Dmitry, I've appreciated the feedback on my patches from your team and the work they are doing, it's great that everyone is working together better now. I think getting more puppet core reviewers is certainly on the horizon and will happen with continued effort, it just takes time and trust. But its on the radar to use a analogy. As for your specific issue with the swift patch, I don't know enough about ring builder to decide whether the author or the swift reviewer is right so I was hoping he (the swift core) would follow-up to your comment. The puppet code itself is fine. I've also asked someone on my team who is a swift expert (but not a puppet core) to take a look and weigh-in. I don't know what our official policy is, but I would expect your author to reach out to the person who left the -1 and attempt to resolve it with them before one of us would essentially override the -1. On Tue, Aug 18, 2015 at 12:33 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Two weeks ago, I flagged the patch sets to commits ratio as the biggest problem that Fuel contributors to Puppet OpenStack should address, and over the past two weeks the situation has improved dramatically. In first and second week of August, 19 of our commits were merged in upstream, bringing our patch sets per commit ratio from 19 down to 5.6 (while average for Puppet OpenStack during that period was 6.5). With the share of patch sets pushed by Fuel developers remaining at roughly the same level (15.9% vs 17.4%), I think it's safe to call this problem solved. Simply awesome! Comparing last 30 days contribution stats vs same numbers two weeks ago: Bogdan Dobrelia (#3 reviewer!): 67.2% - 66.3% (disagreements 4.9% - 3.6%) Denis Egorenko: 97% - 87.5% (disagreements 12.1% - 13.9%) Vasyl Saienko: 100% - 96.4% (disagreements 16.7% - 10.7%) Ivan Berezovskiy: 100% - 92.3% (disagreements 0% - 3.8%) Sergey Kolekonov: 91.7% - 95.7% (disagreements 8.3% - 13%) Max Yatsenko: n/a - 100% (disagreements n/a - 17.4%) Alex Schultz: 80% - 80% (disagreements 20% - 26.7%) Bartlomiej Piotrowski: n/a - 100% (disagreements n/a - 12.5%) Sergii Golovatiuk: 100% - 100% (disagreements 33.3% - 0%) Bogdan continues to set the example and improve his numbers, which is not surprising considering that he's also the top reviewer in fuel-library. I think puppet-nova and puppet-neutron teams should seriously consider nominating him for core, he already tops reviewers lists for these modules. Denis, Vasyl, and Ivan are not there yet, but they all have noticeably increased both number and quality of their reviews, keep it up guys! Numbers for other top reviewers are uneven and small enough for noise to overtake meaningful data, all I can recommend here is to watch your disagreements and learn from them. A ratio above 10% can mean one of three things: 1) you're not doing enough reviews so even a handful of disagreements sticks out -- do more reviews and this will improve on its own; 2) you're missing problems with the code that other reviewers find unacceptable -- try to be more attentive and watch for the things that you've been missing; 3) you disagree with majority on how some things should be done -- discuss your differences on IRC or ML and figure out a consensus. Moving on to
Re: [openstack-dev] [Neutron][fwaas] APAC friendly meeting
OK - UTC sounds good to me, so if anyone is available we can conduct the meeting this week - so in about 5 hours? I'll push an update to the ircmeetings repo. I think it'll be a light agenda from my end due to my last minute decision, but it'll at least give everyone time to say hello and bring up anything they've wanted to discuss. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Update on Angular Identity work
Hi Lin,I agree with you and Eric that we have a lot of HTML fragments. Some of them I think make sense as directives:The table footer is a good example of something we can convert into a directive:https://review.openstack.org/#/c/207631/The table header on the other hand is something more specific to your table:https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table/table-header.htmlSo there are two approaches we can take here:1. Keep some of the presentation related data in the HTML: mainly things like table headers, column definitions, translated texts, etc... I like this approach a bit more because it allow us to read the HTML and know exactly what we are expecting to see. This table.html is compose of smaller directives like hz-table-footer and regular html tags like th and td etc... I think as we have more of these smaller directives available, we can combine the fragments into one file.2. We could create a more general table directive with a common template. This is more inline with what we have currently for legacy. BUT the presentation logic like translations, definitions would now have to reside in the table controller AND we lose the semantic readability part. Doing it this way could potentially introduce more complexity as it now requires people to learn the table directive, which could be very complex if it does not use smaller directives. Another common problem we encountered with this pattern was a lack of customization. In legacy, it was pretty hard to add an icon into a table cell. If we go down this route, I believe we might start to encounter the same issues.In summary, we are working on addressing the HTML fragments, but I think we as a community should go with option 1 and stay away from option 2.-Lin Hua Cheng os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 08/18/2015 02:36PMCc: Vince Brunssen/Austin/IBM@IBMUSSubject: Re: [openstack-dev] [Horizon] Update on Angular Identity workI think the table setup pattern have some opportunity for reducing code duplication before it gets re-used by other panels.. We used to just need to write one file to define a table, now we have to write 9 files [1]. Can we have a table directive to reduce the duplicated code before moving forward to other panels?-Lin[1] https://github.com/openstack/horizon/tree/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/tableOn Tue, Aug 18, 2015 at 11:49 AM, Thai Q Tran tqt...@us.ibm.com wrote:Hi everyone,Just wanted to keep everyone up to date on the angular panels work. The goal was to set a pattern that others can follow, to that end, there were a few requirements:1. reusable and possibly pluggable2. easy to understand3. reduce code duplicationThese requirements don't always go hand-in-hand, and that is the primary reason why it is taking a bit longer. I believe we are nearing the end of it, here are some items remaining that I believe is crucial to finishing up this work.a. i18n was completed, so we need help moving gettext blobs to HTML templates (example patch:https://review.openstack.org/#/c/210366/ ) volunteers are welcomed! We want others to use the translate directive as the main way to translate text blobs, this was why we went down this road using babel and angular_extractor plugin.b. transfer table supports clone feature ( https://review.openstack.org/#/c/211345/). There were a lot of template duplications, this clone feature reduces the HTML by a considerable amount. Since this is something we use quite often, it made sense to invest time into improving it. We have had complaints that there was too much HTML fragments, this will address a bit of that. One of the challenge was to get it working with existing launch-instance, so I spent about 2 weeks making sure it worked well with the old code while allowing the new clone feature.c. I believe we have a pretty good pattern setup for tables. The final piece of the puzzle was the patterns for various actions. We have wizard (create user), form (edit user), confirmation dialog (delete user), and actions with no modal dialog (enable user). We wanted a general pattern that would address the requirements mentioned above. There were some discussions around extensibility at the midcycle that I think will fit well here as well ( https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ). The actions can follow a similar pattern to workflow. I believe this pattern would address #1 and #3 but making it easy to understand is a bit challenging - I think this is where documentation could help.https://review.openstack.org/#/c/202315/ and a few other patches are going to be ready for review soon (sometime end of this week)!Item #c is the most important piece, it is going to be the general pattern that people will use to build their
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 8/19/2015 1:33 PM, Matt Riedemann wrote: On 8/19/2015 12:18 PM, Chen CH Ji wrote: In doing [1] [2], some suggestions raised that those kind of change need microversion bump which is fine however, another concern raised on whether we need combine a set of those kind of changes (which may only change some error code) into one bump ? apparently there are pros and cons for doing so, combine makes API version bump not that frequent for minor changes but makes it hard to review and backport ... so any suggestions on how to handle ? Thanks [1]https://review.openstack.org/#/c/198753/ [2]https://review.openstack.org/#/c/173985/ Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I don't see why https://review.openstack.org/#/c/198753/ would require a microversion bump. We've always allowed handling 500s and turning them into more appropriate error codes, like a 400 in this case. As noted: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html Changing an error response code to be more accurate. is generally acceptable. https://review.openstack.org/#/c/173985/ doesn't require a version bump for the same reasons, IMO. If people are hung up on 400 vs 403 in that change, just make it a 400, we do it both ways in the compute API. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2
On 20 August 2015 at 01:42, Sean Dague s...@dague.net wrote: Sorry about jumping the gun there. We thought, incorrectly, we had the right fix. And it's a conference week so access to my local test env wasn't easy. No worries - these things happen. Having higher fidelity tests would give some more insulation - perhaps not gating though - e.g. a non-cached non-voting nodepool job that looks very much like a local developer experience. And then one of those for Ubuntu and Fedora (and any other commonly used platforms we wish to support developers using). FWIW I think the fix for the specific issue should be to not install the python-cffi package, but I couldn't trivially figure out what was triggering the install. Not installing it would make devstack on Fedora faster (since we're still installing the thing from PyPI as well..) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
One thing came up during lunch was including unit and functional testing of dual stack in the check and gate queues - I was regaled over lunch with one operator's experiences in trying to run Neutron on a dual stack system. Ryan Moats (regXboi) Edgar Magana edgar.mag...@workday.com wrote on 08/19/2015 03:43:44 PM: From: Edgar Magana edgar.mag...@workday.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/19/2015 03:44 PM Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup Actually, there were very few requirements collected. So, your summary is correct. I feel that this time we did not get a lot of input s we got during the Ops meet-up in Philadelphia. I also recommend to read the burning issues ether pads, there are few suggestions on the networking side. Actually, I believe Operators has expressed in this session some good feedback that they probaly did not want to repeat during the networking section. https://etherpad.openstack.org/p/PAO-ops-burning-issues Cheers, Edgar From: Assaf Muller Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Wednesday, August 19, 2015 at 1:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.com wrote: Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. The only action items for Neutron developers that I can spot are: 1. Linux bridge + DVR / multi host 2. Prevent data loss when restarting the OVS agent (The patch [1] is very close to merge anyway, nothing more to do here) 3. Work as described by [2] (Big deployers team) The rest is either polling (Who uses what feature / plugin / etc) or generic comments with no actionable bugs or RFEs. Did I miss anything? [1] https://review.openstack.org/#/c/182920/ [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases Cheers, Edgar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
On Wed, Aug 19, 2015 at 05:11:55PM EDT, Ryan Moats wrote: One thing came up during lunch was including unit and functional testing of dual stack in the check and gate queues - I was regaled over lunch with one operator's experiences in trying to run Neutron on a dual stack system. We are testing dual stack https://review.openstack.org/#/c/160856/ Have they found gaps in our coverage? -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [packaging] asks from the ops meetup
I'll start by giving this out, but I'll also summarize the asks we had from upstream. https://etherpad.openstack.org/p/PAO-ops-packaging General services: - gate check on example config and doc generation - was mentioned this has broken in the past and taken a while to fix - document dependencies needed for config/doc generation - (not all of test requirements) - generated example configs generated and stored in an automated way - (in lieu of packagers generating the configs dynamically) - A place to look for files that go in /etc - Publish pip-freeze at the end - Don't strip out files in the repo when publishing to pip - Publish an example init-script (systemd) - I think this might be going away with wsgi Docs: - nginx wsgi examples -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [app-catalog] IRC Meeting Thursday August 20th at 17:00UTC
Howdy! Our next OpenStack App Catalog meeting will take place this Thursday August 20th at 17:00 UTC in #openstack-meeting-3 The agenda can be found here: https://wiki.openstack.org/wiki/Meetings/app-catalog Please add agenda items if there's anything specific you would like to discuss (or of course if the meeting time is not convenient for you join us on IRC #openstack-app-catalog). Please join us if you can! -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] contextlib.nested and Python3 failing
Hi, I was writing some tests so I added a contextlib.nested to a checked TestCase [1]. Unfortunately, contextlib.nested is no longer available in Python3 and there is no clear solution on how to provide a compatible import for both python2 and python3: - either providing a python3 compatible behaviour by using contextlib.ExitStack but that class is not available in Python 2 - or provide contextlib2 for python2 (and thus adding it to the requirements) That sounds really disruptive and blocking as we are close to the FeatureFreeze. Many other users of contextlib.nested are not impacted by the job because it excludes all of them but since the test I'm changing is part of the existing validated tests, that leaves Jenkins -1'ing my change. Of course, a 3rd solution would consist of excluding my updated test from the python3 check but I can hear others yelling at that :-) Ideas appreciated. -Sylvain [1] https://review.openstack.org/#/c/199205/18/nova/tests/unit/scheduler/test_rpcapi.py,cm __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
On 08/19/2015 05:29 PM, Ryan Moats wrote: They didn't mention a release by name, so I think it may be fair that they were testing pre-kilo - I'll take the action item to follow up with them... Ryan Sean M. Collins s...@coreitpro.com wrote on 08/19/2015 04:25:22 PM: From: Sean M. Collins s...@coreitpro.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/19/2015 04:26 PM Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup On Wed, Aug 19, 2015 at 05:11:55PM EDT, Ryan Moats wrote: One thing came up during lunch was including unit and functional testing of dual stack in the check and gate queues - I was regaled over lunch with one operator's experiences in trying to run Neutron on a dual stack system. We are testing dual stack https://review.openstack.org/#/c/160856/ Have they found gaps in our coverage? -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Some of the issue was that DVR wasn't (not sure if it still isn't) tested in a multi-node setup. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
On 19/08/15 11:52, Edgar Magana wrote: Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. Line 28 on https://etherpad.openstack.org/p/PAO-ops-deployment-tips also has some stuff on networking __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
They didn't mention a release by name, so I think it may be fair that they were testing pre-kilo - I'll take the action item to follow up with them... Ryan Sean M. Collins s...@coreitpro.com wrote on 08/19/2015 04:25:22 PM: From: Sean M. Collins s...@coreitpro.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/19/2015 04:26 PM Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup On Wed, Aug 19, 2015 at 05:11:55PM EDT, Ryan Moats wrote: One thing came up during lunch was including unit and functional testing of dual stack in the check and gate queues - I was regaled over lunch with one operator's experiences in trying to run Neutron on a dual stack system. We are testing dual stack https://review.openstack.org/#/c/160856/ Have they found gaps in our coverage? -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
Folks Why not enable it as an experimental? On Wed, Aug 19, 2015 at 12:20 PM, Mikhail Semenov mseme...@mirantis.com wrote: As we considered today, Ubuntu bootstrap will not be shipped in MOS 7.0. It was a hard decision based on the issue with NICs naming [1]. This bug can be fixed only by changing the naming of network interfaces( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) and it's too late to do it in MOS 7.0 scope. So, this feature is moved to MOS 8.0. [1] https://bugs.launchpad.net/mos/+bug/1482049 -- Thanks, Michael On Thu, Aug 13, 2015 at 6:30 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here https://review.openstack.org/#/c/194154/. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu ( http://archive.ubuntu.com/ubuntu) and MOS ( http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: *fuel-bootstrap-image-set ubuntu* 3. Just in a case restart dnsmasq: *dockerctl shell cobbler service dnsmasq restart* 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for *partners* *and* *plugin developers*. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael -- Thanks, Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
As it simply has blocking bugs, and so it can't even be called experimental, only prototype. I don't vote though for reverting the code. I just want to ensure that we don't recommend it to anyone except other developers, who want to try it and may be propose some fixes. On Wed, Aug 19, 2015 at 3:56 PM Vladimir Kuklin vkuk...@mirantis.com wrote: Folks Why not enable it as an experimental? On Wed, Aug 19, 2015 at 12:20 PM, Mikhail Semenov mseme...@mirantis.com wrote: As we considered today, Ubuntu bootstrap will not be shipped in MOS 7.0. It was a hard decision based on the issue with NICs naming [1]. This bug can be fixed only by changing the naming of network interfaces( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) and it's too late to do it in MOS 7.0 scope. So, this feature is moved to MOS 8.0. [1] https://bugs.launchpad.net/mos/+bug/1482049 -- Thanks, Michael On Thu, Aug 13, 2015 at 6:30 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here https://review.openstack.org/#/c/194154/. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu ( http://archive.ubuntu.com/ubuntu) and MOS ( http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: *fuel-bootstrap-image-set ubuntu* 3. Just in a case restart dnsmasq: *dockerctl shell cobbler service dnsmasq restart* 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for *partners* *and* *plugin developers*. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael -- Thanks, Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-project meeting times
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That makes it 4am for me, so I'm out :( L On 20/08/15 01:39, Morgan Fainberg wrote: I am ok with this moving as long as it doesn't camp on the Keystone meeting time ;). In all seriousness I'm not opposed to moving the meeting if it will include more people / make lives better for those who are there. Sent via mobile On Aug 19, 2015, at 08:20, Sean Dague s...@dague.net wrote: +1 for moving it earlier. On August 19, 2015 6:17:06 AM PDT, Anne Gentle annegen...@justwriteclick.com wrote: Hi all, In last week's TC Highlights blog post [1] I asked if there is interest in moving the cross-project meeting. Historically it is held after the TC meeting, but there isn't a requirement for those timings to line up. I've heard from European and Eastern Standard Time contributors that it's a tough time to meet half the year. It's also a bit early for APAC, my apologies for noting this but still proposing to meet earlier. I'd like to propose a new cross-project meeting time, 1800 Tuesdays. To that end I've created a review with the proposed time: https://review.openstack.org/214605 Please take a look, see if you think it could work, and let us know either on this list or the review itself. Thanks, Anne 1. http://www.openstack.org/blog/2015/08/technical-committee-highlights-august-11-2015/ -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV1QFZAAoJELppzVb4+KUyAysIAKIbbgv9q2PGOMyHYMM4rzen U1MNUJsFJ+zeXkLedRQYOTYOGEtevLph/3DuPku4BdoyjvDSRc6O5GsWI371SjSw +6CLtImy4qKyPbEVt1O6hKArjDQDzjv2y/VJUcumm9/5J/k144QLxYebYwXpMKdw o0bYL1bjtVAMInTegodywdGA4zIcc5lQ6XDbgJOfhI9rs/D1nol0w9sOe7WS7puK cGxh3fiH9pJFlXmkEyL3kXqZ6plVgTEHTeoV5/T8IEBH72QpsdwTqn74f0pllW6r 6mwhUK+MeP3Omk8QgNNDOvA9DOCPUZSfgnYFEgAeG4zFCBWn6nH6MYu+ykIBwEg= =qTHO -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
Mikhail, thanks for the update. I'm glad that we have an agreement here, and collaborative decision have been made not to enable something in 7.0 which is proven to be not yet production ready, such late in the release cycle. I'm all for completing this work in 8.0 though. Can you please: - provide an answer on UX, question which I asked in separate email in this same thread - don't even mention MOS going further (neither in subject nor in email), as we are discussing and working with Fuel code here Thank you, On Wed, Aug 19, 2015 at 10:20 AM Mikhail Semenov mseme...@mirantis.com wrote: As we considered today, Ubuntu bootstrap will not be shipped in MOS 7.0. It was a hard decision based on the issue with NICs naming [1]. This bug can be fixed only by changing the naming of network interfaces( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) and it's too late to do it in MOS 7.0 scope. So, this feature is moved to MOS 8.0. [1] https://bugs.launchpad.net/mos/+bug/1482049 -- Thanks, Michael On Thu, Aug 13, 2015 at 6:30 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here https://review.openstack.org/#/c/194154/. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu ( http://archive.ubuntu.com/ubuntu) and MOS ( http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: *fuel-bootstrap-image-set ubuntu* 3. Just in a case restart dnsmasq: *dockerctl shell cobbler service dnsmasq restart* 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for *partners* *and* *plugin developers*. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael -- Thanks, Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
The etherpad contains some complaints around DVR implementation that might deserve furhter exploration. However, as pointed out by Jay, the comments made leave very little room for actionable items. It would be great if the author(s) could fill in with more details. Salvatore On 19 August 2015 at 23:11, Ryan Moats rmo...@us.ibm.com wrote: One thing came up during lunch was including unit and functional testing of dual stack in the check and gate queues - I was regaled over lunch with one operator's experiences in trying to run Neutron on a dual stack system. Ryan Moats (regXboi) Edgar Magana edgar.mag...@workday.com wrote on 08/19/2015 03:43:44 PM: From: Edgar Magana edgar.mag...@workday.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/19/2015 03:44 PM Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup Actually, there were very few requirements collected. So, your summary is correct. I feel that this time we did not get a lot of input s we got during the Ops meet-up in Philadelphia. I also recommend to read the burning issues ether pads, there are few suggestions on the networking side. Actually, I believe Operators has expressed in this session some good feedback that they probaly did not want to repeat during the networking section. https://etherpad.openstack.org/p/PAO-ops-burning-issues Cheers, Edgar From: Assaf Muller Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Wednesday, August 19, 2015 at 1:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.com wrote: Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. The only action items for Neutron developers that I can spot are: 1. Linux bridge + DVR / multi host 2. Prevent data loss when restarting the OVS agent (The patch [1] is very close to merge anyway, nothing more to do here) 3. Work as described by [2] (Big deployers team) The rest is either polling (Who uses what feature / plugin / etc) or generic comments with no actionable bugs or RFEs. Did I miss anything? [1] https://review.openstack.org/#/c/182920/ [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases Cheers, Edgar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Kuryr - virtual sprint
Hi Gal, even if I've been a lurker so far, I'm interested in attending for learning and contributing to it with my massive bug-injecting skills! You said virtual sprint and somewhere in september - I think somewhere refers to dates? Anyway I am pretty much open to any date from September 7th onwards. Salvatore On 19 August 2015 at 19:57, Gal Sagie gal.sa...@gmail.com wrote: Hello everyone, During our last meeting an idea was brought up that we try to do a virtual sprint for Kuryr somewhere in September. Basically the plan is very similar to the mid cycle sprints or feature sprints where we iterate on couple of tasks online and finish gaps we might have in Kuryr. (I think we are talking about 2-3 days) The agenda for the sprint is dependent on the amount of work we finish by then, but it will probably consist of containerising some of the common plugins and connecting things end to end. (for host networking) I started this email in order to find the best dates for it, so if you plan on participating please share your preferred dates (anyone that has a Neutron plugin might want to offer a containerised version of it with Kuryr to integrate with Docker and lib network and the sprint is probably a good place to start doing it) Thanks Gal. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-ansible][keystone] Federation beyond Shibboleth
On 08/19/2015 04:23 AM, Jesse Pretorius wrote: On 12 August 2015 at 18:48, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: The simplest one is Kerberos + SSSD; Kerberos provides Authentication. mod_lookup_identity uses SSSD to get Groups. It turns LDAP into another Federated identity, much simpler than the LDAP code in Keystone (I am responsible for that mess). We are working on automating this via Ansible on top of a RHEL/Centos 7 install to demo in Tokyo. I am not certain if all the pieces are in place yet for Debian based install. Specifically, it needs an updated sssd-dbus package. We also have mod_mellon and Ipsilon working, as Jamie demo'ed at Pycon AU. Sounds great! Would you be prepared to put together some WIP reviews to add those to the Keystone role in openstack-ansible? Even if they're non-working sketches that we can work from and iterate on, that'd be great. Our sample code is here: https://github.com/jamielennox/rippowam I wrote up a README for what we are doing: https://github.com/admiyo/rippowam/blob/master/README.rst The stuff you care about is here: Setting up SSSD https://github.com/jamielennox/rippowam/blob/master/roles/packstack/tasks/infopipe.yml And https://github.com/jamielennox/rippowam/blob/master/roles/packstack/tasks/keystone-sssd.yml Note that we're looking at implementing some changes to broaden the platform support too. We're moving some of the pieces into place for the liberty [1] release and I'll be putting my thoughts down on multi-platform host enablement [2] soon. Also, considering that it'd be easier to comprehend, consume and iterate the ansible roles if they were independent consumable units I've also proposed [3][4] to break them out into their own repositories. It'd be great if you could provide your input. [1] https://blueprints.launchpad.net/openstack-ansible/+spec/liberty [2] https://blueprints.launchpad.net/openstack-ansible/+spec/multi-platform-host [3] https://blueprints.launchpad.net/openstack-ansible/+spec/independent-role-repositories [4] https://review.openstack.org/213779 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup
To expand on that a bit, I think the DVR complaints were vague because of the simple fact that the overwhelming majority were or wanted to run linuxbridge, not OVS, so DVR was a theoretical thing for them. doug On Aug 19, 2015, at 2:21 PM, Salvatore Orlando salv.orla...@gmail.com wrote: The etherpad contains some complaints around DVR implementation that might deserve furhter exploration. However, as pointed out by Jay, the comments made leave very little room for actionable items. It would be great if the author(s) could fill in with more details. Salvatore On 19 August 2015 at 23:11, Ryan Moats rmo...@us.ibm.com mailto:rmo...@us.ibm.com wrote: One thing came up during lunch was including unit and functional testing of dual stack in the check and gate queues - I was regaled over lunch with one operator's experiences in trying to run Neutron on a dual stack system. Ryan Moats (regXboi) Edgar Magana edgar.mag...@workday.com mailto:edgar.mag...@workday.com wrote on 08/19/2015 03:43:44 PM: From: Edgar Magana edgar.mag...@workday.com mailto:edgar.mag...@workday.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: 08/19/2015 03:44 PM Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup Actually, there were very few requirements collected. So, your summary is correct. I feel that this time we did not get a lot of input s we got during the Ops meet-up in Philadelphia. I also recommend to read the burning issues ether pads, there are few suggestions on the networking side. Actually, I believe Operators has expressed in this session some good feedback that they probaly did not want to repeat during the networking section. https://etherpad.openstack.org/p/PAO-ops-burning-issues https://etherpad.openstack.org/p/PAO-ops-burning-issues Cheers, Edgar From: Assaf Muller Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Wednesday, August 19, 2015 at 1:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.com mailto:edgar.mag...@workday.com wrote: Folks, I just want to share with you the feedback collected today during the networking session on Ops Meet-up: https://etherpad.openstack.org/p/PAO-ops-network-model https://etherpad.openstack.org/p/PAO-ops-network-model Special thanks to Ryan and Doug for helping on some questions. The only action items for Neutron developers that I can spot are: 1. Linux bridge + DVR / multi host 2. Prevent data loss when restarting the OVS agent (The patch [1] is very close to merge anyway, nothing more to do here) 3. Work as described by [2] (Big deployers team) The rest is either polling (Who uses what feature / plugin / etc) or generic comments with no actionable bugs or RFEs. Did I miss anything? [1] https://review.openstack.org/#/c/182920/ https://review.openstack.org/#/c/182920/ [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases https://etherpad.openstack.org/p/Network_Segmentation_Usecases Cheers, Edgar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Update on Angular Identity work
Hi Thai, Thanks for investigating the two options. Option 2 might be better. Folks have to learn the new pattern of writing multiple files, so I think the learning curve for a new table directive is not that much of a difference. I think option 2 is going to be easier to maintain, since we have a layer of abstraction. It might even also increase adoptability since it would be easier to use. It might be harder to customize, but that would probably not be done often. The table directive would be used as is most of the time. My thought is design the code to be easy to use for the use case that will be used most of the time rather than the customization case which maybe harder to do. Which leads me to preferring option 2. Thanks, Lin On Wed, Aug 19, 2015 at 12:16 PM, Thai Q Tran tqt...@us.ibm.com wrote: Hi Lin, I agree with you and Eric that we have a lot of HTML fragments. Some of them I think make sense as directives: The table footer is a good example of something we can convert into a directive: https://review.openstack.org/#/c/207631/ The table header on the other hand is something more specific to your table: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table/table-header.html So there are two approaches we can take here: 1. Keep some of the presentation related data in the HTML: mainly things like table headers, column definitions, translated texts, etc... I like this approach a bit more because it allow us to read the HTML and know exactly what we are expecting to see. This table.html is compose of smaller directives like hz-table-footer and regular html tags like th and td etc... I think as we have more of these smaller directives available, we can combine the fragments into one file. 2. We could create a more general table directive with a common template. This is more inline with what we have currently for legacy. BUT the presentation logic like translations, definitions would now have to reside in the table controller AND we lose the semantic readability part. Doing it this way could potentially introduce more complexity as it now requires people to learn the table directive, which could be very complex if it does not use smaller directives. Another common problem we encountered with this pattern was a lack of customization. In legacy, it was pretty hard to add an icon into a table cell. If we go down this route, I believe we might start to encounter the same issues. In summary, we are working on addressing the HTML fragments, but I think we as a community should go with option 1 and stay away from option 2. -Lin Hua Cheng os.lch...@gmail.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Lin Hua Cheng os.lch...@gmail.com Date: 08/18/2015 02:36PM Cc: Vince Brunssen/Austin/IBM@IBMUS Subject: Re: [openstack-dev] [Horizon] Update on Angular Identity work I think the table setup pattern have some opportunity for reducing code duplication before it gets re-used by other panels.. We used to just need to write one file to define a table, now we have to write 9 files [1]. Can we have a table directive to reduce the duplicated code before moving forward to other panels? -Lin [1] https://github.com/openstack/horizon/tree/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table On Tue, Aug 18, 2015 at 11:49 AM, Thai Q Tran tqt...@us.ibm.com wrote: Hi everyone, Just wanted to keep everyone up to date on the angular panels work. The goal was to set a pattern that others can follow, to that end, there were a few requirements: 1. reusable and possibly pluggable 2. easy to understand 3. reduce code duplication These requirements don't always go hand-in-hand, and that is the primary reason why it is taking a bit longer. I believe we are nearing the end of it, here are some items remaining that I believe is crucial to finishing up this work. a. i18n was completed, so we need help moving gettext blobs to HTML templates (example patch: https://review.openstack.org/#/c/210366/ ) volunteers are welcomed! We want others to use the translate directive as the main way to translate text blobs, this was why we went down this road using babel and angular_extractor plugin. b. transfer table supports clone feature ( https://review.openstack.org/#/c/211345/ ). There were a lot of template duplications, this clone feature reduces the HTML by a considerable amount. Since this is something we use quite often, it made sense to invest time into improving it. We have had complaints that there was too much HTML fragments, this will address a bit of that. One of the challenge was to get it working with existing launch-instance, so I spent about 2 weeks making sure it worked well with the old code while allowing the new clone feature. c. I believe we have a pretty
Re: [openstack-dev] [packaging] asks from the ops meetup
Questions in-line, but I'd appreciate a better summary On 8/19/15, 17:50, Matthew Thode prometheanf...@gentoo.org wrote: I'll start by giving this out, but I'll also summarize the asks we had from upstream. https://etherpad.openstack.org/p/PAO-ops-packaging General services: - gate check on example config and doc generation - was mentioned this has broken in the past and taken a while to fix The etherpad doesn't have much on this topic, could you (or someone else from the mid-cycle) expound on this? - document dependencies needed for config/doc generation - (not all of test requirements) So you want a doc-requirements.txt file? That doesn't have other libraries other than the documentation related ones? - generated example configs generated and stored in an automated way - (in lieu of packagers generating the configs dynamically) Don't most projects already do this? - A place to look for files that go in /etc Again, don't most projects have an etc/ directory inside of them? - Publish pip-freeze at the end At the end of what? - Don't strip out files in the repo when publishing to pip No services are published to PyPI. What is this about? - Publish an example init-script (systemd) This seems reasonable - I think this might be going away with wsgi What? Docs: - nginx wsgi examples Is nginx even supported in any of the services? If so, are we already gating on that? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] contextlib.nested and Python3 failing
haha :) -- dims On Wed, Aug 19, 2015 at 7:59 PM, Sylvain Bauza sba...@redhat.com wrote: Le 19/08/2015 16:51, Sylvain Bauza a écrit : Hi, I was writing some tests so I added a contextlib.nested to a checked TestCase [1]. Unfortunately, contextlib.nested is no longer available in Python3 and there is no clear solution on how to provide a compatible import for both python2 and python3: - either providing a python3 compatible behaviour by using contextlib.ExitStack but that class is not available in Python 2 - or provide contextlib2 for python2 (and thus adding it to the requirements) That sounds really disruptive and blocking as we are close to the FeatureFreeze. Many other users of contextlib.nested are not impacted by the job because it excludes all of them but since the test I'm changing is part of the existing validated tests, that leaves Jenkins -1'ing my change. Of course, a 3rd solution would consist of excluding my updated test from the python3 check but I can hear others yelling at that :-) Ideas appreciated. So, I just saw there is actually already a solution for that here: https://github.com/openstack/nova/blob/master/nova/test.py#L72-L78 beer_count['dims']++ Thanks, -Sylvain [1] https://review.openstack.org/#/c/199205/18/nova/tests/unit/scheduler/test_rpcapi.py,cm __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][cinder] Extending attached disks
Hi everyone,In my current pre-production deployment we were looking for a method to live extend attached volumes to an instance. This was one of the requirements for deployment. I've worked with libvirt hypervisors before so it didn't take long to find a workable solution. However I'm not sure how transferable this will be across deployment models. Our deployment model is using libvirt for nova and ceph for backend storage. This means obviously libvirt is using rdb to connect to volumes.Currently the method I use is:- Force cinder to run an extend operation.- Tell Libvirt that the attached disk has been extended.It would be worth discussing if this can be ported to upstream such that the API can handle the leg work, rather than this current manual method.Detailed instructions.You will need: volume-id of volume you want to resize, hypervisor_hostname and instance_name from instance volume is attached to.Example: extending volumef9fa66ab-b29a-40f6-b4f4-e9c64a155738 attached to instance-0012 on node-6 to 100GB$ cinder reset-state --state availablef9fa66ab-b29a-40f6-b4f4-e9c64a155738$ cinder extendf9fa66ab-b29a-40f6-b4f4-e9c64a155738 100$ cinder reset-state --state in-usef9fa66ab-b29a-40f6-b4f4-e9c64a155738$ssh node-6node-6$ virsh qemu-monitor-command instance-0012 --hmp "info block" | grep f9fa66ab-b29a-40f6-b4f4-e9c64a155738drive-virtio-disk1: removable=0 io-status=ok file=rbd:volumes-slow/volume-f9fa66ab-b29a-40f6-b4f4-e9c64a155738:id=cinder:key=keyhere==:auth_supported=cephx\\;none:mon_host=10.1.226.64\\:6789\\;10.1.226.65\\:6789\\;10.1.226.66\\:6789 ro=0 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0This will get you the disk-id, which in this case is drive-virtio-disk1.node-6$virsh qemu-monitor-command instance-0012 --hmp "block_resize drive-virtio-disk1 100G"Finally, you need to perform a drive rescan on the actual instance and resize and extend thefile-system. This will be OS specific.I've tested this a few times and it seems very reliable.Taylor BertieEnterprise Support Infrastructure EngineerMobile +64 27 952 3949Phone +64 4 462 5030Email taylor.ber...@solnet.co.nzSolnet Solutions LimitedLevel 12, Solnet House70 The Terrace, Wellington 6011PO Box 397, Wellington 6140www.solnet.co.nzAttention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmas...@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][cinder] Extending attached disks
Hi everyone, Apologises for the duplicate send, looks like my mail client doesn't create very clean HTML messages. Here is the message in plain-text. I'll make sure to send to the list in plain-text from now on. In my current pre-production deployment we were looking for a method to live extend attached volumes to an instance. This was one of the requirements for deployment. I've worked with libvirt hypervisors before so it didn't take long to find a workable solution. However I'm not sure how transferable this will be across deployment models. Our deployment model is using libvirt for nova and ceph for backend storage. This means obviously libvirt is using rdb to connect to volumes. Currently the method I use is: - Force cinder to run an extend operation. - Tell Libvirt that the attached disk has been extended. It would be worth discussing if this can be ported to upstream such that the API can handle the leg work, rather than this current manual method. Detailed instructions. You will need: volume-id of volume you want to resize, hypervisor_hostname and instance_name from instance volume is attached to. Example: extending volume f9fa66ab-b29a-40f6-b4f4-e9c64a155738 attached to instance-0012 on node-6 to 100GB $ cinder reset-state --state available f9fa66ab-b29a-40f6-b4f4-e9c64a155738 $ cinder extend f9fa66ab-b29a-40f6-b4f4-e9c64a155738 100 $ cinder reset-state --state in-use f9fa66ab-b29a-40f6-b4f4-e9c64a155738 $ssh node-6 node-6$ virsh qemu-monitor-command instance-0012 --hmp info block | grep f9fa66ab-b29a-40f6-b4f4-e9c64a155738 drive-virtio-disk1: removable=0 io-status=ok file=rbd:volumes-slow/volume-f9fa66ab-b29a-40f6-b4f4-e9c64a155738:id=cinder:key=keyhere==:auth_supported=cephx\\;none:mon_host=10.1.226.64\\:6789\\;10.1.226.65\\:6789\\;10.1.226.66\\:6789 ro=0 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 This will get you the disk-id, which in this case is drive-virtio-disk1. node-6$ virsh qemu-monitor-command instance-0012 --hmp block_resize drive-virtio-disk1 100G Finally, you need to perform a drive rescan on the actual instance and resize and extend the file-system. This will be OS specific. I've tested this a few times and it seems very reliable. Taylor Bertie Enterprise Support Infrastructure Engineer Mobile +64 27 952 3949 Phone +64 4 462 5030 Email taylor.ber...@solnet.co.nz Solnet Solutions Limited Level 12, Solnet House 70 The Terrace, Wellington 6011 PO Box 397, Wellington 6140 www.solnet.co.nz Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmas...@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs
Sounds great. Thank you Roman! I've heard complains about tests not passing for [1]. Now it's passed, so I hope that issues are resolved. [1] https://review.openstack.org/#/c/212906/ On Wed, Aug 19, 2015 at 10:51 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: Indeed, great news! I would only suggest to wait a little bit more that a few days with switching to the voting mode since it looks like there will be not so many patches proposed to python-fuelclient as we are heading towards Hard Code Freeze. I hope that the next step will be to enable Python 3 pipepline for our client so we could finally test all the code that uses six library for Python 2 3 compatibility. Best, Sebastian 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] Gerrit dashboard update: ready for core reviewers, disagreements
Thank you Dmitry, everyone can now open review inbox following [1]. Full link was also updated by Dmitry on main Fuel wiki page. [1] http://bit.ly/1LjYO4t On Wed, Aug 12, 2015 at 8:53 PM Cameron Seader cameron.sea...@suse.com wrote: test On 08/12/2015 07:16 PM, Dmitry Borodaenko wrote: Fuelers, I've proposed an update for the Fuel gerrit dashboard: https://review.openstack.org/212231 New Ready for Core Reviewers section encourages peer review by non-cores and allows cores to focus on reviews that already have +1 from other reviews and from CI. New Disagreements section highlights reviews that have both positive and negative code review votes. This worked out pretty well for Puppet OpenStack, lets try to use it in Fuel, too. The remaining sections are rearranged to exclude commits that match the two new sections. -- Dmitry Borodaenko __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cameron Seader Systems Engineer SUSE c...@suse.com (w)208-572-0095 (M)208-420-2167 Register for SUSECon 2015 www.susecon.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [packaging] asks from the ops meetup
On 08/19/2015 07:22 PM, Ian Cordasco wrote: Questions in-line, but I'd appreciate a better summary On 8/19/15, 17:50, Matthew Thode prometheanf...@gentoo.org wrote: I'll start by giving this out, but I'll also summarize the asks we had from upstream. https://etherpad.openstack.org/p/PAO-ops-packaging General services: - gate check on example config and doc generation - was mentioned this has broken in the past and taken a while to fix The etherpad doesn't have much on this topic, could you (or someone else from the mid-cycle) expound on this? Not sure, wasn't the one that brought it up, but a specific check on config/doc generation did seem like a good idea. - document dependencies needed for config/doc generation - (not all of test requirements) So you want a doc-requirements.txt file? That doesn't have other libraries other than the documentation related ones? Yes, though I think this may cover example config generation as well. - generated example configs generated and stored in an automated way - (in lieu of packagers generating the configs dynamically) Don't most projects already do this? iirc neutron at least does not - A place to look for files that go in /etc Again, don't most projects have an etc/ directory inside of them? yes, though files have been removed in favor of dynamic generation. The more specific ask was for this to be auto generated and updated, which we don't see as being done (could be wrong) - Publish pip-freeze at the end At the end of what? of a test/gerrit run - Don't strip out files in the repo when publishing to pip No services are published to PyPI. What is this about? Think this is more the bash autocomplete stuff - Publish an example init-script (systemd) This seems reasonable - I think this might be going away with wsgi What? the init scripts may be going away because of wsgi, it's be in apache or nginx or whatever Docs: - nginx wsgi examples Is nginx even supported in any of the services? If so, are we already gating on that? The docs give example configs for apache mod_wsgi, this was an ask for similiar with nginx. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] contextlib.nested and Python3 failing
On Aug 19, 2015, at 16:51, Sylvain Bauza sba...@redhat.com wrote: Ideas appreciated. Instead of using the nested context managers, a way I like is to decorate a nested function in the test and call it, for example: def test_thing(self): @mock.patch(...) @mock.patch(...) @mock.patch(...) def do_test(..., ..., ...): ... do_test() -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] Extending attached disks
On Wed, Aug 19, 2015 at 7:48 PM, taylor.ber...@solnet.co.nz wrote: Hi everyone, Apologises for the duplicate send, looks like my mail client doesn't create very clean HTML messages. Here is the message in plain-text. I'll make sure to send to the list in plain-text from now on. In my current pre-production deployment we were looking for a method to live extend attached volumes to an instance. This was one of the requirements for deployment. I've worked with libvirt hypervisors before so it didn't take long to find a workable solution. However I'm not sure how transferable this will be across deployment models. Our deployment model is using libvirt for nova and ceph for backend storage. This means obviously libvirt is using rdb to connect to volumes. Currently the method I use is: - Force cinder to run an extend operation. - Tell Libvirt that the attached disk has been extended. It would be worth discussing if this can be ported to upstream such that the API can handle the leg work, rather than this current manual method. Detailed instructions. You will need: volume-id of volume you want to resize, hypervisor_hostname and instance_name from instance volume is attached to. Example: extending volume f9fa66ab-b29a-40f6-b4f4-e9c64a155738 attached to instance-0012 on node-6 to 100GB $ cinder reset-state --state available f9fa66ab-b29a-40f6-b4f4-e9c64a155738 $ cinder extend f9fa66ab-b29a-40f6-b4f4-e9c64a155738 100 $ cinder reset-state --state in-use f9fa66ab-b29a-40f6-b4f4-e9c64a155738 $ssh node-6 node-6$ virsh qemu-monitor-command instance-0012 --hmp info block | grep f9fa66ab-b29a-40f6-b4f4-e9c64a155738 drive-virtio-disk1: removable=0 io-status=ok file=rbd:volumes-slow/volume-f9fa66ab-b29a-40f6-b4f4-e9c64a155738:id=cinder:key=keyhere==:auth_supported=cephx\\;none:mon_host=10.1.226.64\\:6789\\;10.1.226.65\\:6789\\;10.1.226.66\\:6789 ro=0 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 This will get you the disk-id, which in this case is drive-virtio-disk1. node-6$ virsh qemu-monitor-command instance-0012 --hmp block_resize drive-virtio-disk1 100G Finally, you need to perform a drive rescan on the actual instance and resize and extend the file-system. This will be OS specific. I've tested this a few times and it seems very reliable. Taylor Bertie Enterprise Support Infrastructure Engineer Mobile +64 27 952 3949 Phone +64 4 462 5030 Email taylor.ber...@solnet.co.nz Solnet Solutions Limited Level 12, Solnet House 70 The Terrace, Wellington 6011 PO Box 397, Wellington 6140 www.solnet.co.nz Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmas...@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey Taylor, This is something that has come up a number of times but I personally didn't have a good solution for it on the iSCSI side. I'm not sure if your method would work with iSCSI attached devices because typically you need to detach/reattach for size changes to take effect, in other words I'm uncertain if libvirt would be able to see the changes. That being said I also didn't know about this option in libvirt so it may work out. I'll let the Nova folks reply regarding interest from their side in the M release, but I know from the Cinder side and the Trove side this would in fact be a desireable feature. Appreciate the detailed write up, and again WELCOME!! Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] What's Up, Doc? 21 August 2015 (Early edition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, First of all, apologies for missing last week's newsletter: I got so caught up in the documentation swarm happening here in Brisbane that it totally slipped my mind! To make up for it, have this week's newsletter a day early :) In swarm news, the two days ran extremely smoothly, much to the credit of Suyog, Brian, and Alex who did the heavy lifting of preparation and organisation. While we focused largely on copy editing, we also had a lot of great discussion about the overall architecture of the book, and now have a draft plan ready for Mitaka, which Darren is driving with the Ops/Arch Guide speciality team. While last week was all about the docs swarm, this week has been doing the final cleanup on our newly converted RST books. The Security Guide is now up, and the Cloud Admin and HA Guides aren't far behind. We're also about to start testing the Install Guide, now that its conversion is complete. Well done to all the people who have helped out on these efforts, great job! == Progress towards Liberty == 55 days to go! * RST conversion: ** Install Guide: Conversion is done, testing to begin soon. ** Cloud Admin Guide: is complete! The new version will be available on docs.openstack.org very soon. ** HA Guide: is also done, and will available on the site soon. ** Security Guide: is complete, and live: http://docs.openstack.org/security-guide/ * User Guides information architecture overhaul ** Some user analysis has begun, with a new blueprint to land soon. * Greater focus on helping out devs with docs in their repo ** Work has picked up on the Ironic docs again. * Improve how we communicate with and support our corporate contributors ** If you currently work on documentation for a company that would like to improve their upstream commits for documentation, please contact me! * Improve communication with Docs Liaisons ** I'm very pleased to see liaisons getting more involved in our bugs and reviews. Keep up the good work! * Clearing out old bugs ** Sadly, no action on the spotlight bugs again this week. I'll keep the current three bugs for this week, to give everyone a little more time. == RST Migration == That's it! We're done! Do you have ideas for which book should be next? Have a think on it, and we'll discuss this at Summit. == Training Guides == I'm happy to announce that the Training Labs are now in their own repo, and are considered a documentation speciality team. Well done to Pranav, Matjaz, Sayali, and Roger for driving this effort. == Countdown to Summit == With the Liberty release less than two months away, that means it's nearly Summit time again: https://www.openstack.org/summit/tokyo-2015/ Here's a few things you might want to be thinking about: * Do you need a visa to visit Japan? If so, you need to be organising this NOW: https://www.openstack.org/summit/tokyo-2015/tokyo-and-travel/#visa * Do you have an ATC pass? If you haven't received your pass yet, and you're an ATC, please contact me so I can chase this up for you. Remember to use your ATC discount code before 31 August to make sure you get the full price discounted. == Doc team meeting == The APAC meeting was held this week. Read the minutes here: https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2015-08-19 The next meetings are: US: Wednesday 26 August, 14:00:00 UTC APAC: Wednesday 2 September, 00:30:00 UTC Please go ahead and add any agenda items to the meeting page here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting == Spotlight bugs for this week == Let's give these three a little more love: https://bugs.launchpad.net/openstack-manuals/+bug/1257018 VPNaaS isn't documented in cloud admin https://bugs.launchpad.net/openstack-manuals/+bug/1257656 VMware: add support for VM diagnostics https://bugs.launchpad.net/openstack-manuals/+bug/1261969 Document nova server package - -- Remember, if you have content you would like to add to this newsletter, or you would like to be added to the distribution list, please email me directly at openst...@lanabrindley.com, or visit: https://wiki.openstack.org/w/index.php?title=Documentation/WhatsUpDoc Keep on doc'ing! Lana - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV1TwWAAoJELppzVb4+KUylDUIALVRDpsMU+xM+7x8AsJKfnwv BRmGvUQWrrneBdx99b4Dyq/qianUPxz0hHjdchdeA37JfQYGiKoaVWVR1QAj5aPs WSg5/KRKI8cjHdfGDo7o0NhFIl2d9cyLj55xXap89QWSZvGoRSn8pXIibRoGd+1t Pp4RpxqftB8BYTlDkrdePYDIb0X+um3CJ2a/0DwuKUUVfn5zWxt9pOBYrYuqyFbK fUmI0LzRtopT+hmk02eHaefFzq+nQg5RO64osxd3JG/Zibgb8nIqw6eTjMBLvLs8 aPiNQ5ZSi5dwwRfy3pX8XpM4bl9iXOjhEAxtBT+6Zen4MvaTLehXbnoQ+ooETcQ= =ul61 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
[openstack-dev] [nova][qa] libvirt + LXC CI - where's the beef?
After spending a few hours on https://bugs.launchpad.net/nova/+bug/1370590 I'm annoyed by the fact we don't yet have a CI system for testing libvirt + LXC. At the Juno midcycle in Portland I thought I remember some guy(s) from Rackspace talking about getting a CI job running, whatever happened with that? It seems like we should be able to get this going using community infra, right? Just need some warm bodies to get the parts together and figure out which Tempest tests can't be run with that setup - but we have the hypervisor support matrix to help us out as a starter. It also seems unfair to require third party CI for libvirt + parallels (virtuozzo) but we don't have the same requirement for LXC. What gives?! -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] extension implemented by multiple plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/19/2015 10:54 AM, Bence Romsics wrote: Hi, I'm not sure I need it. :-) My first idea was, that if two plugins implement an extension together (neither the new first class resource, nor the new port attributes is a usable feature in themselves in my case), then it would be nice to express this. However thinking a bit more, I believe the only practical difference between your solution in the qos patches and my first idea is that we could catch some bad neutron configurations (ie. loading only one of the two plugins). Which is probably really rare, so it does not seem to justify the extra complexity. So I will just go with your stuff. Thanks. Well, if we can move into dreams area, we may think of a way to express such inter-dependency, f.e. by introducing hidden sub-extensions; and meta-extensions that are satisfied only if all sub-extension pieces are present. But we like simple solutions, so we just hacked around the limitation. Our fault. :) Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV1FfcAAoJEC5aWaUY1u57QrAH/A7qwU0EI9GE7yLI3pKckxnQ 7WJrjeLkewJkAH4LgPPkrD37ENgvKihF7MeEONzLaGll3OPp0xqTMGelLf+xPQ83 Cp2FNvG32kBi9EI/ge/VNxKBqpP+b6GcVP+UiH87dL4o35GHdbdC8uopKXjjDEKL uP2yVvJNz2IsojPUgbNw7GlWsP43EL93Piig6T7aRpApafSair3unc0/FbiYZlD/ WGepc+vwni+NC+Hk8PAb2jKCWA7xNvmZzpFKrTvY7Z75t0AK39a6SdCPbUvjwU/9 XL+gcPOggLq9LElZjdnyEW+EmVO0euAbl3YYLbyPdJWxM4d3sk+KGQCBhfwgsOs= =B0T+ -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes
On 19 August 2015 at 21:19, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: [...] Proposed data structure: - create a top level directory in each repo called release-notes - within that create a subdirectory called changes. - within the release-notes dir we place yaml files containing the release note inputs. - within the 'changes' subdirectory, the name of the yaml file will be the gerrit change id in a canonical form. E.g. I1234abcd.yaml This serves two purposes: it guarantees file name uniqueness (no merge conflicts) and lets us determine which release to group it in (the most recent one, in case of merge+revert+merge patterns). One small issue I see with using changeid in the filename is that it prevents people from easily proposing a backport with a release note snippet in them (since they can't predict the changeID). They will have to get it generated and then amend their commit. Backports typically use the original changeID - they will if they use git cherry-pick. I think we need to enforce some more structure. Release notes are easier to read if you group them by category. For stable branches you should put critical upgrade notes first, then security updates, then random release notes. For master branch notes we usually have critical upgrade notes, then major features, then known issues, then random release notes. So I would encourage a slightly more detailed schema with categories to keep consistency and readability. Sure - please fill it in :). I was winging it, since I don't do release notes, I had no idea of your needs. Processing: 1) determine the revisions we need to generate release notes for. By default generate notes for the current minor release. (E.g. if the tree version is 1.2.3.dev4 we would generate release notes for 1.2.0, 1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]). How would that work in a post-versioned world ? What would you generate if the tree version is 1.2.3.post12 ? 1.2.3 is still the version, not that we can use post versions at all with pbr. (Short story - we can't because we used them wrongly and we haven't had nearly enough time to flush out remaining instances in the wild). 2) For each version: scan all the commits to determine gerrit change-id's. i) read in all those change ids .yaml files and pull out any notes within them. ii) read in any full version yaml file (and merge in its contained notes) iii) Construct a markdown document as follows: a) Sort any preludes (there should be only one at most, but lets not error if there are multiple) b) sort any notes We would sort them by category. The requirement for deterministic results means we'd just sort them. If they are divided into categories, we'd sort the list of categories (perhaps according to some schema) and then within each category sort the notes. c) for each note transform it into a bullet point by prepending its first line with '- ' and every subsequent line with ' ' (two spaces to form a hanging indent). d) strip any trailing \n's from everything. e) join the result - '\n'.join(chain(preludes, notes)) iv) we output the resulting file to release-notes/$version.md where $version is the pbr reported version for the tree (e.g. in the example above it would be 1.2.3.dev4, *not* 1.2.3). So you would have release-notes/1.2.2.yaml and release-notes/1.2.2.md in the same directory, with one being a subset of the data present in the other ? That feels a bit confusing. I would rather use two separate directories (source and output) for that. If you like, sure. Though the thing I was thinking was that for very old things we might generate the md file, delete the yaml, and commit to the tree. 3) possibly symlink the highest output version to ./RELEASENOTES.md or something, so other tooling can look for a constant value. +1 If we want to put release notes in sdists, we can have pbr do this, otherwise it could just be built entirely separately. I think we need to put release notes in sdists, so that people consuming stable branches from a random commit can still get work-in-progress releasenotes for the upcoming version. Those two things are disconnected. Consuming a random commit doesn't imply sdist - nor does it preclude it. We don't *currently* generate release notes in sdists. Whats the driver for adding it? [perhaps as a use case so we can flush out hidden assumptions we have] I recommend we start with it entirely separate: part of the release-management tooling. That could work, for example, for the liberty release. I think for stable branches we'll need releasenotes published in the sdists, for the above-mentioned reason. I don't understand the reason well enough to follow it. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not
Re: [openstack-dev] Fw: [heat-translator] Nominating new core reviewers
+1 Hello, I am glad to nominate Vahid Hashemian [1] and Srinivas Tadepalli [2] for the Heat-Translator core reviewers team. Both of them have been providing significant contribution, development and review, since the beginning of this year and knows code base well. Existing cores, please reply this email by end of this week with your vote +1/-1 for their addition to the team. Review stats: *http://stackalytics.com/report/contribution/heat-translator/90* http://stackalytics.com/report/contribution/heat-translator/90 [1] *https://review.openstack.org/#/q/reviewer:%22Vahid+Hashemian+%253Cvahidhashemian%2540us.ibm.com%253E%22,n,z* https://review.openstack.org/#/q/reviewer:%22Vahid+Hashemian+%253Cvahidhashemian%2540us.ibm.com%253E%22,n,z [2] *https://review.openstack.org/#/q/reviewer:%22srinivas_tadepalli+%253Csrinivas.tadepalli%2540tcs.com%253E%22,n,z* https://review.openstack.org/#/q/reviewer:%22srinivas_tadepalli+%253Csrinivas.tadepalli%2540tcs.com%253E%22,n,z Regards, Sahdev Zala PTL, Heat-Translator __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Vendor tools related to Ironic
Hi All, This is an informational mail for both vendor tool developers and Ironic community. For vendor tool developers - We decided the last week's Ironic meeting [1] that vendors who want to share tools/scripts related to Ironic, can do so in their own preferred way (personal github repositories or stackforge/openstack github repositories ((provided it gets accepted))). Such vendor tools can be listed in Ironic wiki[3]. These vendor tools will not be reviewed/maintained by the Ironic community. For Ironic community - After having taken the action item for wikifying them, I have just written down wiki pages ([2] and [3]), and linked them to the main page of our wiki[4]. This just captures what we discussed in the meeting, plus a bit of additions from my side. Please feel free to discuss and edit them as required. [1] http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-08-17-17.00.log.txt [2] https://wiki.openstack.org/wiki/Ironic/ThirdPartyVendorToolsDeveloperDoc [3] https://wiki.openstack.org/wiki/Ironic/ThirdPartyVendorToolsList [4] https://wiki.openstack.org/wiki/Ironic Thanks. Regards, Ramesh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state
My opinion:
- If a new API is desirable by operators who would like to skip a few steps
in Ironic before making it active, then we should do it. I mean we should
allow them to skip the enroll state and manageable state, thereby giving
them an opportunity to land the node in manageable or available state
by default.
- Default state (by default) should be enroll as that's where the state
of a node in Ironic begins. May be optionally it can be tweaked in
ironic.conf.
- I don't like the idea to land a node directly in active state. The main
reason being it differs from driver to driver, what it takes to bring a
node to active and what is required for a take over for the active node.
For example, while deploying a partition image (by pxe or virtual media
drivers), the uuid of the root partition should be available in the
driver_internal_info for take_over to happen. So, it would mean that even
for existing drivers, we would need to at least provide a mechanism for
writing driver_internal_info from the API which is not desirable. It is
very much a valid use case to do import. From first thought, I think we
should have a new API endpoint to request such an import and a new method
in DeployInterface (not an abstract method) for importing bare metals from
another system. The API should allow parameters to be passed from the
driver to do the import, optionally requesting to reboot the bare metal
after it is imported (to make sure that Ironic can properly manage the node
again). The new method in DeployInterface should do what it takes to
import the bare metal given the parameters. But, that might be a different
story :).
Regards,
Ramesh
On Wed, Aug 19, 2015 at 5:35 AM, Ruby Loo rlooya...@gmail.com wrote:
On 17 August 2015 at 20:20, Robert Collins robe...@robertcollins.net
wrote:
On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com wrote:
Hi, sorry for the delay. I vote no. I understand the rationale of
trying to
do things so that we don't break our users but that's what the
versioning is
meant for and more importantly -- I think adding the ENROLL state is
fairly
important wrt the lifecycle of a node. I don't particularly want to
hide
that and/or let folks opt out of it in the long term.
From a reviewer point-of-view, my concern is me trying to remember
all the
possible permutations/states etc that are possible to make sure that
new
code doesn't break existing behavior. I haven't thought out whether
adding
this new API would make that worse or not, but then, I don't really
want to
have to think about it. So KISS as much as we can! :)
I'm a little surprised by this, to be honest.
Here's why: allowing the initial state to be chosen from
ENROLL/AVAILABLE from the latest version of the API is precisely as
complex as allowing two versions of the API {old, new} where old
creates nodes in AVAILABLE and new creates nodes in ENROLL. The only
difference I can see is that eventually someday if {old} stops being
supported, then and only then we can go through the code and clean
things up.
It seems to me that the costs to us of supporting graceful transitions
for users here are:
1) A new version NEWVER of the API that supports node state being one
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
AVAILABLE when not supplied.
2) Supporting the initial state of AVAILABLE indefinitely rather than
just until we *delete* version 1.10.
3) CD deployments that had rolled forward to 1.11 will need to add the
state parameter to their scripts to move forward to NEWVER.
4) Don't default the client to the veresions between 1.10 and NEWVER
versions at any point.
That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new functionality
when they are ready.
-Rob
After thinking about this some more, I'm not actually going to address
Rob's points above. What I want to do is go back and discuss... what do
people think about having an API that allows the initial provision state to
be specified, for a node that is created in Ironic. I'm assuming that
enroll state exists :)
Earlier today on IRC, Devananda mentioned that there's a very strong case
for allowing a node to be created in any of the stable states (enroll,
manageable, available, active). Maybe he'll elaborate later on this. I
know that there's a use case where there is a desire to import nodes (with
instances on them) from another system into ironic, and have them be active
right away. (They don't want the nodes to go from
enroll-verifying-manageable-cleaning!!!-available!!!-active).
1. What would the default provision state be, if it wasn't specified?
A. 'available' to be backwards compatible with pre-v1.11
or
B. 'enroll' to be consistent with v1.11+
or
?
2. What would it mean to set the initial provision state to something
other than 'enroll'?
manageable
In our state machinery[0], a node
Re: [openstack-dev] [neutron] New networking-calico project
On 2015-08-18 20:30, Sean M. Collins wrote:
Are your ACLs set up properly?
https://review.openstack.org/#/admin/projects/openstack/networking-calico,access
I don't see your group - or any actual group that has rights assigned to
the repo - it's empty.
compare that to:
https://review.openstack.org/#/admin/projects/openstack/neutron,access
Something is indeed broken. Please discuss with the infra team on
#openstack-infra IRC channel and let's figure out what's the problem.
I did a quick review and it looks fine in project-config.
It might be that something went wrong with initial project creation.
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] API: Question on 'Retry-After': 0 in HTTPForbidden
+1 for Retry-After is wrong for quota case 在 2015年8月19日，下午1:32，GHANSHYAM MANN ghanshyamm...@gmail.com 写道： Retry-After __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.
Hi Abhi, IIUC, you should create and configure slaves(these slaves can be VMs or real physical machine) in Jenkins. And the nodepool is used to create and pool VMs automatically, and these VMs should be run on the slaves. Then, while CI wants to build and execute a testcase, especially which attempts to be run on an isolated host, the nodepool will match a proper VM for this testcase. Hope this might help you. Xiexs From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] Sent: Tuesday, August 18, 2015 1:46 PM To: openstack-in...@lists.openstack.org; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves. Also adding the following: * https://github.com/openstack-infra/project-config/tree/master/nodepool/elements Does this means that we don't have to take care of creating slaves(i.e; installing slave using scripts as we have done in master) and it will be done automatically, and also we don't have to configure slaves in Jenkins. A bit confusing for me so if anyone can explain it to me then it will be very helpful. On Tue, Aug 18, 2015 at 11:11 AM, Abhishek Shrivastava abhis...@cloudbyte.commailto:abhis...@cloudbyte.com wrote: Hi Folks, I was going through Ramy's guide for setting up CI, there I found out the following: * https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves But I don't get the fact on how to create the image, also what major settings need to be done to make the config perfect for use. Can anyone help me with that? -- [https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ] Thanks Regards, Abhishek Cloudbyte Inc.http://www.cloudbyte.com -- [https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ] Thanks Regards, Abhishek Cloudbyte Inc.http://www.cloudbyte.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] neutron-lbaas code structure problem
Thanks Brandon, got it. It is easy to understand :) On Sat, Aug 15, 2015 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi Gareth, The reason for this is because lbaas v1 is in the services/loadbalancer/drivers path. This path was maintained from when neutron-lbaas was just another directory in the neutron repo. Once we moved to neutron-lbaas as its own repo and going forward with lbaas v2, the decision was made to not maintain that same path for v2. There's no reason to keep that path for v2 as v1 will be deprecated and eventually removed and we did not want to be stuck with that path. Eventually the plugin.py module will have to be moved to the root directory as well from services/loadbalancer but thats a minor change. Thanks, Brandon -- *From:* Gareth academicgar...@gmail.com *Sent:* Thursday, August 13, 2015 9:38 PM *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [Neutron] neutron-lbaas code structure problem Dear neutron guys. [0] https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/drivers [1] https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/services/loadbalancer/drivers the codes under these two paths are 'same' (implement same things with v1 and v2), but why use two different code paths here? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud
Thanks Steven. I've registered the blueprint: https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support We'll start preparing the pseudo-thirdparty job, develop the feature and bother you guys in the IRC channel as soon as you approve the blueprint. Can we discuss it next Thursday on the IRC meeting? On 18 August 2015 at 18:14, Steven Hardy sha...@redhat.com wrote: On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote: Hi Steven/Emilien, Thanks for the quick responses. On Tue, 18 Aug 2015 16:10, Steven Hardy wrote: On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote: I think the pattern for the templates will be similar to the Cisco ML2 plugins which are currently being integrated: https://review.openstack.org/#/c/198754/ The plug-points for third-party configuration is still undergoing some refinement, but the basic steps are: 1. Ensure you have support in the upstream puppet modules (as mentioned by Emilien), and figure out the hieradata required to drive puppet as required. Yes, we would like to be fully upstream on this. MidoNet plugin support for Puppet Neutron is already done since Kilo (and backported to Juno). We do have in mind Emilien's request. So I think that won't be a problem. 2. Create a heat template which creates the hieradata, and defines parameters for all configurable values, e.g like: https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml 3. Define a heat environment file, which wires in the template from (2) via the OS::TripleO::ControllerExtraConfigPre interface: https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml 4. Add the hieradata file deployed via (2) to the controller hierarchy: https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml 5. Add conditional logic to the manifiests so the appropriate modules from (1) are included when your backend is enabled: https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp Basically the way this works is the hieradata is deployed via (2) before puppet runs, and the manifiest changes in (5) consumes that data when we apply it during deployment. The links and the steps to follow are so helpful! Thanks again. Couple of questions here: * There is no need of `tripleo-puppet-elements`? It depends, if your additions require additional packages to be installed, then you may need to either add them to an existing element, or create a new element which may be specified by those building images with diskimage-builder, e.g so their images contain what you require. https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller If your integration purely requires configuration changes (and the puppet module already exists in the image), you may not need to do anything. * Since the integration seems feasible, does it make sense to start opening a blueprint and start working on it? Absolutely, a blueprint is probably a good idea (although tbh these haven't been strictly required lately..) summarising the required changes, then you can use the examples I linked to work on the template changes. No, we're moving away from tuskar and it's not required for third-party integration such as described above (it's also not covered in CI). Speaking of CI, it'd be good to discuss how you plan to ensure your stuff stays working, as clearly we don't have the resources in upstream CI to test it, having third-party CI jobs vote on TripleO changes would be one way to solve this, but AFAIK we don't yet have a process in place to enable this. Even if there is not an official Third Party methodology, it wouldn't be so hard to add a Jenkins job on our infrastructure to listen upstream gerrit events and make comments instead of voting, right? (maybe I am speaking so quickly, I can not image right now how a TripleO Jenkins job look like...) Yes, this was exactly what I had in mind - it'd be great if we could get some sort of non-voting comments from those contributing third-party additions - I know this pattern works well for other projects, so I guess the same approach for TripleO may be reasonable as well. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura __ OpenStack
Re: [openstack-dev] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud
Sorry, I meant Tuesday. On 19 August 2015 at 10:51, Jaume Devesa devv...@gmail.com wrote: Thanks Steven. I've registered the blueprint: https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support We'll start preparing the pseudo-thirdparty job, develop the feature and bother you guys in the IRC channel as soon as you approve the blueprint. Can we discuss it next Thursday on the IRC meeting? On 18 August 2015 at 18:14, Steven Hardy sha...@redhat.com wrote: On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote: Hi Steven/Emilien, Thanks for the quick responses. On Tue, 18 Aug 2015 16:10, Steven Hardy wrote: On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote: I think the pattern for the templates will be similar to the Cisco ML2 plugins which are currently being integrated: https://review.openstack.org/#/c/198754/ The plug-points for third-party configuration is still undergoing some refinement, but the basic steps are: 1. Ensure you have support in the upstream puppet modules (as mentioned by Emilien), and figure out the hieradata required to drive puppet as required. Yes, we would like to be fully upstream on this. MidoNet plugin support for Puppet Neutron is already done since Kilo (and backported to Juno). We do have in mind Emilien's request. So I think that won't be a problem. 2. Create a heat template which creates the hieradata, and defines parameters for all configurable values, e.g like: https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml 3. Define a heat environment file, which wires in the template from (2) via the OS::TripleO::ControllerExtraConfigPre interface: https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml 4. Add the hieradata file deployed via (2) to the controller hierarchy: https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml 5. Add conditional logic to the manifiests so the appropriate modules from (1) are included when your backend is enabled: https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp Basically the way this works is the hieradata is deployed via (2) before puppet runs, and the manifiest changes in (5) consumes that data when we apply it during deployment. The links and the steps to follow are so helpful! Thanks again. Couple of questions here: * There is no need of `tripleo-puppet-elements`? It depends, if your additions require additional packages to be installed, then you may need to either add them to an existing element, or create a new element which may be specified by those building images with diskimage-builder, e.g so their images contain what you require. https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller If your integration purely requires configuration changes (and the puppet module already exists in the image), you may not need to do anything. * Since the integration seems feasible, does it make sense to start opening a blueprint and start working on it? Absolutely, a blueprint is probably a good idea (although tbh these haven't been strictly required lately..) summarising the required changes, then you can use the examples I linked to work on the template changes. No, we're moving away from tuskar and it's not required for third-party integration such as described above (it's also not covered in CI). Speaking of CI, it'd be good to discuss how you plan to ensure your stuff stays working, as clearly we don't have the resources in upstream CI to test it, having third-party CI jobs vote on TripleO changes would be one way to solve this, but AFAIK we don't yet have a process in place to enable this. Even if there is not an official Third Party methodology, it wouldn't be so hard to add a Jenkins job on our infrastructure to listen upstream gerrit events and make comments instead of voting, right? (maybe I am speaking so quickly, I can not image right now how a TripleO Jenkins job look like...) Yes, this was exactly what I had in mind - it'd be great if we could get some sort of non-voting comments from those contributing third-party additions - I know this pattern works well for other projects, so I guess the same approach for TripleO may be reasonable as well. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software
Re: [openstack-dev] [Congress] [Murano] multiple numbers of arguments for table
Hi Tim We use fixed count of columns. So I believe there should not be any bad impact of this change. Regards Filip On 08/18/2015 11:22 PM, Tim Hinrichs wrote: Hi all, We're contemplating a small syntax change in the Congress policy language and wanted to see if it would cause anyone problems. Currently you can write rules that give a single table differing numbers of columns. In the following example, the 'error' table has both 1 column and 2 columns. error(vm) :- blah blah error(vm, net) :- blah blah We're contemplating removing this flexibility and making every table have a fixed number of columns. (We only support differing numbers of columns in very special cases anyway.) Would this cause any problems? Murano team? Thanks, Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] extension implemented by multiple plugins
Hi, I'm not sure I need it. :-) My first idea was, that if two plugins implement an extension together (neither the new first class resource, nor the new port attributes is a usable feature in themselves in my case), then it would be nice to express this. However thinking a bit more, I believe the only practical difference between your solution in the qos patches and my first idea is that we could catch some bad neutron configurations (ie. loading only one of the two plugins). Which is probably really rare, so it does not seem to justify the extra complexity. So I will just go with your stuff. Thanks. Cheers, Bence On Tue, Aug 18, 2015 at 4:02 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/18/2015 03:11 PM, Bence Romsics wrote: Hi Ihar, Thank you. Just rebased my patch and following the example of the qos feature now I can start neutron-server with both the service plugin and the ml2 extension driver loaded. However I have noticed that I can no longer mark the extension driver as implementing the extension alias (the 'extension_alias' property seems to be better not used, or I still have the same error). Is that intentional? I think the assumption is that only one plugin is capable of implementing an extension. We only allowed to implement no extensions at all. If you think we should allow multiple plugins to claim support for the same extension, then it's an additional use case on top of what we needed in qos. Why do you need it? BTW feature/qos was merged in master yesterday, so it's now available for all patches. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV0zrZAAoJEC5aWaUY1u57DIAIAJG+U3sVI/ejvEmETEtbINH+ mm8IFhpwoSzMNcRKfrlobgmu4R/+saGfQsUaQHjh4ko7PVq2eDH9sMPlHjVZXUGi x5Rt7gKuFCXsPLyXybjAaaWQjI/hO65/V7D1xwQceRl9FL6kSjgxoasu5ufGUR4j ZMmp0f9nN8v7VVHynhLq0FEYMqMs0fylO2hnyJKyJUk26Xd1GZqv/58jAl6RaB3Z LzE6Qd6yO0R4ekEhL4DhBbf3+J59ljDhgCbCvScKiL83IZb0FT4vcYMvuHIKezHt c23ImDJjz9ZCCld0ah39/jEcqOWj8IM41L/1Qjwdk/Fn/s1CUtFY1vJ28z8IOgg= =rMZ7 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes
Robert Collins wrote: [...] Proposed data structure: - create a top level directory in each repo called release-notes - within that create a subdirectory called changes. - within the release-notes dir we place yaml files containing the release note inputs. - within the 'changes' subdirectory, the name of the yaml file will be the gerrit change id in a canonical form. E.g. I1234abcd.yaml This serves two purposes: it guarantees file name uniqueness (no merge conflicts) and lets us determine which release to group it in (the most recent one, in case of merge+revert+merge patterns). One small issue I see with using changeid in the filename is that it prevents people from easily proposing a backport with a release note snippet in them (since they can't predict the changeID). They will have to get it generated and then amend their commit. I don't really have a better suggestion though, so I guess we could do some git-review magic to simplify that (fix the filename at ChangeID generation time and/or have a --releasenote option that autocreates a file). - we also create files that roll up all the notes within history versions - named by the version. e.g. release-notes/1.2.3.yaml. Yaml schema: prelude: prelude prose notes: - note1 - note2 - note3 I think we need to enforce some more structure. Release notes are easier to read if you group them by category. For stable branches you should put critical upgrade notes first, then security updates, then random release notes. For master branch notes we usually have critical upgrade notes, then major features, then known issues, then random release notes. So I would encourage a slightly more detailed schema with categories to keep consistency and readability. Processing: 1) determine the revisions we need to generate release notes for. By default generate notes for the current minor release. (E.g. if the tree version is 1.2.3.dev4 we would generate release notes for 1.2.0, 1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]). How would that work in a post-versioned world ? What would you generate if the tree version is 1.2.3.post12 ? 2) For each version: scan all the commits to determine gerrit change-id's. i) read in all those change ids .yaml files and pull out any notes within them. ii) read in any full version yaml file (and merge in its contained notes) iii) Construct a markdown document as follows: a) Sort any preludes (there should be only one at most, but lets not error if there are multiple) b) sort any notes We would sort them by category. c) for each note transform it into a bullet point by prepending its first line with '- ' and every subsequent line with ' ' (two spaces to form a hanging indent). d) strip any trailing \n's from everything. e) join the result - '\n'.join(chain(preludes, notes)) iv) we output the resulting file to release-notes/$version.md where $version is the pbr reported version for the tree (e.g. in the example above it would be 1.2.3.dev4, *not* 1.2.3). So you would have release-notes/1.2.2.yaml and release-notes/1.2.2.md in the same directory, with one being a subset of the data present in the other ? That feels a bit confusing. I would rather use two separate directories (source and output) for that. 3) possibly symlink the highest output version to ./RELEASENOTES.md or something, so other tooling can look for a constant value. +1 If we want to put release notes in sdists, we can have pbr do this, otherwise it could just be built entirely separately. I think we need to put release notes in sdists, so that people consuming stable branches from a random commit can still get work-in-progress releasenotes for the upcoming version. I recommend we start with it entirely separate: part of the release-management tooling. That could work, for example, for the liberty release. I think for stable branches we'll need releasenotes published in the sdists, for the above-mentioned reason. Thanks, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Bugs for Rackspace resources that use scheduler tasks
Hi Randall, Jason this is re bug https://bugs.launchpad.net/heat/+bug/1393268 As most of in-tree resources are now fixed in this regard, Steve Baker asked me to create separate bugs for Rackspace resources from Heat's contrib that need fixing. As I am not comfortable with messing around in those resources (and I remember I've talked with Randall about this last summit), I have assigned those bugs to Randall first so you can spread them between your heat team. Not sure when/if you guys will switch to convergence, so I've made those bugs about using scheduler.TaskRunner objects as Medium (those are must for convergence phase 2), and those where only rich objects are passed around as Low. Bugs in question are: - Rackspace Cloud Network https://bugs.launchpad.net/heat/+bug/1486464 (this one is easy, it almost does the right thing already), priority Low - Rackspace Cloud LoadBalancer https://bugs.launchpad.net/heat/+bug/1486463 (this one is bad, especially the update logic), priority Medium Best regards, -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state
To be honest, I'm tired of repeating the same arguments again and
again... I personally would like to get something cool done, rather than
discussing how to work around our new state machine again and again.
Now to some trolling: please include a way to users to opt-out from
NOSTATE - AVAILABLE renaming.
On 08/18/2015 09:11 PM, Ruby Loo wrote:
Apologies, forgot to add [ironic] to the subject.
On 18 August 2015 at 13:27, Ruby Loo rlooya...@gmail.com
mailto:rlooya...@gmail.com wrote:
Hi,
I want to start a different thread on this topic because I don't
think this is about whether/how to do API microversions. Rather,
given that we are going to support microversioning, how to deal with
the non-backward compatible change in 1.11 with the ENROLL state
(instead of AVAILABLE) being the provision state that a node is in,
after being created/registered in ironic.
(This was from 'Let's talk about API versions,
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html.)
I want to think about this before replying but others are more than
welcome to reply first so that I may not feel the need to reply :-)
--ruby
maybe chop off this and above when replying :-)
On 17 August 2015 at 20:20, Robert Collins
robe...@robertcollins.net mailto:robe...@robertcollins.net wrote:
On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com
mailto:rlooya...@gmail.com wrote:
Hi, sorry for the delay. I vote no. I understand the rationale of
trying to
do things so that we don't break our users but that's what the
versioning is
meant for and more importantly -- I think adding the ENROLL state is
fairly
important wrt the lifecycle of a node. I don't particularly want to
hide
that and/or let folks opt out of it in the long term.
From a reviewer point-of-view, my concern is me trying to remember
all the
possible permutations/states etc that are possible to make sure that
new
code doesn't break existing behavior. I haven't thought out whether
adding
this new API would make that worse or not, but then, I don't really
want to
have to think about it. So KISS as much as we can! :)
I'm a little surprised by this, to be honest.
Here's why: allowing the initial state to be chosen from
ENROLL/AVAILABLE from the latest version of the API is precisely as
complex as allowing two versions of the API {old, new} where old
creates nodes in AVAILABLE and new creates nodes in ENROLL. The
only
difference I can see is that eventually someday if {old} stops being
supported, then and only then we can go through the code and clean
things up.
It seems to me that the costs to us of supporting graceful
transitions
for users here are:
1) A new version NEWVER of the API that supports node state
being one
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
AVAILABLE when not supplied.
-1, it's a breaking change again. And it does not make any sense to me.
2) Supporting the initial state of AVAILABLE indefinitely rather
than
just until we *delete* version 1.10.
We don't delete any versions. This would be a terrible (backward
incompatible) change, breaking the whole idea of versioning.
3) CD deployments that had rolled forward to 1.11 will need to
add the
state parameter to their scripts to move forward to NEWVER.
4) Don't default the client to the veresions between 1.10 and NEWVER
versions at any point.
That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new functionality
when they are ready.
That's what versioning is for, so we're fine, nothing needs to be done.
-Rob
--
Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state
On 08/19/2015 02:05 AM, Ruby Loo wrote:
On 17 August 2015 at 20:20, Robert Collins
robe...@robertcollins.net mailto:robe...@robertcollins.net
wrote:
On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com
mailto:rlooya...@gmail.com wrote:
Hi, sorry for the delay. I vote no. I understand the rationale of
trying to
do things so that we don't break our users but that's what the
versioning is
meant for and more importantly -- I think adding the ENROLL state
is fairly
important wrt the lifecycle of a node. I don't particularly want
to hide
that and/or let folks opt out of it in the long term.
From a reviewer point-of-view, my concern is me trying to
remember all the
possible permutations/states etc that are possible to make sure
that new
code doesn't break existing behavior. I haven't thought out
whether adding
this new API would make that worse or not, but then, I don't
really want to
have to think about it. So KISS as much as we can! :)
I'm a little surprised by this, to be honest.
Here's why: allowing the initial state to be chosen from
ENROLL/AVAILABLE from the latest version of the API is
precisely as
complex as allowing two versions of the API {old, new} where old
creates nodes in AVAILABLE and new creates nodes in ENROLL.
The only
difference I can see is that eventually someday if {old}
stops being
supported, then and only then we can go through the code and
clean
things up.
It seems to me that the costs to us of supporting graceful
transitions
for users here are:
1) A new version NEWVER of the API that supports node state
being one
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
AVAILABLE when not supplied.
2) Supporting the initial state of AVAILABLE indefinitely
rather than
just until we *delete* version 1.10.
3) CD deployments that had rolled forward to 1.11 will need
to add the
state parameter to their scripts to move forward to NEWVER.
4) Don't default the client to the veresions between 1.10
and NEWVER
versions at any point.
That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new
functionality
when they are ready.
-Rob
After thinking about this some more, I'm not actually going to address
Rob's points above. What I want to do is go back and discuss... what do
people think about having an API that allows the initial provision state
to be specified, for a node that is created in Ironic. I'm assuming that
enroll state exists :)
Again...
Earlier today on IRC, Devananda mentioned that there's a very strong
case for allowing a node to be created in any of the stable states
(enroll, manageable, available, active). Maybe he'll elaborate later on
this. I know that there's a use case where there is a desire to import
nodes (with instances on them) from another system into ironic, and have
them be active right away. (They don't want the nodes to go from
enroll-verifying-manageable-cleaning!!!-available!!!-active).
And I want node to be created in INSPECTING state directly. I don't care
it's a transient state, I just want it :) Oh, and can I please skip
MANAGEABLE? I need the following flow INSPECTING-AVAILABLE.
Now seriously: to what degree are we going to allow people to break our
state machine? Or alternatively, are we going to allow steps to happen
automatically? I'm in favor of this idea actually, maybe someone feels
like writing a spec?
1. What would the default provision state be, if it wasn't specified?
A. 'available' to be backwards compatible with pre-v1.11
or
B. 'enroll' to be consistent with v1.11+
or
?
B. No more breaking changes please.
2. What would it mean to set the initial provision state to something
other than 'enroll'?
manageable
In our state machinery[0], a node goes from enroll - verifying -
manageable. For manageble to be initial state, does it mean that
A. whatever is needed for enroll and verifying is done and succeeds
(under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying)
or
C. no enroll or verifying is done, it goes straight to manageble
A sounds nice, but that's now how our state machine currently works.
Being able to skip states is really an interesting feature, but it
requires somewhat broader discussion. And then yes, you should allow me
to just straight into INSPECTING in this case :)
If it's not implied, then my
Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state
Hi, After thinking about this some more, I'm not actually going to address Rob's points above. What I want to do is go back and discuss... what do people think about having an API that allows the initial provision state to be specified, for a node that is created in Ironic. I'm assuming that enroll state exists :) Earlier today on IRC, Devananda mentioned that there's a very strong case for allowing a node to be created in any of the stable states (enroll, manageable, available, active). Maybe he'll elaborate later on this. I know that there's a use case where there is a desire to import nodes (with instances on them) from another system into ironic, and have them be active right away. (They don't want the nodes to go from enroll-verifying-manageable-cleaning!!!-available!!!-active). I would like to hear the more elaborated proposal before we start digging much into this problem. 1. What would the default provision state be, if it wasn't specified? A. 'available' to be backwards compatible with pre-v1.11 or B. 'enroll' to be consistent with v1.11+ or ? 2. What would it mean to set the initial provision state to something other than 'enroll'? manageable In our state machinery[0], a node goes from enroll - verifying - manageable. For manageble to be initial state, does it mean that A. whatever is needed for enroll and verifying is done and succeeds (under the hood) or B. whatever is needed for enroll is done and succeeds (but no verifying) or C. no enroll or verifying is done, it goes straight to manageble I'm fine with A.I'm not sure that B makes sense and I definitely don't think C makes sense. To date, verifying means checking that the conductor can get the power state on the node, to verify the supplied power credentials. I don't think it is a big deal if we skip this step; it just means that the next time some action is taken on the node, it might fail. available In our state machinery, a node goes from enroll - verifying - manageable - cleaning - available. For available to be initial state, does it mean that A. whatever is needed for enroll, verifying, cleaning is done and succeeds (under the hood) or B. whatever is needed for enroll is done and succeeds (but no verifying or cleaning) or ?? active In our state machinery, a node goes from enroll - verifying - manageable - cleaning - available-deploying-active. For active to be initial state, does it mean that A. whatever is needed for enroll, verifying, cleaning, deploying is done and succeeds (under the hood) or B. whatever is needed for enroll is done and succeeds (but no verifying or cleaning) or C. whatever is needed for enroll and I dunno, any 'takeover' stuff by conductor or whatever node states need to be updated to be in active? What I'm more concerned about allowing the enroll a node in any stable state is that it's going to be a big change in our API. We have PATCH as a mechanism of updating a resource partially because we have read-only attributes (driver_internal_info, *_updated_at, etc...) in the API that are internal and should not be updated by the user. Some states might depend on them i.e a node in ACTIVE state might have indicators in the driver_internal_info field. Another thing it's really cross resource, a node in ACTIVE state will depend on a certain port which it was used to be deployed (and other things about registering that port in Neutron with the right DHCP information, so if one is PXE booting after ACTIVE the node won't get stuck with a boot error. (Also we need to create the right TFTP (or TFTP + HTTP for iPXE) environment for that node. Anyway, I don't want to get much deeper, I think we should all be open to hear what will be proposed with a fresh mind. Cheers, Lucas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
my 0.02€ on the matter inline. Regards, Salvatore On 18 August 2015 at 23:45, Mathieu Rohon mathieu.ro...@gmail.com wrote: hi brandon, thanks for your answer. my answers inline, On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan brandon.lo...@rackspace.com wrote: So let me make sure I understand this. You want to do a separate service plugin for what would normally be separate drivers under one service plugin. The reasons for this are: 1. You dont want users the ability to choose the type, you want it always to be the same one While in theory it is be possible to have multiple BGPVPN providers in the same deployment, there are control and data plane aspects that the service type framework at the moment cannot deal with it. Mathieu brought some examples in the bug report. The bottom line appears to be that the choice of the l3 service plugin (or whatever serves l3 in your deployment) also dictates the choiche of the BGPVPN service provider to employ. 2. Some types do want to be the source of truth of the data stored, instead of it being the service plugin database. This point has little to do with service types. It's about the fact that plugins are not required to implemented the various db mixins in neutron.db and therefore not required to use the neutron DB. First, let me address the possibility of a solution using one service plugin and multiple drivers per type: I think that you can overcome #1 in the instantiation of the service plugin to check if there are more than 1 provider active, if so you can just throw an exception saying you can only have 1. I'd have to look at it more to see if there are any caveats to this, but I think that would work. For #2, assuming #1 works, then the drivers that are defined can have some boolean that they set that will tell the plugin whether they are the source of truth or not, and depending on that you can store the data in the service plugin's db or just pass the data along, also pass GET requests to the drivers as well. I agree that those workarounds will surely works but I wonder what is the meaning of a service plugin/type that can only support one service provider? can't the service plugin be the service provider directly? I believe there is some value, but I am not able to quantify it at the moment. - A single service plugin also implies (more or less) a common user-facing APIs. I really don't want to end up in a conditons where the user API looks different (or the workflow is different) according to what's backing the neutron BGPVPN implementation - A single service plugin provides a commonplace for all the boilerplate management logic. This works for most drivers, but not for those who don't rely on neutron DB as a data source (unless you manage to build a sqlalchemy dialect for things such as opencontrail APIs, but I seriously doubt that it would be feasible) - Distinct service plugins might lead to different workflows. This is not necessarily a bad thing, because integration for some backends might need it. However this means that during review phase particular attention should be paid to ensure the behaviour of each service plugin respects the API specification. The reasons why I'm considering this change are : 1. I'm not sure we would have some use cases where we would be able to choose one bgpvpn backend independently from the provider of the core plugin (or a mech driver in the ML2 case) and/or the router plugin. If one use ODL to manage its core resources, he won't be able to use nuage or contrail to manage its bgpvpn connection. The bgpvpn project is more about having a common API than having the capacity to mix backends. At least for the moment. I agree with this; but this problem exists regardless of whether you have a single service plugin with drivers or multiple service plugins. You are unlikely to be able to use the contrail BGPVPN service plugin is core and l3 are managed by ODL, I think. 2. I'm also considering that each plugin, which would be backend dependent, could declare what features it supports through the use of extensions. Unfortunately extensions are the only way to declare supported capabilities at the moment. But please - don't end up allowing each service plugin exposing a different API. Each plugin would be a bgpvpn service type, and would implement the bgpvpn extension, but some of them could extend the bgpvpn_connection resource with other extensions also hosted in the bgpvpn project. Since some backends only support attachment of networks to a bgpvpn_connection, others support attachment of routers, and others both attachments, I'm considering having an extension for each type of attachment. Then the bgpvpn plugin declares what extensions it supports and the end user can act accordingly depending on the scan of neutron extensions. This is not good. It appears that you are forced to leak backend details to API consumers. Is it possible for you
[openstack-dev] [Fuel] Code review process in Fuel and related issues
Hi all, let's discuss code review process in Fuel and what we can improve. For those who want to just have a quick context of this email, please check out presentation slides [5]. ** Issues ** Depending on a Fuel subproject, I'm aware of two buckets of issues with code review in Fuel: a) It is hard to get code reviewed and merged b) Quality of code review itself could be better First bucket: 1) It is hard to find subject matter experts who can help and core reviewers for the area of code, especially if you are new to the project 2) Contributor sometimes receives contradicting opinions from other reviewers, including cores 3) Assigned / responsible core reviewer is needed for a feature in order to help in architectural negotiations, guiding through, landing the code into master 4) Long wait time for getting code reviewed Quality-related items: 5) Not thorough enough, full review in one shot. For example, reviewer can put -1 due to missed comma, but do not notice major gap in the code. It leads to many patch sets, and demotivation of contributors 6) Some of the core reviewers decreased their involvement, and so number of reviews has dropped dramatically. However, they still occasionally merge code. I propose to remove these cores, and get them back if their involvement is increased back again (I very rarely merge code, but I'm one of those to be removed from cores). This is standard practice in OpenStack community as well, see Neutron as example [4, line 270]. 7) As a legacy of the past, we still have old core reviewers being able to merge code in all Fuel repos. All new cores have core rights only for single repo, which is their primary area of expertise. For example, core team size for fuel-library is adidenko + whole fuel-core group [7]. In fact, there are just 4 trusted or real core reviewers in fuel-library, not the whole fuel-core group. These problems are not new to OpenStack and open source in general. You can find discussions about same and similar issues in [1], [2], [3]. ** Analysis of data ** In order to understand what can be improved, I mined the data at first. Main source of information was stackalytics.com. Please take a look at few graphs on slides 4-7 [5], built based on data from stackalytics. Major conclusions from these graphs: 1) Rather small number of core reviewers (in comparison with overall number of contributors) reviewing 40-60% of patch sets, depending on repo (40% fuel-library, 60% fuel-web). See slide #4. 2) Load on core reviewers in Fuel team is higher in average, if you compare it with some other OpenStack projects. Average load on core reviewer across Nova, Keystone, Neutron and Cinder is 2.5 reviews a day. In Fuel though it is 3.6 for fuel-web and 4.6 for fuel-library. See slide #6. 3) Statistics on how fast feedback on code proposed is provided: - fuel-library: 2095 total reviews in 30 days [13], 80 open reviews, average wait time for reviewer - 1d 1h [12] - fuel-web: 1789 total reviews in 30 days [14], 52 open reviews, average wait time for reviewer - 1d 17h [15] There is no need to have deep analysis on whether we have well defined areas of ownership in Fuel components or not: we don’t have it formally defined, and it’s not documented anywhere. So, finding a right core reviewer can be challenging task for a new contributor to Fuel, and this issue has to be addressed. ** Proposed solution ** According to stackalytics, for the whole fuel-group we had 262 reviewers with 24 core reviewers for the past 180 days [19]. I think that these numbers can be considered as high enough in order to think about structure in which code review process would be transparent, understandable and scalable. Let’s first agree on the terminology which I’d like to use. It can take pages of precise definitions, however in this email thread I’d like to focus on code review process more, and hopefully high level description of roles would be enough for now. - Contributor: new contributor, who doesn’t work on Fuel regularly and doesn’t know team structure (or full time Fuel developer, who just started his work on Fuel) - SME: subject matter expert of certain Fuel area of code, which he / she regularly contributes to and reviews code of other contributors into this area. Example: network checker or Nailgun agent. - Core Reviewer: expert in one or few parts of Fuel, who was promoted to Core Reviewers team thanks to the contribution, high rate of quality reviews. - Component Lead: The one who defines architecture of a particular module or component in Fuel, does majority of merges there, resolves conflicts between SMEs and / or contributors in the area of responsibility, if conflicts can’t be resolved by other means. Component Lead has to review all design specs in its parts where his/her component is under change. - Fuel PTL: Project Team Lead in its OpenStack standard definition [8], delegates most of the work to component leads, but helps in cases when resolution of conflicts between
Re: [openstack-dev] [congress] [murano] Congress jenkins job is failing
Hi Tim I will try it once it merges. Thanks Filio On 08/18/2015 05:46 PM, Tim Hinrichs wrote: Hi Filip, I just submitted a revert of the problematic change. Once it merges, all should be well again. Sorry for the trouble. Tim On Tue, Aug 18, 2015 at 7:57 AM Tim Hinrichs t...@styra.com mailto:t...@styra.com wrote: Looks like we merged a database schema change without the migration script. I'm on it. (We'll get our tempest tests running in gate again ASAP.) Tim On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hi Congress team. Our jenkins job testing integration congress and murano is failing. Congress fails to start on some DB error [1] . Does anyone know what could be the problem? [1] http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033 Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
