Re: [openstack-dev] [Barbican] Barebones CA
Hello folks, Just trying clarify things...are we talking about a dev plugin to generate asymmetric keys, or else one to mimic working with a CA to create SSL certificates via workflow (so including firing off certificate-generated events, for example)? If we are talking about the former, then you would be interested in a plugin that implements a method such as this one: https://github.com/openstack/barbican/blob/master/barbican/plugin/interface/secret_store.py#L167 If you are talking about the latter, then that would be a different type of plugin that handles CA workflows, as proposed in this blueprint: https://review.openstack.org/#/c/99221/ Thanks, John From: Nathan Kinder [nkin...@redhat.com] Sent: Wednesday, June 25, 2014 9:43 PM To: OpenStack Development Mailing List (not for usage questions); a...@redhat.com Subject: Re: [openstack-dev] [Barbican] Barebones CA On 06/25/2014 02:42 PM, Clark, Robert Graham wrote: Ok, I’ll hack together a dev plugin over the next week or so, other work notwithstanding. Where possible I’ll probably borrow from the dog tag plugin as I’ve not looked closely at the plugin infrastructure in Barbican recently. My understanding is that Barbican's plugin interface is currently in the midst of a redesign, so be careful not to copy something that will be changing shortly. -NGK Is this something you’d like a blueprint for first? -Rob On 25/06/2014 18:30, Ade Lee a...@redhat.com wrote: I think the plan is to create a Dogtag instance so that integration tests can be run whenever code is checked in (both with and without a Dogtag backend). Dogtag isn't that difficult to deploy, but being a Java app, it does bring in a set of dependencies that developers may not want to deal with for basic/ devstack testing. So, I agree that a simple OpenSSL CA may be useful at least initially as a 'dev' plugin. Ade On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote: Rob, RedHat is working on a backend for Dogtag, which should be capable of doing something like that. That's still a bit hard to deploy, so it would make sense to extend the 'dev' plugin to include those features. Jarret On 6/24/14, 4:04 PM, Clark, Robert Graham robert.cl...@hp.com wrote: Yeah pretty much. That¹s something I¹d be interested to work on, if work isn¹t ongoing already. -Rob On 24/06/2014 18:57, John Wood john.w...@rackspace.com wrote: Hello Robert, I would actually hope we have a self-contained certificate plugin implementation that runs 'out of the box' to enable certificate generation orders to be evaluated and demo-ed on local boxes. Is this what you were thinking though? Thanks, John From: Clark, Robert Graham [robert.cl...@hp.com] Sent: Tuesday, June 24, 2014 10:36 AM To: OpenStack List Subject: [openstack-dev] [Barbican] Barebones CA Hi all, I¹m sure this has been discussed somewhere and I¹ve just missed it. Is there any value in creating a basic ŒCA¹ and plugin to satisfy tests/integration in Barbican? I¹m thinking something that probably performs OpenSSL certificate operations itself, ugly but perhaps useful for some things? -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] milestone-proposed is dead, long lives proposed/foo
On 6/27/2014 7:44 AM, Thierry Carrez wrote: Hi everyone, Since the dawn of time, we have been using milestone-proposed branches for milestone and final release branches. Those would get milestone-critical and release-critical bugfixes backports, while the master branch can continue to be open for development. However, reusing the same blanket name for every such branch is causing various issues, especially around upgrade testing. It also creates havoc in local repositories which may have kept traces of previous incarnations of milestone-proposed. For all those reasons, we decided at the last summit to use unique pre-release branches, named after the series (for example, proposed/juno). That branch finally becomes stable/juno at release time. In parallel, we abandoned the usage of release branches for development milestones, which are now tagged directly on the master development branch. The visible impact of this change will be apparent when we reach Juno RC1s. RC bugfixes will have to be backported to proposed/juno instead of milestone-proposed. Tarballs automatically generated from this branch will be named PROJECT-proposed-juno.tar.gz instead of PROJECT-milestone-proposed.tar.gz. All relevant process wiki pages will be adapted to match the new names in the coming weeks. We are also generally changing[1] ACLs which used to apply to milestone-proposed branches so that they now apply to proposed/* branches. If you're a stackforge or non-integrated project which made use of milestone-proposed branches, you should probably switch to using proposed/foo branches when that patch lands. [1] https://review.openstack.org/#/c/102822/ Regards, We've been using a similar concept internally, we call it havana-proposed, icehouse-proposed, etc, but it sounds like the same idea. We're supporting more than the last 2 stable releases and it's hard to tell when we need to quickly turn out a release candidate build (like for a security issue going back to Folsom or something), so it makes sense for us to try and avoid branch naming collisions. Besides that branch naming we basically follow the same release process as upstream based on the same wiki's, with some additional automation for tagging and cleanup after the release. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Log / error message format best practices standards
On 6/26/2014 1:54 PM, Jay Pipes wrote: On 06/26/2014 12:14 PM, boden wrote: We were recently having a discussion over here in trove regarding a standardized format to use for log and error messages - obviously consistency is ideal (within and across projects). As this discussion involves the broader dev community, bringing this topic to the list for feedback... I'm aware of the logging standards wiki[1], however this page does not describe in depth a standardized format to use for log / error messages. In particular w/r/t program values in messages: (a) For in-line program values, I've seen both single quoted and unquoted formatting used. e.g. single quote: LOG.info(The ID '%s' is not invalid. % (resource.id)) unquoted: LOG.info(The ID %s is not valid. % (resource.id)) No opinion on this one. (b) For program values appended to the message, I've seen various formats used. e.g. LOG.info(This path is invalid: %s % (obj.path)) LOG.info(This path is invalid %s % (obj.path)) LOG.info(This path is invalid - %s % (obj.path)) The first would be my preference (i.e. using a : to delineate the target of the log message) From a consistency perspective, it seems we should consider standardizing a best practice for such formatting. Possibly, though this is likely getting into the realm of femto-nits and bike-shedding. Ha, you read my mind, i.e. bike-shedding. There are a few wikis and devref docs on style guides in openstack including logging standards, I'd say make sure there is common sense in there and then leave the rest to the review team to police the logs in new changes - if it's ugly, change it with a patch. We don't need to boil the ocean to develop a set of standards/processes that are so heavy weight that people aren't going to follow anyway. This sounds exactly like the kind of thing I see a lot within the workings of my corporate overlord and it drives me crazy, so I'm a bit biased here. :) FWIW, Sean Dague has a draft logging standards spec for nova here: https://review.openstack.org/#/c/91446/ For in-line values (#a above) I find single quotes the most consumable as they are a clear indication the value came from code and moreover provide a clear set of delimiters around the value. However to date unquoted appears to be the most widely used. For appended values (#b above) I find a delimiter such as ':' most consumable as it provides a clear boundary between the message and value. Using ':' seems fairly common today, but you'll find other formatting throughout the code. If we wanted to squash this topic the high level steps are (approximately): - Determine and document message format. - Ensure the format is part of the dev process (coding + review). - Cross team work to address existing messages not following the format. Thoughts / comments? [1] https://wiki.openstack.org/wiki/LoggingStandards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Log / error message format best practices standards
On 06/28/2014 09:41 AM, Matt Riedemann wrote: On 6/26/2014 1:54 PM, Jay Pipes wrote: On 06/26/2014 12:14 PM, boden wrote: We were recently having a discussion over here in trove regarding a standardized format to use for log and error messages - obviously consistency is ideal (within and across projects). As this discussion involves the broader dev community, bringing this topic to the list for feedback... I'm aware of the logging standards wiki[1], however this page does not describe in depth a standardized format to use for log / error messages. In particular w/r/t program values in messages: (a) For in-line program values, I've seen both single quoted and unquoted formatting used. e.g. single quote: LOG.info(The ID '%s' is not invalid. % (resource.id)) unquoted: LOG.info(The ID %s is not valid. % (resource.id)) No opinion on this one. (b) For program values appended to the message, I've seen various formats used. e.g. LOG.info(This path is invalid: %s % (obj.path)) LOG.info(This path is invalid %s % (obj.path)) LOG.info(This path is invalid - %s % (obj.path)) The first would be my preference (i.e. using a : to delineate the target of the log message) From a consistency perspective, it seems we should consider standardizing a best practice for such formatting. Possibly, though this is likely getting into the realm of femto-nits and bike-shedding. Ha, you read my mind, i.e. bike-shedding. There are a few wikis and devref docs on style guides in openstack including logging standards, I'd say make sure there is common sense in there and then leave the rest to the review team to police the logs in new changes - if it's ugly, change it with a patch. We don't need to boil the ocean to develop a set of standards/processes that are so heavy weight that people aren't going to follow anyway. This sounds exactly like the kind of thing I see a lot within the workings of my corporate overlord and it drives me crazy, so I'm a bit biased here. :) FWIW, Sean Dague has a draft logging standards spec for nova here: https://review.openstack.org/#/c/91446/ Yeh, I agree. I think stuff to that level of detail is just overkill. Lets spend our energy on the bigger issues in logging first, and not create a overreach rules that people are going to forget anyway. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
Matt Riedemann mrie...@linux.vnet.ibm.com writes: I would be good with Jenkins not reporting on a successful run, or if rather than a comment from Jenkins the vote in the table had a link to the test results, so if you get a -1 from Jenkins you can follow the link from the -1 in the table rather than the comment (to avoid cluttering up the review comments, especially if it's a +1). The problem with that is it makes non-voting jobs very difficult to see, not to mention ancillary information like job runtime. Plus it adds extra clicks to get to jobs whose output are frequently reviewed even with positive votes, such as docs jobs (on docs-draft.o.o). I think a new table on the page, separate from the comment stream, with only the latest results of each job is the ideal presentation. -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Sergey Kraynev for heat-core
On Fri, Jun 27, 2014 at 07:11:48PM +0400, Sergey Kraynev wrote: Thanks you everyone for the chance to join to this awesome team! It's honor for me and I hope, that my 5 cents will help to make Heat even better :) Regards, Sergey. Congratulations! - Qiming ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] DVR SNAT shortcut
Paul, Is there a blueprint filed on the subject of logging? This really doesn't have anything to do with DVR. The current solution has no logging either. Carl On Thu, Jun 26, 2014 at 5:41 AM, CARVER, PAUL pc2...@att.com wrote: Original message From: Yi Sun beyo...@gmail.com Date: To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut Yi wrote: +1, I had another email to discuss about FW (FWaaS) and DVR integration. Traditionally, we run firewall with router so that firewall can use route and NAT info from router. since DVR is asymmetric when handling traffic, it is hard to run stateful firewall on top of DVR just like a traditional firewall does . When the NAT is in the picture, the situation can be even worse. Yi Don't forget logging either. In any security concious environment , particularly any place with legal/regulatory/contractual audit requirements a firewall that doesn't keep full logs of all dropped and passed sessions is worthless. Stateless packet dropping doesn't help at all when conducting forensics on an attack that is already known to have occured. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] oslo.messaging 1.4.0.0a1 released
On Fri, 2014-06-27 at 13:28 +, Paul Michali (pcm) wrote: Mark, When would we be able to get a release of Oslo with 102909 fix in? It’s preventing Jenkins passing for some commits in Neutron. I've just pushed 1.4.0.0a2 with the following changes: 244a902 Fix the notifier example a7f01d9 Fix slow notification listener tests da2abaa Fix formatting of TransportURL.parse() docs 13fc9f2 Fix info method of ListenerSetupMixin 0cfafac encoding error in file 0102aa9 Replace usage of str() with six.text_type Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 'retry' option
On Fri, 2014-06-27 at 17:02 +0100, Gordon Sim wrote: A question about the new 'retry' option. The doc says: By default, cast() and call() will block until the message is successfully sent. What does 'successfully sent' mean here? Unclear, ambiguous, probably driver dependent etc. The 'blocking' we're talking about here is establishing a connection with the broker. If the connection has been lost, then cast() will block until the connection has been re-established and the message 'sent'. Does it mean 'written to the wire' or 'accepted by the broker'? For the impl_qpid.py driver, each send is synchronous, so it means accepted by the broker[1]. What does the impl_rabbit.py driver do? Does it just mean 'written to the wire', or is it using RabbitMQ confirmations to get notified when the broker accepts it (standard 0-9-1 has no way of doing this). I don't know, but it would be nice if someone did take the time to figure it out and document it :) Seriously, some docs around the subtle ways that the drivers differ from one another would be helpful ... particularly if it exposed incorrect assumptions API users are currently making. If the intention is to block until accepted by the broker that has obvious performance implications. On the other hand if it means block until written to the wire, what is the advantage of that? Was that a deliberate feature or perhaps just an accident of implementation? The use case for the new parameter, as described in the git commit, seems to be motivated by wanting to avoid the blocking when sending notifications. I can certainly understand that desire. However, notifications and casts feel like inherently asynchronous things to me, and perhaps having/needing the synchronous behaviour is the real issue? It's not so much about sync vs async, but a failure mode. By default, if we lose our connection with the broker, we wait until we can re-establish it rather than throwing exceptions (requiring the API caller to have its own retry logic) or quietly dropping the message. The use case for ceilometer is to allow its RPCPublisher to have a publishing policy - block until the samples have been sent, queue (in an in-memory, fixed-length queue) if we don't have a connection to the broker, or drop it if we don't have a connection to the broker. https://review.openstack.org/77845 I do understand the ambiguity around what message delivery guarantees are implicit in cast() isn't ideal, but that's not what adding this 'retry' parameter was about. Calls by contrast, are inherently synchronous, but at present the retry controls only the sending of the request. If the server fails, the call may timeout regardless of the value of 'retry'. Just in passing, I'd suggest that renaming the new parameter max_reconnects, would make it's current behaviour and values clearer. The name 'retry' sounds like a yes/no type value, and retry=0 v. retry=1 is the reverse of what I would intuitively expect. Sounds reasonable. Would you like to submit a patch? Quick turnaround is important, because if Ceilometer starts using this retry parameter before we rename it, I'm not sure it'll be worth the hassle. Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
