Swift middleware subordinate charms?
Hi folks,
I've just started looking into writing a charm (possibly two charms?) to
deploy some middleware to Swift; both the proxy and storage will have
middleware added. Today was the first time I've deployed any OpenStack
component, so my terminology could be off.
I imagine a middleware charm would make most sense as a subordinate to
swift-{proxy,storage}. Are there any existing examples of such a thing? Is
there a friendly way for the subordinate to tell the swift services to
restart, or is it just a matter of sudo restart swift-object-server or
whatever?
Cheers,
Andrew
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Swift middleware subordinate charms?
On Wed, Sep 24, 2014 at 7:52 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi folks,
I've just started looking into writing a charm (possibly two charms?) to
deploy some middleware to Swift; both the proxy and storage will have
middleware added. Today was the first time I've deployed any OpenStack
component, so my terminology could be off.
I imagine a middleware charm would make most sense as a subordinate to
swift-{proxy,storage}. Are there any existing examples of such a thing? Is
there a friendly way for the subordinate to tell the swift services to
restart, or is it just a matter of sudo restart swift-object-server or
whatever?
Hi Andrew. If you're writing a subordinate charm, it'll be relating to
the primary charm via some relation (say middleware-changed) right?
Which I assume you'll need to add to the swift-proxy charm (ie. to
support middleware subordinates generally? Not sure.)
Anyway, normally I think you'd want the primary charm's
(swift-proxy's) relevant relation-changed hook to do the restart
itself when the middleware changes (ie. when middleware-changed is
triggered). This just makes sure that the responsibility and knowledge
of restarts stays within the charm responsible for the service.
Sometimes your subordinate might need to cause a restart even though
nothing else about the relation has changed, which you can do with a
relation-set with an additional timestamp to ensure that the
relation-changed will still be triggered in the related charm which in
turn ensures the restart.
You could of course just have your subordinate restarting the service
itself, but it may bite later on (I think this issue in reverse hit
the gunicorn subordinate charm, which changed the service name and
hence the way restarts happen, but some charms using the gunicorn
charm had done the restarts themselves rather than via the
relationship, causing compatibility issues).
-Michael
Cheers,
Andrew
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Swift middleware subordinate charms?
On Wed, Sep 24, 2014 at 6:59 PM, Michael Nelson
michael.nel...@canonical.com wrote:
On Wed, Sep 24, 2014 at 7:52 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi folks,
I've just started looking into writing a charm (possibly two charms?) to
deploy some middleware to Swift; both the proxy and storage will have
middleware added. Today was the first time I've deployed any OpenStack
component, so my terminology could be off.
I imagine a middleware charm would make most sense as a subordinate to
swift-{proxy,storage}. Are there any existing examples of such a thing?
Is
there a friendly way for the subordinate to tell the swift services to
restart, or is it just a matter of sudo restart swift-object-server or
whatever?
Hi Andrew. If you're writing a subordinate charm, it'll be relating to
the primary charm via some relation (say middleware-changed) right?
Which I assume you'll need to add to the swift-proxy charm (ie. to
support middleware subordinates generally? Not sure.)
Anyway, normally I think you'd want the primary charm's
(swift-proxy's) relevant relation-changed hook to do the restart
itself when the middleware changes (ie. when middleware-changed is
triggered). This just makes sure that the responsibility and knowledge
of restarts stays within the charm responsible for the service.
That makes sense. I was coming from the angle of how to do this without
touching any existing charms, which is wrong.
I think to do this right I'd need to modify the swift-proxy and
swift-storage charms, and have them modify their configuration files rather
than having the subordinate do it. The subordinate would effectively just
provide configuration parameters and install the middleware dependencies.
I'll hack around for now, and maybe I'll propose something later if
anything becomes of my charm.
Thanks for the advice!
Sometimes your subordinate might need to cause a restart even though
nothing else about the relation has changed, which you can do with a
relation-set with an additional timestamp to ensure that the
relation-changed will still be triggered in the related charm which in
turn ensures the restart.
You could of course just have your subordinate restarting the service
itself, but it may bite later on (I think this issue in reverse hit
the gunicorn subordinate charm, which changed the service name and
hence the way restarts happen, but some charms using the gunicorn
charm had done the restarts themselves rather than via the
relationship, causing compatibility issues).
-Michael
Cheers,
Andrew
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Gluu Server Juju Charm
Jose and Charles, Could you summarize the issue? Is it something that we need to document or bugs we should file in core? Marco On Wed, Sep 24, 2014 at 12:42 AM, José Antonio Rey j...@ubuntu.com wrote: On 09/23/2014 11:25 PM, Tim Penhey wrote: On 24/09/14 16:20, Michael Schwartz wrote: Juju team, Thanks to Charles and José, I was able to get my local deployment of Juju running, and later I was successful getting the Gluu Server and Gluu OpenDJ charms installed, which is great progress. Good to hear. Tim That's awesome to hear, Mike! I really look forward to seeing these charms in the review queue soon! Let us know if there's anything else we can assist you with, and we'll be more than happy to. -- José Antonio Rey -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Gluu Server Juju Charm
Marco, The process forward to get Michael unblocked was specifically with regard to a Virtualbox workflow that did not leverage vagrant. It was a vanilla Ubuntu server installation in vbox, leveraging X11 forwarding, and getting the local provider setup and explaining the process of what was happening in the background. Such as on first deploy it's fetching the cloud images and building the containers - there's no console feedback that this is happening and was confusing. Prior Michael stated he had not progressed even as far as getting the GUI setup as he ran into a quickstart issue (undisclosed on what that issue was), that we did not see during our 1:1 support session. With a follow up scheduled tomorrow we'll be capturing additional feedback. I'll have a full report after that meeting drafted for us to triage and turn into work items. All the best, Charles On Wed, Sep 24, 2014 at 11:54 AM, Marco Ceppi ma...@ondina.co wrote: Jose and Charles, Could you summarize the issue? Is it something that we need to document or bugs we should file in core? Marco On Wed, Sep 24, 2014 at 12:42 AM, José Antonio Rey j...@ubuntu.com wrote: On 09/23/2014 11:25 PM, Tim Penhey wrote: On 24/09/14 16:20, Michael Schwartz wrote: Juju team, Thanks to Charles and José, I was able to get my local deployment of Juju running, and later I was successful getting the Gluu Server and Gluu OpenDJ charms installed, which is great progress. Good to hear. Tim That's awesome to hear, Mike! I really look forward to seeing these charms in the review queue soon! Let us know if there's anything else we can assist you with, and we'll be more than happy to. -- José Antonio Rey -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Gluu Server Juju Charm
Marco, I have no idea. We installed the Juju software from a different repository and it worked. It still threw errors, which resulted in confusion, but when we checked juju status, the servers came up. In my original Juju deployment, when I went to bootstrap, it would just hang. I added Jorge Castro, because he also tried to get it working when we manned the booth at OSCON. I did keep the logs from the 2nd successful install, which I'll send. - Mike On 2014-09-24 10:54, Marco Ceppi wrote: Jose and Charles, Could you summarize the issue? Is it something that we need to document or bugs we should file in core? Marco On Wed, Sep 24, 2014 at 12:42 AM, José Antonio Rey j...@ubuntu.com wrote: On 09/23/2014 11:25 PM, Tim Penhey wrote: On 24/09/14 16:20, Michael Schwartz wrote: Juju team, Thanks to Charles and José, I was able to get my local deployment of Juju running, and later I was successful getting the Gluu Server and Gluu OpenDJ charms installed, which is great progress. Good to hear. Tim That's awesome to hear, Mike! I really look forward to seeing these charms in the review queue soon! Let us know if there's anything else we can assist you with, and we'll be more than happy to. -- José Antonio Rey -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju [1] Links: -- [1] https://lists.ubuntu.com/mailman/listinfo/juju -- - Michael Schwartz Gluu Founder / CEO m...@gluu.org -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Gluu Server Juju Charm
It wasn't a download speed issue. Once I let it run overnight. When we got it working the second time, the server deployed in about 5 minutes. Even at OSCON we let it RIP for some time and got nothing. thx, Mike On 2014-09-24 11:02, Charles Butler wrote: Marco, The process forward to get Michael unblocked was specifically with regard to a Virtualbox workflow that did not leverage vagrant. It was a vanilla Ubuntu server installation in vbox, leveraging X11 forwarding, and getting the local provider setup and explaining the process of what was happening in the background. Such as on first deploy it's fetching the cloud images and building the containers - there's no console feedback that this is happening and was confusing. Prior Michael stated he had not progressed even as far as getting the GUI setup as he ran into a quickstart issue (undisclosed on what that issue was), that we did not see during our 1:1 support session. With a follow up scheduled tomorrow we'll be capturing additional feedback. I'll have a full report after that meeting drafted for us to triage and turn into work items. All the best, Charles On Wed, Sep 24, 2014 at 11:54 AM, Marco Ceppi ma...@ondina.co wrote: Jose and Charles, Could you summarize the issue? Is it something that we need to document or bugs we should file in core? Marco On Wed, Sep 24, 2014 at 12:42 AM, José Antonio Rey j...@ubuntu.com wrote: On 09/23/2014 11:25 PM, Tim Penhey wrote: On 24/09/14 16:20, Michael Schwartz wrote: Juju team, Thanks to Charles and José, I was able to get my local deployment of Juju running, and later I was successful getting the Gluu Server and Gluu OpenDJ charms installed, which is great progress. Good to hear. Tim That's awesome to hear, Mike! I really look forward to seeing these charms in the review queue soon! Let us know if there's anything else we can assist you with, and we'll be more than happy to. -- José Antonio Rey -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju [1] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju [1] Links: -- [1] https://lists.ubuntu.com/mailman/listinfo/juju -- - Michael Schwartz Gluu Founder / CEO m...@gluu.org -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: got bootstrapped; now having trouble deploying mysql
Juju will always try to access http://cloud-images.ubuntu.com/releases
to get OS images unless it is configured to get OS imaged from
elsewhere
On Tue, Sep 23, 2014 at 1:43 PM, Patrick O'Brien pdobr...@gmail.com wrote:
...
'juju metadata validate-images' also fails with:
ERROR index file has no data for cloud {RegionOne https://URL:8770/v2.0/}
not found
Resolve Metadata:
source: default cloud images
signed: false
indexURL: http://cloud-images.ubuntu.com/releases/streams/v1/index.json
ERROR subprocess encountered error code 1
However 'juju metadata validate-tools' works:
Matching Tools Versions:
- 1.20.7-trusty-amd64
- 1.20.7-trusty-arm64
- 1.20.7-trusty-armhf
- 1.20.7-trusty-i386
- 1.20.7-trusty-ppc64el
Resolve Metadata:
source: cloud storage
signed: false
indexURL:
https://URL:6482/v1/2c1e5b83fb7b4ffdb43fa4196f2def8d/e5f00e2c5be94b3a89880aa14087fec6/tools/streams/v1/index.json
I've verified that the metadata is in place and current on the object store.
Images metadata: http://pastebin.com/9B8JnC5x
Log from bootstrap node with debug enabled: http://pastebin.com/ffVc7pHE
I think you redacted the image-servers's url in this email and the the
pastebin. I see URL where I expect to see a domain. Can you confirm
that you set the image-metadata-url in environments.yaml to point to
the server and the path to the root of the streams? Something like
image-metadata-url:
https:/my-private-cloud/:6482/v1/2c1e5b83fb7b4ffdb43fa4196f2def8d/e5f00e2c5be94b3a89880aa14087fec6/images
The output from the failed bootstrap shows your image metadata being
read and I can see two matches for images, but the switch to
/cloud-images.ubuntu.com implies juju didn't know how to retrieve
those images.
Also. In my experience with openstack. the endpoint/auth url must end
with a trailing slash. So this maybe redacted URL
endpoint: https://url:8770/v2.0
would be written as
endpoint: https://url:8770/v2.0/
in the json
and then environments.yaml needs the corresponding config
auth-url: https://url:8770/v2.0/
to complete the match.
--
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] rabbitmq-server, postgresql
[1] Merge proposal for rabbitmq-server. The author has been attentive to feedback, and his latest work passes charm proof and lint cleanly. I’ve asked him to provide the steps necessary to properly test his changes, in lieu of actual unit tests. [2] Pinged #juju on Freenode for a charmer to mark this merge as rejected. Similar work is already being done, superseded by stub’s collection of MPs in the review queue. [1] https://code.launchpad.net/~gnuoy/charms/trusty/rabbitmq-server/lp-1355848/+merge/231528 [2] https://code.launchpad.net/~jaywink/charms/trusty/postgresql/swiftwal_missing_functionality/+merge/235394 -- Adam Israel-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Application to ~charmers - Jorge Niedbalski
Hello Charmers, I would like to have your consideration to become a member of the http://launchpad.net/~charmers team. I have been playing around with the Juju's ecosystem since some months, fair enough time to understand where a ~charmer should be pushing to contributors to make the environment safer for everyone. Part of my daily job is to deal with customers with several distinct deployment scenarios. I have been dealing with issues and feature requests on almost the entire Juju stack (Juju-core, juju-plugins, charms, charm-helpers, charm-tools, openstack, juju-client, deployer, etc). Regarding to my contributions, the charms that i authored/maintain are: - https://jujucharms.com/trusty/rsyslog - https://jujucharms.com/trusty/rsyslog-forwarder-ha I also have contributed patches to other charms ( mysql, rabbitmq-server, nrpe, postgresql) as well to most of the ~openstack-charms in different areas. On ecosystems, I have contributed several patches on the charm-helpers package (important: contrib.python, core modules), I have performed revisions and observations on charm-tools changes and authored/re-factored juju-plugins. I also have contributions to the Amulet suite and minor fixes to jujuclient library. Also i have a fair amount of juju-core's mps and bugs. I understand that we need mature and well tested charms (I use them daily!!), for that reason i have been directly pushing and teaching constantly to contributors and customers for having unit and functional tests (see: trusty/vem trusty/vsm charms) to improve the code coverage and documentation. On the community side, I have performed several reviews; blocking changes and asking for improvements whenever i can. Also have been listed as official reviewer a couple of weeks, helping people on public channels and performed several training sessions to co-workers , team and people interested in charming in general. Please, feel free to ask me whatever you think is important (IRC: niedbalski), and again, thanks for your consideration. -- Jorge Niedbalski R. # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544) -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Another ~charmers application! - Chris Glass
Hi all, It's my turn to apply for ~charmers membership. I have been using juju since the pyjuju days, mostly professionally but also for my personal use. Most of my contributions to the charm ecosystem stem from my current work position as a software engineer for Canonical, as part of the Landscape team: 1. Contributing to our own landscape and landscape-client charms (I am a member of ~landscape-charmers) 2. Heavy contributions to the storage subordinate (refactoring and extra features). 3. Working with OpenStack charms daily, and as such had the opportunity to find, trace and fix a variety of bugs in them. (I'm a member of ~openstack-charmers). 4. charm-helpers is of particular interest to me, and I have undertaken to explore, tidy and refactor that code, since it appears to have grown organically in the past, and accumulated a bit of technical debt. From the personal use side, I'm also the author of the ubuntu-mirror charm announced a few days ago, that I use to deploy and maintain an official ubuntu archives mirror. As most programmers I have a few other projects up my sleeve, but all of them might not become public before a bit more time. Outside of charming I'm an Ubuntu member and contributor, dad of one, and world traveler. Python has been my tool of choice these last few years, and before joining Canonical I've used puppet, vCenter Orchestrator, chef, and crowbar quite extensively. The last few items should give a hint as to where my previous professional positions were held :) Thanks for your consideration, time and awesome work, Best, - Chris -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: RFC: state entities, replace globalKey() with .Tag().String()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.09.2014 06:53, Tim Penhey wrote: Hi folks, I have been going through much of the code in the state package looking at the work to migrate all the collection keys to handle multiple environments. In the long and distant past (earlier this year), the Tag() method returned a string. There is a second tag like thing in the state package called the globalKey. This is used as a collection independent key into annotations, presence, settings, networks and status. It seems that the only things we ever use for this are entities that have their own tag types. If we ignore actions (which I don't think should bother implementing globalKey), then we are talking about: machine, service, unit, and network. I propose that we replace all occurrences of the globalKey with a string representation of the Tag for that entity. Why? Global keys are a shorter than tags, and in several places we use fast regular expression searches using a prefix based on the global key. So instead of having m#0#n#juju-public as global key for a port ranges document, we'll have to use machine-0*network-juju-public, where * is some unambiguous separator. The same is valid for service settings - s#wordpress will become service-wordpress. I'd rather have a transparent transformation in place to convert global keys to tags, where needed (the only special case I can think of is relation tags relation-123, which cannot be converted back to relation names (e.g wordpress:db mysql:server) without a DB lookup). Also, what I didn't understand is how using tags as global keys will solve the case with multiple environments in the same DB? One good part of this, is that for any element of the other collections, we can use the existing state.FindEntity(tag names.Tag) function. Is anyone opposed to this change? Cheers, Tim - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUIl6FAAoJENzxV2TbLzHwTIEH/2UBuTZDZ+q/4cA+lobBkzlF USCuH2QWHh2IAjDqpTBgOyhqfBiN/eWXlxkoay6WfdPMeulUuZfcNG+E2rK/0Zs6 GE6W5MLLUEftgPm4cBCKyaaJozcpK4Yr7aQfLM9A0XcD3iQziyQPaceHZh5jB+Al bzuoCdAy1d8oC5D0Ir3SIBWN5scytDCUyhOfrkqJCa8euFxTkYwidgCcLXyer1wn I0MuoBP1yEfloJx2y7WAbVkmPU9vs8rjNMu5mLh+DyjwJWlF2s2q2kATccu/E9zu tx991nqkplmrfqIOqX/OREYt6vwrnkYQUsZDMARIhDwLA1JzgT7/mXzGuxOs5fc= =82Nr -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: RFC: state entities, replace globalKey() with .Tag().String()
On 24/09/14 18:02, Dimiter Naydenov wrote: On 24.09.2014 06:53, Tim Penhey wrote: Hi folks, I have been going through much of the code in the state package looking at the work to migrate all the collection keys to handle multiple environments. In the long and distant past (earlier this year), the Tag() method returned a string. There is a second tag like thing in the state package called the globalKey. This is used as a collection independent key into annotations, presence, settings, networks and status. It seems that the only things we ever use for this are entities that have their own tag types. If we ignore actions (which I don't think should bother implementing globalKey), then we are talking about: machine, service, unit, and network. I propose that we replace all occurrences of the globalKey with a string representation of the Tag for that entity. Why? Global keys are a shorter than tags, and in several places we use fast regular expression searches using a prefix based on the global key. So instead of having m#0#n#juju-public as global key for a port ranges document, we'll have to use machine-0*network-juju-public, where * is some unambiguous separator. The same is valid for service settings - s#wordpress will become service-wordpress. Sorry, but this is terrible. The regex searches we have are needlessly complicated, and the documents should have real fields rather than disassembling the _id field. I think that having a slightly longer value stored in mongo is worth the code when it means we go from having two ways to identity an entity down to one. I'd rather have a transparent transformation in place to convert global keys to tags, where needed (the only special case I can think of is relation tags relation-123, which cannot be converted back to relation names (e.g wordpress:db mysql:server) without a DB lookup). I'd rather just have one way to identify an entity in state. Also, what I didn't understand is how using tags as global keys will solve the case with multiple environments in the same DB? It doesn't, it is just code cleanup that I think we should do. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: RFC: state entities, replace globalKey() with .Tag().String()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.09.2014 10:09, Tim Penhey wrote: Why? Global keys are a shorter than tags, and in several places we use fast regular expression searches using a prefix based on the global key. So instead of having m#0#n#juju-public as global key for a port ranges document, we'll have to use machine-0*network-juju-public, where * is some unambiguous separator. The same is valid for service settings - s#wordpress will become service-wordpress. Sorry, but this is terrible. The regex searches we have are needlessly complicated, and the documents should have real fields rather than disassembling the _id field. I think that having a slightly longer value stored in mongo is worth the code when it means we go from having two ways to identity an entity down to one. Using compound keys like that allows us to overcome some limitations of MongoDB/mgo with regards to ensuring integrity, which is otherwise either impossible or quite hard to do with transactions. If I use the port ranges document as an example again, the compound key including the machine id and network name gives us: - A way to get all docs for a given machine and any network, using a simple regex like m#42#n#.*. - No need to add unique indexes to guarantee only a single document per machine / network (and using unique indexes has other drawbacks - mgo returning nil and not inserting anything when there's an index violation, so this means additional checks and more complicated asserts) - Using the _id field gives us uniqueness and fast lookup by id, slightly slower regexp lookup, but still faster than other cases. A more complicated example is the proposed network interfaces document structure: https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/edit#heading=h.pwdo7b7njiz9 There, using an _id field like m#id#sha1-hash(network#mac-addr[#suffix]) gives us both a way to get all machine NICs easily, but also guarantees there won't be a chance to have a NIC with the same MAC on the same network and machine. The same is much harder or impossible to do with asserts on multiple fields and unique indexes, in a transaction. I'm not opposed to replacing global keys with tags in state, but using only simple _id fields in all collections is impractical in certain cases. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUInUuAAoJENzxV2TbLzHww5MH/A0foVm/+dYfHWLNsEyi//DN 7QtkkJxmu79JYBzG15fCIrrBDa6Edx0VCIYeEvsQmRRnDJUH+H4IWtlvmssxaxw2 WWoOVuDgCn5oKbEE0NKSbYq3dbk2q4VUryPml+0n79KZxZQrI9Xry6W/o2pm0BQc LIEU5RjxgD1YXV/B+0cvp9zpKmwm9/Pi6VsXF5O8sewINh0INr0HEMOYPt+LLsec yIMcdd7ujIxL/hU1IOjtLkwBaPSXSxcbK5UUzO0aG2KNswfxCXO7X99kpFlg7z29 xqdoW7UCEkzoWrSCHWmkiTyCYa1zPApHEBd/tA/K34BV+XEDFMolFi9b8GmhliA= =sX4m -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: RFC: state entities, replace globalKey() with .Tag().String()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.09.2014 10:46, Tim Penhey wrote: On 24/09/14 19:39, Dimiter Naydenov wrote: I'm not opposed to replacing global keys with tags in state, but using only simple _id fields in all collections is impractical in certain cases. Don't get me wrong, I'm not suggesting changing the _id fields to be more simple. I understand that they are needed for the watchers (at the moment). I fact, the _id fields are getting more complex as we prepend the environment uuid to it. However we are also adding a normal field for the EnvUUID so it can be easily queried against. Tim +1, this sounds good to me! - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUIngDAAoJENzxV2TbLzHwcwAH/iGJbsaVRQcF326W+R+1JIA/ Hlzo/srbTXulrI029aw8JYjIhXnzvlzvYpaOZvE9trdH1izr0lcSd/m3kcJIv4Bq bXCNZDJlSrudV6E3DQKqBSWyCM7HRUEUa498MGcNBkmPxgQwwdFddV62YCyqT4R7 T/pgU5/cNrh73QL6C0xoFJOy9NL5LXYHM8cURBB2RmhSuHj7I8QUk3+/DRxL/Tc5 cIjzjhj6t6Y5DOtvgsXJK4Hx3DsaOSw04lyW+hWvy5PfZPk6Lj4VJFYfhHx93SMG RF3ObX2ArF26m2insrv6S2du9adyoh2OGZA9CeCyDKE9BOtvy4zW7ljH25EvlJQ= =995A -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Rsyslog imtcp issue
Hello, I am the maintainer of the rsyslog/forwarder charms. While i was working implementing an option to expose the protocol/port used by rsyslogd I noticed that enabling TCP on rsyslogd using imtcp ($InputTCPServerRun 514) was not possible on any machine deployed by Juju. The root cause is that /etc/rsyslog.d/26-juju-unit-primary-0.conf declares a DefaultNetStreamDriver to use gTLS, and apparently both plain tls sockets cannot live together on rsyslogd. After changing the $DefaultNetstreamDriver from gtls to ptcp it worked correctly, for both actions collecting logs via TCP 514 and forwarding logs to 10.0.3.1:6514;LongTagForwardFormat. I know is not an option to abandon the usage of gTLS, but ideally, Juju should have a separated service and configuration path that doesn't interrupts any other rsyslogd process running on the host. I think we can workaround/fix this by running 2 different rsyslogd services with different configurations (maybe a default path different for juju /etc/rsyslog.d/juju/ ?), Please any observation would be appreciated Cheers. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services Engineering Team # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544) -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
HA UX Revamp
There was some feedback recently that the UX of Juju's HA implementation is not very good. I wrote up a doc[1] capturing the feedback and some solutions that were proposed during an informal meeting. The document is currently purely just about capturing information about the problem. It is not intended to be a spec, and work has not (yet) been scheduled. However, I wanted to make sure everyone was aware of it, because some of the suggested changes represent significant dev investment, and I'd like to get as many people's input as possible about the UX changes. [1] https://docs.google.com/a/canonical.com/document/d/1odffi1HE61qTOsznx0rOjPdhZJT_wGlf25x-xNP5Lg8/edit# -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
